Leaderboard

1. Предистория Допустим мы имеем базовый сайт на сайтбилле. У нас есть стандартная модель квартиры-недвижимости со всякими Цена, Площадь и прочими свойствами по вкусу. И вот, в один прекрасный момент, мы решили заняться торговлей квартирами в новостройках. А новостройки эти у нас зачастую представлены не отдельными зданиями, а целыми комплексами зданий, которые в свою очередь разбиты на секции. 2. Анализ. Сначала разберемся со структурой. Самый простой вариант - мы решили еализовывать каждую квартиру в виде отдельного объекта. Например, если в ЖК "Элитный" у нас есть корпус А, а в нем секция I и в этой секции, грубо говоря, 15 квартир одной планировки, но некоторые на разных этажах, мы будем считать, что каждая квартира, даже одинаковой планировки - является одним объектом. Иными словами, мы не делаем группировок по типам, а ведем каждую квартиру отдельно. Это дает нам некоторую гибкость, так как квартиры на крайних этажах могут иметь меньшую цену в отличии от одноплановых с ними, на остальных этажах. Так же, из плюсов то, что мы можем задать какие-то особенности поквартирно, даже не смотря на то, что они одноплановые. Особенно это касается, когда квартиры продаются не в сыром виде, а меблированные или с финишной отделкой. Либо учесть иные особенности каждой квартиры. Из минусов такого подхода то, что если секция у нас 9-ти этажная с 4 квартирами на этаж, то на секцию получается 36 объектов. И дальше в геометрической прогрессии в зависимости от количества секций в корпусе и корпусов в ЖК. Соответственно, логично предположить, что кроме обычных для недвижимости параметров (цена, площадь, этаж,и т.д.) нам придется снабдить модель недвижимости дополнительными параметрами, устанавливающими ее привязку к конкретному положению в разрезе ЖК - конкретный ЖК, корпус ЖК, секция корпуса ЖК. И так же очевидно, что при заполнении формы эти параметры должны бы быть связаны цепочкой, как то при выборе отдельного ЖК, мы должны получить под выбор список корпусов только этого ЖК, что бы не рыскать в длиннющем списке всех корпусов. Аналогино и с секциями. 3. Инструментарий. Для реализации нам понадобятся свежие приложения system, admin, table, customentity. Привлекать готовые приложения типа "Жилые комплексы" мы не будем. Из настроек нам будет необходимо включить параметр Настройки - Дополнительно - Off system Ajax. Данная опция выключает автоматические связки между зависимыми элементами и предоставляет нам полный контроль над определением своих зависимостей. Из почитать - http://wiki.sitebill.ru/index.php?title=%D0%A1%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5_%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D1%8B 4. Подготовка дополнительных сущностей. Если мы должны иметь возможность выбрать корпус, ЖК и секцию, значит у нас где-то должны быть списки этих значений. В Сайтбилле, для организации списков значений существует два типа полей - select_box и selectbox_by_query. Первый нам не подходит, так как не поддерживает организацию наследия. Т.е. штатными средствами этого элемента мы можем задать набор его вариантов значений, но не можем указать какие-то связующие ключи с другим элементом. Второй, поскольку хранится в БД в виде отдельной таблицы, вполне на это способен. Но для его использования необходима соответствующая таблица в БД. В нашем случае таблиц будет три - таблица ЖК, таблица корпусов и секций корпусов. Что бы избавить себя от рутинной работы по наполнению этих данных через phpMyAdmin создадим соответствующие таблицы в Редакторе форм. 4.1. Жилые комплексы. Для ЖК - это таблица czhilkom с полями czhilcom_id (primary_key) и name (safe_string). Создав таблицу и наполнив ее элементами, нажимаем кнопку Создать таблицу. Теперь таблица ЖК существует физически в БД. Надо наполнить ее какими-то жилыми комплексами. Для того, что бы получить доступ к работе с этой сущность через стандартную админку, воспользуемся приложением Пользовательские сущности. Для начала проверим, что приложение установлено. Для этого в админке переходим по адресу /admin/index.php?action=customentity&do=install При переходе по нему, в случае отсутствия необходимых таблиц для работы приложения, они будут созданы. После этого возвращаемся в Редактор форм и в заголовке таблицы czhilkom ищем кнопку со завездочкой Эта кнопка отвечает за создание мини-обработчика для сущности, у которой нет штатного обработчика (в виде встроенного модуля или стандартного\стороннего приложения). NB. Попытка создать этой кнопкой обработчик для встроенных сущностей, как Город, Район или для тех у которых есть приложения - Баннеры, Новости - ни к чему не приведет. После нажатия кнопки Создания обработчика мы увидим следующее окно где в поле Название вам нужно ввести вменяемое название для вашего обработчика, что бы вы знали к чему он относится. Введем например Жилой комплекс и нажмем Создать. После перезагрузки страницы в верху, возле кнопки раскрытия списка приложений мы получим дополнительную кнопку Пользовательские, а под ней и наше квази приложение Жилой комплекс Если перейти по предложенной ссылке, вы получите минималистический инструмент для управления вашими ЖК где вы можете добавить ЖК в список, изменить существующий или удалить ненужный. Приложение не следит за целостностью, т.е. если вы удаляете ЖК, то об удалении соответствующих зависимых корпусов и секций вам так же придется позаботиться самому. Не надейтесь на возможность реализации таким способом каких-то "творческих вывихов" - это исключительно инструмент для обеспечения удобства. Для полноценной работы с такими сущностями, как разделение их по пользователям с возможностью редактирования последними, организация страницы, например конкретного ЖК, шаблонизация необходимо создавать полноценное приложение. Для наших целей добавим два ЖК - Элитный и Морской с помощью кнопки Добавить запись Процесс, как вы можете заметить, вполне привычный и не должен вызвать трудностей 4.1. Корпуса. Создание таблицы корпусов абсолютно ничем не отличается от создания таблицы ЖК кроме того, что у корпусов есть зависимость от ЖК. Например ЖК Элитный имеет два корпуса - Корпус А и Корпус Б. Тогда модель корпуса (ckorps) будет состоять из полей Поле czhilcom_id является обычным полем селектбокса подбирающим данныеиз внешней таблицы, в данном случае из таблицы czhilcom Простыня под спойлером Дальше все по алгоритму - создали таблицу в Редакторе форм, наполнили полями, создали физическую таблицу, зарегистрировали обработчик. Из Пользовательских переходим в Корпуса добавляем Названия сущностей рекомендую давать расширенные - с включением родительского описания. Так как обработчик весьма прост, то особых способов отличить Корпус А от ЖК Элитный и Корпус А от ЖК Морской у вас не будет. В результате мы получаем нечто похожее на

Давно пора создать отдельную ветку на форуме для обсуждения похожей тематики. Да простит меня админ но своими словами этого не описать, а по ссылке не каждый перейдет. Это должен знать каждый человек который хочет что бы его сайт быстро продвигался в сети интернет. Начнем. Факторы, влияющие на поисковое продвижение сайтов в Google Ключевые слова: 1. url ключевые слова (первое и второе слово является наиболее ценным ……) 2. Ключевые слова в доменном имени (Преимущество для англоязычных сайтов) 3. Тег title описание документа (5-9 слов, не должен содержать специальных символов). 4. Description — тег описания страницы (не более 200 символов, этот показатель в настоящее время Google больше не рассматривается в качестве важного параметра, однако он все еще часто используются другими ПС). 5. Keywords тег ключевых слов, (менее 10 слов, отдельные ключевые слова должны появляться в теле страницы от двух и более раз, чтобы быть эффективными, в противном случае они могут быть расценены как спам.) По заявлениям руководства Google ключевые слова в этом теге более не учитываться поисковиком. 6. Ключевые слова в тексте страницы плотностью 5 — 20% (все ключевые слова /всего слов). 7. Одинарная плотность ключевых слов 1 — 6% (каждое ключевое слово / всего слов). 8. Теги H1, H2, H3 с ключевыми словами. 9. Ключевые слова выделенные жирным шрифтом или курсивом. 10. Текст в таблицах. 11. Ключевые слова в порядочном списке. 12. Ключевые слова в тексте Alt в атрибутах графики. 13. Ключевыми словама во внешних ссылках (якорный текст). Меню — внутренние ссылки разделов: 14. Ключевые слова в ссылках на внутренние страницы. 15. Все внутренние ссылки должны быть действительными. 16. Древовидная структура меню для любой страницы, которая не превышает 4-х уровней вложенности. 17. Наличие навигации в низу страницы. Навигация — внешние ссылки раздела: 18. Ключевые слова на старице сопоставляются с внешними ссылками. 19. Якорный текст внешней ссылки. 20. Важны постоянные ссылки. 21. Внешние ссылки должны быть действительными. 22. Менее 100 внешних ссылок на страницу (в Google говорят, что к сайтам размещающим более 100 ссылок на странице применяются фильтры.) Благоприятные факторы влияющие на Google Rank (PR). 24. Уровни домена, (Edu является самым авторитетным, за которым следует Org, и. Com. Поскольку они содержат много спама, Google будет подвергаться эти сайты строгому анализу). 25. Размер текста на странице (не более 100К и не менее 1К) 26.URL дефис (самое лучшее, 1 или 2, если еще четыре будут считаться спамом, 10 скорее всего, будет понижен в выдачи). 27. Важно регулярное обновление страниц. 28. Время жизни страницы (чем дольше страница существует без изменений тем более Google ей доверяет). 29. Скорость обновления ссылок на страницах сайта. (Google не любит страницы с часто обновляемыми внешними ссылками). 30. Частота обновления (Refresh Rate = пауки сканируют частоту обновления). 31. Page Theme 32. Ключевые слова, синонимы ….. 33. Семантические ассоциации (синонимы, и так далее …) 34. Общая тематика сайта. (Наличие семантического ядра сайта). 35. Длинна URL (как можно меньше, максимально допустимый размер 2000 символов, предпочтительно до 100 символов или меньше). 36. Объем сайта (Google больше ценит крупные сайты с хорошо организованной навигацией и эффективной и понятной структурой). 37. Возраст сайта (Google считает что чем старше домен тем лучше). 38. Возраст отдельных страниц сайта. Обратные ссылки: 39. Общее число обратных ссылок. 40. Обратные ссылки на страницы с PR> 4 41. Каждая страница сайта учитывается при подсчете PR. 42. Небольшое число внешних ссылок. 43. Тематические ссылки. Каталоги: 45. Регистрация в каталоге DMOZ. 46. Наличие в каталоге Yahoo. 47. Тематические каталоги. 48. Сайт стабильно обновляется. (Сам факт регулярного обновления содержания положительно оценивается ПС). 49. Наличие карты сайта. Поведение пользователей: 50. Общий объем трафика с поисковых систем. 51. Число переходов по внутренним страницам. 52. Количество времени проведенного пользователями на вашем сайте. 53. Количество закладок и подписчиков вашего сайта. 54. Как часто к вам возвращаются ваши посетители. 55. Возраст домена (5 лет считается хорошим показателем). Неблагоприятные факторы, влияющие на Google Rank (PR). 56. В образе формы имеются текстовые описания, но текста в письменном описании не очень. 57. Зеркало сайта. 58. Пере оптимизация страниц. 59. Плохая связь с сайтом. 60. Перенаправление страницы на другой адрес или обновление метатегов. 61. Не цензурные слова. 62. Фразы порнографического содержания. 63. Чрезмерное количество взаимных ссылок (если на вашем домене есть еще сайты, то ваши взаимные ссылки учитываться не будут). 64. Текст закрытый изображениями. 65. Многократное повторение ключевых слов (затруднение индексации). 66. Ключевые слова разрежения (если на странице высокий процент нерелевантных слов к заголовку). 67. Слишком частое изменения содержания страниц. 68. Частое обновление текста якоря. 69. Использование динамических адресов (это дефекты поисковых систем, по возможности не стоит использовать страницы с динамическими адресами). 70. Слишком много JS кода (не используйте скрытые ссылки и функции перенаправления). 71. Flash страницы, пауки поисковых систем не могут правильно сканировать содержание Flash сайтов. (Используете технологию flash как вспомогательный инструмент при создании сайта.) 72. Одна пиксельные ссылки (будет рассматриваться как скрытый Link) 73. Скрытый текст (текст цвета фоны). 74. Doorway страниц (страницы с автоматически сформированным текстом, синонимизированным или обработанным иначе). 75. Дублирование текстов (Google обычно выбирает наиболее ранний текст а все аналоги значительно опускает в поисковой выдаче). 76. Требование к html коду, он должен соответствовать стандарту W3C. 77. Покупные ссылки. (Ситуация с продажей ссылок с сайта может привести к обнулению pr). 78. Ссылки, ведущие на несуществующую старицу или страницу с ошибкой. 79. Нерелевантный текст ссылки к содержанию страницы, на которую она ссылается. 80. Нерелевантное название страницы (тег title) к содержанию страницы. 81. Многократные запросы с хостинга к поисковику Google может привести к бану. 82. Качество сервера. Имеет значение, насколько сервер надежен и как часто случаются сбои в его работе. 83. Отсутствие сайта и его страниц в крупнейших поисковых системах, в том числе и национальных, если их доля трафика значительна. 84. Большое количество взаимных ссылок с другими сайтами. Вроде автор ни чего не упустил P.S. http://www.promolab.ru/free/ простенький, но удобный сервис анализа страницы на предмет ее видимости поисковой машиной, ключевых слов и заголовков

Вот это кажется как раз ваш случай http://www.etown.ru/s/topic/823-после-обнавления-картинки-стали-не-кликабельн/?p=7457

1. В принципе, вывод маркера, при указанных координатах, никоим образом не связан с другими полями. Нужно смотреть конкретно. 2. "Должным образом не выводится" - можно подробнее? В стилевом смысле или положение не то? 3. То же вроде бы не связанные события. Шаблон агенси? 4. Первый способ - убрать вывод валюты в шаблоне сетки. Если указание валюты, как таковое не нужно, либо оно подразумевается иным способом - можно воспользоваться именно этим способом. Второй способ - подключить Использование нескольких валют, в Менеджере валют обозначить используемые валюты, снабдить модель объявления полем для фиксации валюты. Назначить объявлениям конкретную валюту. Тогда вывод валюты будет укащзани именно таким, как его укажут для конкретного объявления и не придется править шаблон. 5. Теоретически: а) дополняем модель объявления признаком Долгосрочная аренда (чекбокс, например) б) вводим дополнительное поле под цену. Например уже существующую считаем ценой посуточной, а долгосрочную добавляем. в) реализуем в поиске алгоритм поиска (тут нужны конкретные установки, что бы что-то конкретное написать) 5 еще один. Возможно была бы нужна, но маловероятно, что могла бы быть. 6. Тут без проблем. Согласен. 7. Будет. По срокам не уточню)) Оффтоп: на каком основании вы бы давали разные маркеры разным объектам? По какому признаку?

1. /template/frontend/agency.pay/main/main.php находим if ( preg_match('/\/register/', $_SERVER['REQUEST_URI']) ) {...}сразу после if ( preg_match('/\/register/', $_SERVER['REQUEST_URI']) ) { добавляем $this->template->assert('hide_search_form', 1);2. /template/frontend/agency.pay/main.tpl Находим {if !$is_account}...{include file="search_form.tpl"}...{/if}и первую строку меняем на {if !$is_account && $hide_search_form!=1} теперь форма поиска будет отображаться на всех страницах, кроме ЛК и регистрации.

Попробуйте установить в Настройки - Тип списка объявлений значение thumbs

Ага, забыл один момент. В шаблоне, где включается карта RM.initJSON('YMapsID', loc_objects, map_type, {scrollZoom: false, minimap: false, defaultZoom: 4}); добавьте еще вид карты в опциях RM.initJSON('YMapsID', loc_objects, map_type, {scrollZoom: false, minimap: false, defaultZoom: 4, yandexMapType: 'yandex#map'}); если этот параметр не указан, то карта строится в виде народной.

Таблетка 1. Если в шаблоне есть файл /main/main.php 1.1. В этом файле есть функция isRealtyDetected в ней находим кусочек header('HTTP/1.1 301 Moved Permanently');header('Location: '.$new_location);и после него доставляем exit();1.2. Если функции нет, то в функции main() находим блок if ( preg_match('/realty/', $_SERVER['REQUEST_URI']) ) { ...}и в нем аналогичный кусок с командой header. Точно так же после этих строк добавляем exit();2. Файла /main/main.php в шаблоне нет. Открываем файл /apps/system/lib/sitebill_krascap.php, находим в нем функцию main() поступаем аналогично пункту 1.2

Продолжаю отдельными постами, так как исчерпал лимит на картинки в одном сообщении )) 4.1. Секции. Не буду давать расширенного описания, скажу только, что все идентично как для корпусов. Таблица csection и поля csection_id, name, ckorps_id (по таблице ckorps) В принципе для секций можно было бы установить двойную зависимость - указывать принадлежность секции к корпусу и к ЖК. Для некоторых случаев это оправдано (особенено если делается полноценное приложение), но в нашем случае, когда необходимо лишь поразграничивать принадлежности и сам корпус и ЖК будет указан в свойствах недвижимости, такая связка будет избыточной. В итоге 5. Внедрение в недвижимость Сущности у нас готовы, можно приступать к привязке их на объявление. Нам необходимо добавить три свойства в нашу таблицу data - ЖК, Корпус и Секция. Все они будут добавляться полями типа select_by_query, что бы мы могли сформировать их списки в элементах выбора из соответствующих таблиц. Носить имена будут эти элементы czhilcom_id, ckorps_id и csection_id Если теперь мы перейдем в форму добавления объявления мы увидим, что наши новые три поля уютно прописались в форме в виде привычных списков выбора. Но если их поразворачивать, то вы увидите, что они вмещают все варианты из своих таблиц и не реагируют на состояние "родительского" элемента. Например выбор ЖК никак не отражается на содержимом списка корпусов. Приступаем к наладке связей. 6. Связывание Основой для связывания служит принцип связанных элементов формы - http://wiki.sitebill.ru/index.php?title=%D0%A1%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5_%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D1%8B Нам необходимо в рамках одной формы указать элементам на какие другие элементы они влияют в форме и от каких зависят. Например - ЖК. От состояния этого элемента зависит возможный список выбора в элементе Корпуса. Эта зависимость описывается какЭто значит, что элемент, в котором мы выбираем название ЖК связан с элементом с системным именем ckorps_id (элемент выбора Корпуса ЖК), а ключем, который внутри Корпуса соответствует жилому корпусу является значение из поля czhilcom_id модели Корпуса. Если взлянете выше, то это значение в модели Корпуса у нас является идентификатором ЖК, к которому привязан Корпус.Больше ЖК у нас ни на что не влияет, потому и других параметров нет. Далее Корпус. Корпус, аналогично ЖК влияет на "следующий" элемент - Секцию. Но, кроме этого, он еще должен знать от какого элемента зависит сам - это необходимо для формирования адекватного списка значений элемента Корпус, но не тогда, когда сделан выбор конкретного ЖК, а при загрузке формы. Например, если вы открыли на редактирование объявление в котором ЖК был указан как Элитный, тогда в списке Корпусов вполне ожидаемо окажется уже готовый список корпусо ЖК Элитный. linked - описывает зависмость когда элемент влияет на что-то.depended - когда что-то влияет на элемент И, наконец, Секция. Самый простой элемент. Он ни на что не влияет, но на него влияет Корпус. Что и видно из параметров. Нет ничего страшного, если вы ничего не поняли про связи с первого раза. Это нормально, Я гарантирую это. Если теперь вы попробуете загрузить форму добавления объявления, вы видите, что у вас доступен на выбор только элемент ЖК, а остальные будут подгружены только после выбора соответствующего родительского. Для того, что бы увидеть этот эффект в Настройках необходимо включить параметр Настройки - Дополнительно - Off system Ajax 7. Эпилог Ай, у меня не работают элементы выбора географии. Что делать?... Тут все ожидаемо. Изначально принцип связанных элементов предназначался как-раз для географических элементов, что бы вывести из кода движка жесткие зависимости Страна-Регион-Город-Район\Улица и иметь более широкую возможность настройки своих связей. А так же, иметь возможность введения промежуточных элементов (Страна-Регион-Субрегион-Город), которые разрывали бы существующие связи, заложенные в код Сайтбилля. Именно поэтому опция Off system Ajax отрубает всю систему заложенных связей. Возможно это слишком кардинально и стоило бы предусмотреть ступенчатую систему, когда подключение пользовательских связанных элементов регулировалось бы одной настройкой, а отключение привычной связки от Страны к Улице другой. На данный момент четкого мнения у меня пока нет. Для себя я решил эту проблему навеской связей на географические элементы в виде, аналогичном системным правилам. Т.е.country_idlinked region_id,country_id region_idlinked city_id,region_iddepended country_id city_idlinked street_id,city_id;district_id,city_iddepended region_id district_idlinked mkrn_id,district_iddepended city_id street_iddepended city_id mkrn_iddepended district_id 8. Offtop С другой стороны, даже этот способ немного избыточен. Если Город является дочерним к Региону, а Регион к Стране, то хранение всех трех значений для объявления - это "лишние" данные, хотя при организации поиска они весьма кстати. Суть в том, что географические данные вполне возможно хранить в виде, схожем со структурой и получать к ним доступ более "человечным" путемНо в этом случае остается так же много вопросов связанных с совместимостью с многими приложениями, принципом организации смой геоструктуры (ведь если заструктурить географию от страны до улиц - это может стать неподъемным грузом, а если закончить городом, то не совсем понятно, как вести связь дальше к улицам, которые должны таки быть привязаны к городам или чему-то наследному от них). В общем идея у нас полно, была бы возможность все реализовать)

Как бэ так )