abushyk

Если два запроса это вызовы в следующих функциях в начале main() $rs .= $this->getImage();$rs .= $this->getAccountValue($em);то второй точно никогда не отработает. В него не передается значимый аргумент, а только необъявленная переменная, которая приведется к пустому значению.

Проверяйте, что возвращает запрос к вашей таблицы. У меня такой нет, поэтому я просто инициализировал $em в getImage заведомо правильным значением почтового ящика и вывод прошел. Есть ли в той таблице вообще поле email и если есть, то не пустое ли оно у первой записи в выборке?

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

Пардон, я подумал, что вы про редактирование объявления, а не модели, пишете.

Умная мысля, она, как известно, хорошо, если вообще приходит)

настройки, вкладка Общее, Включить привязку улиц к городу Хотя, если у вас улицы прилинкованы к городу, тоже будет не гут.

Проверьте вот єту конфиг переменную link_street_to_city Если она выбрана, то район игнорируется.

Тут дело не ограничится одной БД и таблицами в ней. Для каждой сущности придется сообразить какой-то конец в админке, что бы управлять (как справочники городов, стран). Либо из excel через csv вгонять всразу в mysql. Следующая проблема - вывод. Напрмер, есть Регион и дочерние к нему Район (которых "не одна сотня"). Без некотороой доли инетрактивности вывод того же селектбокса Районов будет выглядеть как простыня всех раонов. Но тут, допустим решабельно через автокомплит (не комбобокс!). Дальше, поиск. Что бы искать по новым сущностям - тут тоже придется где-то прописать к ним обращения. На фоне всего этого само заведение справочника в БД - задача не сложная. CREATE TABLE IF NOT EXISTS `re_имя_сущности` ( `имя_сущности_id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL DEFAULT '', `имя_родительской_сущности_id` int(11) UNSIGNED NOT NULL DEFAULT '0', PRIMARY KEY (`имя_сущности_id`), INDEX (`имя_родительской_сущности_id`)) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;где имя_сущности - это route, subregion, station а имя_родительской_сущности - это то к чему сущность привязана region, city, ... Либо через Редактор Форм использовав привычные поля типа safe_string и select_by_query (тут главное создавать таблицы в порядке наследования от родителя к детям). Но Редактор Форм не генерирует код работы с новосозданной сущностью. Т.е. опять получаем вещь в себе без админки.

Это вы сделали первый шаг к гибриду между Nested Sets и Materialized Paths структуре))) У нее есть один огромный минус - вам придется лично следить за попаданием новых категорий в нужный промежуток. Ну а глобально говоря - будет беда, если надо вставить подкатегорию, а свободных номеров в промежутке 200-299 уже нет. Именно поэтому для активно растущих и часто изменяемых деревьев не особо используют подобные подходы, а используют автогенерируемые id\parent_id. А вот если вы четко знаете какая структура будет на вашем сайте и что она не выйдет за эти рамки - можно смело переходить к другим типам - если дерево категорий не громадно - прирост производительности гарантирован. Кстати, если вы присмотритесь к структуре категорий, которая содается при первичной инсталяции сайтбилля, вы найдете много похожего на ваш подход.

Такая кнопка есть в админке. В свежих, то точно. А вот "Откатить" - мысль не плохая.

active - признак активности. случаи использования не зафиксированы. sql_where - устаревшее поле. не используется (когда-то в нем бул кусок sql для формирования выборки). def_id1, def_id2 - аналогично предыдущему obj_type_id, operation_type_id - частные случаи. Не используются в подавляющем большинстве шаблонов.

Вылетело из головы - в параметрах поля тлокейшн проверьте, что бы не был отмечен чекбокс "Хранить значение поля в таблице". Поле комплексное и на БД оно проецируется не прямо на колоку таблицы, а на группу колонок.

В связи с переходом на другую библиотеку для доступа к БД лучше пользоваться методами библиотеки DBC И вместо этого function getAccountValue($em) { $query = "select * from re_user where email='$em'"; $this->db->exec($query); $this->db->fetch_assoc();$rs = $this->db->row['imgfile']; return $rs; }это function getAccountValue($em) { $rs=''; if($em==''){ return $rs; } $DBC=DBC::getInstance(); $query = "select * from ".DB_PREFIX."_user where email=? LIMIT 1"; $stmt=$DBC->query($query, array($em)); if($stmt){ $ar=$DBC->fetch($stmt); if($ar['imgfile']!=''){ $rs=$ar['imgfile']; } } return $rs;}

$rs = $this->getTopMenu();$rs .= $this->getImage();$rs .= $this->getAccountValue($em);Во второй строке внутри getImage выполняется, а отдельно в getAccountValue нет? А где присвоение значения для $em ?

Не удалось подать с той формы, что под урлом /add/ или через админку?

Не совсем верно. Есть два пути развития структуры географии (города, страны, улицы, ...) - ленивый и геморройный. Геморройный - это тлокейшн, который требует порядка в связях между географическими элементами, что требует от админа некоторых дополнительных усилий. Ленивый - комбобокс или автокомплит, которы допускает, что географические элементы не представляют собой некоторую структуру, а являются банальными хешами (просто таблица городов, просто таблица улиц. и одно не связано с другим). И у первого, и второго есть свои плюсы и минусы. И каждому нравится что-то из них. Либо просто больше подходит в силу некоторых обстоятельств. Поэтому хоронить один из них вряд ли придется. Думаю со временем они могут разойтись на две различные ветки без возможости переключения между ними "ван кликом". Но не более. Это если речь идет о самом принципе работы, а не о презентационном стиле.

Если его нет в редакторе форм для таблицы data - тогда ничего не надо деактивировать. Главное, проверьте, что бы работала возможность добавлять страны из админки (Справочники -> Страны). Если там есть этот раздел и он рабочий, значит страны подключатся. И еще непонятно что делать с формами подачи объявления?Форма подачи строится на основе модели для data. Она, в принципе, повторяет форму администратора при вводе объявления. Т.е. тут не должно быть надо что-либо еще делать. Только как по умолчанию страну,регион поставить?В редакторе форм берется на редактирование ваш элемент tlocation. Ближе к концу у него есть набор полей Параметры. В них можно выставить дефолтные значения. например для страны добаляете пару default_country_id и для нее вписываете значение id (идентификатора) страны по умолчанию. Взять его можно из Справочник - Страны

Города были. Улицы были. Регионов вроде не было.

В окошках пусто, потому что шаблон рассчитывает на стандартные элементы географии, а они отключены. А вот тлокейшн не выводится, потому, что по умолчанию он не присутствует в шаблоне формы поиска. 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

В принципе можно, но это не реализовано. Думаю, стоит задуматься о переходе на приложение GeoData. В нем вшита возможность геокодирования существующей базы объявлений.

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" и не иначе.

В принципе да. ЦМС выдает в шаблон некоторые более-менее универсальные значения, а уже сам шаблон решает в каком виде вывести это значение пользователю. например, значение is_telephone в форме выводится в вимде чекбокса - есть или нет. В шаблон оно приходит в виде значение 1 или 0 - соответственно установлено ли начение или нет. Но вот как его показать пользователю решение принимает дизайнер. Кто-то захочет вывести "Телефон: есть", а кто-то, как вы, захочет обозначить наличие тлефона картинкой. Именно поэтому и выдается именно 1\0 значение, что бы не сковывать дизайнера и обеспечить некоторую гибкость. А внося поле в модель таблицы вы гарантируете, что это поле попадет в шаблон, но никоим образом не обуславливаете в каком виде оно отобразится - этим занимается шаблон.

Это скорее не жиквери, это сss стили кривят. Возможно бутстрап сует палки в колеса. На каждый ваш выпадающий список крепится свойство overflow:hidden, которое обрезает область элемента его границами. Поэтому все подпункты открываются, то оказываются вне этих границ и их не видно. Надо попробовать подключить предыдущую версию бутстрапа. Если неоткрывание пропадет, то надо подбирать фиксы к нему.

Если они есть в модели таблицы data, то аналогично {if $data.internet.value != ''} пользуете {if $data.какое_то_другое_поле.value != ''} Если их в модели еще нет, то через Редактор Форм создаете эти поля, заполняете через админку или иным способом и возвращаетесь к предыдущему преложению.