abushyk

Админка /admin/index.php?action=structure
Тут для каждого пункта меню необлодимо указать иноязычные названия.

Думаю, что скоро, не смотря на наличие редактора форм, мы придем к некоторой спецификации модели, которая будет иметь набор обязательных неизменяемых полей. Наверное даже управление которыми будет не доступно пользователю через редактор форм. Эот будут поля вроде id, дата создания, дата изменения.

/apps/system/lib/admin/data/data_manager.php:1342 - тут фактическое сохранение при редактировании.
Если до этого места в функции Data_Manager::edit_data() проинициализировать некое поле, например date_added (поле даты добавления объекта) текущей датой, как это сделано в строке 1471
$form_data['date_added']['value'] = date('Y-m-d H:i:s', time()); то будет установлена новая дата.

Думаю вопрос о том, можно ли в полях настроек неявно прописівать что-то вроде {$current_city_name} куда бы динамически подставлялось имя текущего города. Если да, то нет. Пока ни один параметр не позволяет вставки подобных плейсхолдеров.

Небольшой оффтоп.
Уже сложилась практика создания структуры категорий в виде Продажа-Квартиры, Продажа-Комнаты, Аренда-Квартиры, ... Т.е объединения в одно целое различных понятий - типа недвижимости и вида операции с ней. имхо - это плохая практика. Ведь недаром стараются вести отдельно параметры жилой и общей площади. С ними тогда значительно удобнее работать, сравнивать, фильтровать, чем со значениями вада ааа/ббб.
Если все упирается в создание меню навигации в виде выпадающих списков, то затраты от разработки такого меню не есть больше минусов от содержаний структуры в виде смешанных понятий.
 
Теперь чисто теоретически.
 
Имеем таблицу re_data, re_topic, re_rubrika (объявления, типы недвижимости, рубкрики (как-то Продам, Сдам, Сниму)). Как получить сводную матрицу количеств обїявлений:
$ads_count_matrix=array();$DBC=DBC::getInstance();$query='SELECT COUNT( d.id ) AS dcount , t.name AS tname, r.name AS rnameFROM re_data dLEFT JOIN re_topic t ON d.topic_id = t.idLEFT JOIN re_rubrika r ON d.rubrika_id = r.rubrika_id WHERE d.active=1GROUP BY d.topic_id, d.rubrika_id';$stmt=$DBC->query($query);if($stmt){    while($ar=$DBC->fetch($stmt)){ $ads_count_matrix[]=$ar; }} В результате мы получаем массив вида:
[0][dcount]='10'[0][tname]='Квартиры'[0][rname]='Продам'[1][dcount]='2'[1][tname]='Комнаты'[1][rname]='Продам'[2][dcount]='1'[2][tname]='Квартиры'[2][rname]='Сдам'[3][dcount]='0'[3][tname]='Комнаты'[3][rname]='Сдам'... Дальше уже дело техники. Либо скинуть этот массив в шаблон и там его просто вывести, либо в контроллере обработать его дополнительно - упорядочить по рубрикам, типам и тогда уже скинуть в шаблон для вывода.
 
Если рубрики\категории слиты в единую структуру, то принципиально решение будет похожим, но будет больше мороки с упорядочиванием, так как надо будет вычислить какие типы в какие рубрики входят и свести их.

Небольшой оффтоп.
Уже сложилась практика создания структуры категорий в виде Продажа-Квартиры, Продажа-Комнаты, Аренда-Квартиры, ... Т.е объединения в одно целое различных понятий - типа недвижимости и вида операции с ней. имхо - это плохая практика. Ведь недаром стараются вести отдельно параметры жилой и общей площади. С ними тогда значительно удобнее работать, сравнивать, фильтровать, чем со значениями вада ааа/ббб.
Если все упирается в создание меню навигации в виде выпадающих списков, то затраты от разработки такого меню не есть больше минусов от содержаний структуры в виде смешанных понятий.
 
Теперь чисто теоретически.
 
Имеем таблицу re_data, re_topic, re_rubrika (объявления, типы недвижимости, рубкрики (как-то Продам, Сдам, Сниму)). Как получить сводную матрицу количеств обїявлений:
$ads_count_matrix=array();$DBC=DBC::getInstance();$query='SELECT COUNT( d.id ) AS dcount , t.name AS tname, r.name AS rnameFROM re_data dLEFT JOIN re_topic t ON d.topic_id = t.idLEFT JOIN re_rubrika r ON d.rubrika_id = r.rubrika_id WHERE d.active=1GROUP BY d.topic_id, d.rubrika_id';$stmt=$DBC->query($query);if($stmt){    while($ar=$DBC->fetch($stmt)){ $ads_count_matrix[]=$ar; }} В результате мы получаем массив вида:
[0][dcount]='10'[0][tname]='Квартиры'[0][rname]='Продам'[1][dcount]='2'[1][tname]='Комнаты'[1][rname]='Продам'[2][dcount]='1'[2][tname]='Квартиры'[2][rname]='Сдам'[3][dcount]='0'[3][tname]='Комнаты'[3][rname]='Сдам'... Дальше уже дело техники. Либо скинуть этот массив в шаблон и там его просто вывести, либо в контроллере обработать его дополнительно - упорядочить по рубрикам, типам и тогда уже скинуть в шаблон для вывода.
 
Если рубрики\категории слиты в единую структуру, то принципиально решение будет похожим, но будет больше мороки с упорядочиванием, так как надо будет вычислить какие типы в какие рубрики входят и свести их.

Нет. Но можете применить стили косвенно, через указание привязки к родительскому элементу.
Например, если у вас {$country_list} в форму выводится как
<div class="someclass_for_countrylist">{$country_list}</div> то можно обцеэсэсить его следующим образом
.someclass_for_countrylist select { /*тут стили*/} Но не забывайте, что не все элементы столь прямолинейны. Для вывода автокомплит-элементов используются возможности jqueryUI, поэтому стили надо применять к конечному элементу, который создает жиквери.

Никак.
При обработке данных от пользователя из ЛК
1. Поле user_id средствами цмс инициируется значением ид текущего пользователя. Т.е., что бы вы не передали с сайта, в поле юзера всегда будет указан текущий пользователь.
2. Поле user_id средствами цмс ставится в скрытое состояние. Т.е. его не видно в форме так как оно проходит hidden элементом формы. Но даже если вы его поинициируете, например, скриптом, все равно сработает пункт 1.
 
В данный момент все попытки реализовать вашу схему - бессмысленны. Так как, что бы пользователь С мог сменить владельца объявления с А на Б,ему надо получить это объявление на редактирование. Но получить объявление в ЛК, владельцем которого есть А, на редактирование можно только под логином А. Логика понятна?
Выставление видимости поля юзер_ид в модели для групп тоже ничего не даст, так как опять сработает пункт 1. Это ЛК, а не админка, доступная с фронта. Поэтому и такая своя логика.
 
Тут выходом может быть адаптация ЛК под вашу систему ролей.

Разобрался если обьявление подает не зарегистрированный пользователь  то работает форма data_form.tpl     - в этой форме все работает
                     если обьявление подает зарегистрированный пользователь  то работает форма data_form_front.tpl - в этой форме не работает условие "Активно в категории"
 
Ошибочное заключение поменял названия файлов все осталось без изменений.
Совсем запутался.
Итог:
1. В таблице data для поля room_count выбрал "Активно в категории" нужные категории.
Работает 
   - при создании  объявления а админке
   - при редактировании объявления а админке,
   - при создании объявление на сайте незарегистрированным пользователем.
Не работает
   - при создании  объявления на сайте зарегистрированным пользователем
   - при редактировании объявления на сайте зарегистрированным пользователем

Есть маленький баг\фича - в силу структуры запроса к БД, в вывод не попадают объявления, для которых не указан раздел из таблицы re_topic (topic_id)

Вывод цены за квметр "в лоб"
 
вычисление
{if $data.square_all.value!='' && $data.square_all.value!=0 && $data.price.value!=0 && $data.price.value!=''}    {assign var=per_meter_price value=$data.price.value/$data.square_all.value}{else}    {assign var=per_meter_price value=''}{/if} вывод
{if $per_meter_price ne ''} {$per_meter_price|number_format:2:',':' '}{/if} Это если обработку размещать в шаблоне. Поля price и sqare_all должны быть заданы в модели.

Ответ: 530 Login authentication failed Вводите неверные логин либо пароль. Скорее всего пароль.
Хост указывается тот, который вам выдал провайдер, либо который можно обнаружить в настройках вашей панели управления хостингом.
Порт, если соединяетесь по фтп, 21.
 
По сабжу. Через редактор шаблонов вы сможете загрузить ТОЛЬКО логотипы в формате gif, jpg, png.
Если очень хочется свг, флеш или что-то иное, файл логотипа грузится вручную на сервер и, так же вручную, должен быть прописан в разметке.

Не 
{include file="tlocation_form_element_simple.html"} а просто 
{$tlocation_form_element_simple.html} Тут .html это не расширение файла, а поле объекта.

Для проверки условия?
Вы рассуждайте от того, что бы вы должны получить. Например getAccountValue должна вернуть имя файла, а это строк. Непустая. Тогда можете смело проверять на !='' . trim лишних пробелов можете сделать как внутри getAccountValue , так и после нее, но лучше внутри - тогда функция будет  гарантировано возвращать строку-имя либо пустую строку, т.е. будет предсказуемой.
Тут много зависит именно от того, какие задания вы возложите на функции и сто они должны будут вам возвращать. Но проверок по сути всего несколько. Для примитивных значение это равенство\неравенство\эквивалетность и empty

Новое поле - это совсем новое или одно из тех, что есть в модели, но не выводится в форме поиска?

Поле добавленное в модель как safe_string штатными средствами в данный момент могут быть выведены в форму поиска либо как текстовое поле (для поиска по точному значению), либо как диапазонный элемент (для поиска в промежутке, логично для числовых значений, требует некоторой доработки). Возможности превратить safe_string в селектбокс с набором существующих значений самим движком сейчас нет

Если это select_box, то да, тут не добавишь. А если это select_by_query, то существует вариант с auto_add - полями. Т.е. сам селектбокс выводит присутствующие в таблице данные, но есть дополнительное, несохраняемое, поле типа auto_add, значение введенное в которое будет дописано в таблицу, указанную в его настройках.
Напрмер select_by_query поле street_id - выводит улицы из таблицы street.
А auto_add поле new_street при сохранении добавляет новую запись в таблицу street.

Частные формы поиска завязываются на категорию и, соответственно, они активируются если 1)для них указана категория\категории 2) поиск прошел по одной из этих категорий. Если для частных форм не указать категории, либо указать, но выполнить поиск со стандартной без выбора категории, активной автоматически станет стандартная.

В окошках пусто, потому что шаблон рассчитывает на стандартные элементы географии, а они отключены. А вот тлокейшн не выводится, потому, что по умолчанию он не присутствует в шаблоне формы поиска.
 
1. Файл /www/apps/system/lib/frontend/search/kvartira_search.php ищем строку типа
 
if(isset($kvartira_model['data']['tlocation'])){ $this->template->assert('tlocation_form_element', $form_generator->compile_tlocation_element($kvartira_model['data']['tlocation']));} и заменяем ее на 
 
if(isset($kvartira_model['data']['tlocation'])){ $this->template->assert('tlocation_form_element_simple', $form_generator->compile_tlocation_element($kvartira_model['data']['tlocation'])); $this->template->assert('tlocation_form_element_extended', $form_generator->compile_tlocation_element($kvartira_model['data']['tlocation']));} 2. Файл /www/template/frontend/имя шаблона/standart_search_form.tpl либо /www/template/frontend/agency/search_form.tpl (для тех шаблонов в которых нет standart_search_form.tpl)
Там есть разметка которая отвечает за вывод географии. Это {$country_list} и т.д. похжее по смыслу.
 
За вывод тлокейшна отвечает два куска кода
{$tlocation_form_element_simple.html}и{$tlocation_form_element_extended.html} Первый для простой формы поиска, второй для расширенной.
 
Нужно ликвидировать из формы (либо закомментировать) все выводы стандартных элементов ({$country_list}, {$region_list}, {$city_list}, {$street_list}, {$district_list}) и расставить {$tlocation_form_element_simple.html} и {$tlocation_form_element_extended.html}
 
3. Следить за тем, что бы не обновился файл  /www/apps/system/lib/frontend/search/kvartira_search.php ибо тот вывод что там для тлокейшн немного устарел и был рассчитан, что форма поиска одна, а не две - расширенная и простая. В дальнейшем, думаю, генерация двух элементов станет доступна и в базовой версии.

Вот, кстати, вспомнил http://wiki.sitebill.ru/index.php?title=Tlocation

Cам tlocation не имеет включателя\выключателя. Для него может включаться\выключаться стратегия обработки адресных данных при загрузке из эксель листов. Но сам тлокейшн не требует включения. Он активен автоматически при установке приложения. В админке он не выдает ничего - белый лист.
Для использования тлокейшн в редакторе форм создается элемент типа tlocation, там где выбираются safe_string и прочие. Этот элемент создает комплекс элементов аналогичных по смыслу country_id\region_id\city_id\district_id\street_id. Для правильной обработки элементы с такими именами в редакторе форм должны быть удалены либо переведены в состояние "неактивно".
По сути тлокейшн это все те же country_id\region_id\city_id\district_id\street_id, но собранные в комплекс.
Тлокейшн требует от администратора структурированной базы. Тут не проходит вариант, когда есть список уникальных имен городов и список уникальных имен улиц и они не связаны между собой. Каждой сущности должны соответствовать другая. Кроме стран. Страны - корневые и они не имеют принадлежности.
Еще одно замечание - элемент типа tlocation должен иметь системное имя - "tlocation" и не иначе.

Там есть свои нюансы.
1. Болгария свободно продает недвижимость иностранцам, но земельные участки могут покупать только нерезиденты имеющие зарегистрированное юрлицо на территории Болгарии. Поэтому если "в комплекте" с недвижимостью идет участок, на котором расположен дом - могут возникнуть сложности. Часто существуют дома, построенные как раз для покупки квартир\апартаментов в них именно иностранцами.
2. Любой трезвомыслящий покупатель захочет получить инспекционый осмотр покупаемого. Это больше касается новостроек, но и при покупке апартаментов, лично я бы не отказался от выезда на место с целью лоценки окружающей инфраструктуры, климата и состояния объекта.
3. Придется глубоко вникнуть во все эти болгарские акты 14, 15, 16.
4. Больший смысл имеет для иностранца покупка апартаментов в апартотелях хотя бы с минимальными удобствами: лифт, охрана, парковка, что бы эта недвижимость могла работать. Это очень актуально для черноморского побережья. Они выйдут дороже в ежегодном обслуживании, но более выгодными в имиджевом плане.
5. Придется заводить хорошие контакты в среде застройщков. Не посредников, а именно застройщиков, так как только они владеют реальной информацией о сроках готовности объекта и, зачастую, занимаются организацией "прикрепленных" услуг как комуналка, ежегодное обслуживание, охранная и лифтовая компания.

Принципиально - возможна. Стоимость заграничной недвижимости обуславливается в основном длинной "пищевой цепочки" между застройщиком и финальным покупателем и аппетитами участников этой цепочки.
В конкретном случае я интересовался стоимостью жилья на побережье Болгарии. Так вот легче оказалось найти офис застройщика физически в Болгарии, чем найти его сайт в интернете. Хотя предложений от посредников для конкретного жилкомплекса в поиске попадается много. В добавок к этому посредники практически никогда не озвучивают фирму-застройщика, что логично, но затрудняет поиск прямых контактов.
В целом болгарская недвижимость не есть дорогой и, зачастую, довольно качественная. Но тут огромное влияние имеет ее расположение. То, чего не видно в состоянии недвижимости, например в летний сезон, очень даже сильно может вылезти в зимние месяцы, так как болгарские зимы ближе к европейским чем к тропическим.

abushykВозможность осмотра с бесплатным проживанием есть, по-крайней мере, предварительно декларируется. Проживающий там человек как раз и обеспечивает контакт с застройщиками и собственниками.
Нюансы понятны, куда ж без нюансов... Главное, что меня интересует - возможна ли реально продажа именно дешевле, чем у всех. А с этим пока непонятка. 

В принципе, если кому интересно, то я разместил в Яндекс.Диске весь КЛАДР, преобразованный в формат CSV (открывается Экселем) - http://yadi.sk/d/vbs4sjGk6jRjd
Качайте и пользуйтесь на здоровье!