abushyk

1. Открыываете файл шаблона куда нужно вставить. Обычно это footer.tpl 2. Берем код метрики и вставляем его туда предварительно окружив {literal} тут код {/literal} 3. Сохраняем. Если все это сделано, а код и далее "не найден" значит проблема не с самой вставкой, а 1. ошибка в коде 2. ошибка с выбором шаблона - не все шаблоны доступны на всех страницах

У меня такое впечатление, что не удается создать выгружаемый файл на сервере (возможно из-за прав на запись или отсутствия конечной папки) и поэтому функция создающая файл выдает ошибку. Посмотрите существует ли физически папка /cache/upl/ в вашем сайте.

1. Файл /template/frontend/realia/main/main.php 2. Внутри class frontend_main extends SiteBill_Krascap { ... } добавляем function getTopicFullInfo ( $topic_id ) {$r=parent::getTopicFullInfo($topic_id);if(!empty($r)){require_once(SITEBILL_DOCUMENT_ROOT.'/apps/system/lib/admin/structure/structure_manager.php');$Structure_Manager = new Structure_Manager();$category_structure = $Structure_Manager->loadCategoryStructure();$params['topic_id']= $topic_id;$r['name']=$this->get_category_breadcrumbs_string( $params, $category_structure );}return $r;}3. Должно сработать. Если не получится, пишите, помогу разобраться. ПС. Вывод в названии категории именно названия категории, а не цепочки вложенности, позволяет более четко определить цель страницы и не замусоривать ее лишним текстом. Все пояснения относительно контента должны быть в описании, а заголовок только однозначно позиционировать информацию на странице. Заголовок не должен быть длинным, что неизбежно при большой вложенности. Чем больше у вас на сайте разных отличающихся друг от друга заголовков - тем лучше. Цепочка вложенности и ее ветвистость может и должна прослеживаться в хлебных крошках (которые являются частью UI пользователя), но не тайтлах (которые ориентированны в первую очередь на робота).

Нет. База остается та же самая. Алиасы все учитывают текущее положение сайта в папке он или нет. Т.е., если вы все поднимете на уровень вверх и в setting.ini смените параметр estate_folder на пустое значение, то все должно работать.

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

Так может просто вынять сайтбилль из папки dom и положить в корневую папку?

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

Для ЯВыгрузки я делал обновление приложения до версии 1.3.9. Суть обновления состояла в том, что вся генерация выгрузки разбита на более примитивные функции. Указывая в настройках приложения алиас выгрузки отличный от стандартного, вы переводите выгрузку на этот новый режим. Тогда у вас есть возможность локализации кода выгрузки и изменения отдельных его функций, например принципа формирования блока географии по своим требованиям и данным.

Именно в data. Каждая модель в Редакторе формы представляет собой заготовку под форму. Поэтому все увязки зависимостей должны применяться именно к элементам модели конкретной формы. Если вам нужны эти зависимости на форме добавления или поиска (что одно и то же, так как строятся они по одной и той же модели data), значит указать их нужно на полях таблицы data. Если например вы заведете какую-то свою таблицу, где будут фигурировать подобные поля географии и вам будут нужны зависимости на ней, их нужно будет указать уже на полях упомянутой таблицы.

А что, 13 секунд - это какой-то эталон длинны для проморолика?

Для большего удобства с помощью Менеджера линков можно вынести на отдельный красивый адрес. Просто Иное - это то, для чего не нашлось подходящего типа. А Дачи - вполне нормальный тип. Зачем в него примешивать еще что-то неопределенное иное? Там ведь может все, что угодно оказаться в "ином".

Я бы еще от такой скользкой штуки как "посуточная" избавился бы. Посуточно ведь может сдаваться все, что угодно. И квартира, и дом, и комната. И вот у нас уже кустится очередное поддерево на все эти случаи. Просто бы добавил галочку "Сдается посуточно" и отмечал бы ее там, где нужно указать, что аренда не только долгосрочка. А в остальном, если вам нравится и удобно, значит норм)) Это сейчас скорее модно. Пункт "Дачи, иное" - это уже ересь))) С таким успехом могли назвать весь его "Иное" без упоминания дач)))

Я вообще не понимаю смысла в типе жилья Новостройка. Может быть квартира, студия, апартаменты, паркоместо в подземной парковке. В том числе и в новостроящемся\новопостроенном здании. Но они все равно останутся квартирой или апартаментами. Тут налицо примешивание в обычные типы недвижимости модных штучек либо признака здания. Вот если бы продавались новостройки как целые здания-коробки - вопросов нет. Наверное нет "правильной" точки зрения. Либо опираться на какие-то правила-документы-стандарты типа этого http://rway.ru/Upload/bulletines/233/5_Repin_160-169_233.pdf

/template/frontend/realia/main.tpl ...{include file=$_layout}{if $REQUESTURIPATH == '' }... тут оно ...{if}...

Пробуем понять это - 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 и это - http://www.etown.ru/s/topic/782-%D0%BF%D0%B5%D1%81%D0%BE%D1%87%D0%BD%D0%B8%D1%86%D0%B0-%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D0%B5-%D1%81%D1%83%D1%89%D0%BD%D0%BE%D1%81%D1%82%D0%B8-%D0%B8-%D1%81%D0%B2%D1%8F%D0%B7%D0%B0%D0%BD/ Если будут вопросы, спрашиваем. В принципе да. С помощью стилей например. Тут нужно смотреть каждый конкретный случай

Я бы наоборот разъединял, если эти типы в контексте данных сайта имеют значительные различия. Но если у вас по набору данных что коттедж, что дом особо не отличаются, то можно и слить. Оптимально - разделы не должны быть избыточными. Так довольно дико выглядит типизация по комнатности - 1-комнатные, 2-комнатные,... вместо просто "квартира". Поскольку свойство комнатности кодируется отдельным полем - в таком случае наблюдается просто избыточность однотипного понятия по побочному признаку. Но вместе с тем, не следует делать разделы раздутыми. При наличии возможности типизации комерческогой недвиги по типам "офисное", "складское" и т.д. тип "Коммерческая" является обобщающим. Но употребленный самостоятельно, без последующего его дробления на мелкие конкретные типы он малополезен в большинстве случаев. Все зависит от контекста. Если под Новостройки понимать "жилье в построенных новостройках" (ну вот решил владелец так выделить в силу каких-то соображений - привлекательность нового строения(например, в новостройках тараканы большая редкость), элитность, которая часто присуща новостройкам(не серийым)), то почему нет? Если же понимать как "еще строящиеся дома", тогда нет. Все это условности и сильно зависят от интерпретации.

Дмитрий имеет в виду, что каждое объявление имеет ряд ключевых признаков. Грубо говоря это: 1. тип недвижимости - квартира, дом, участок,... либо если огрублять, то жилая, коммерческая,... 2. география. одно или комплекс полей описывающих географическое положение (страна, город, улица,...) 3. тип сделки с объектом - продажа, аренда. Структура в исходном виде после установки, по своей сути, является не только рубрикатором, но и синтезом типа недвижимости и типа операции. Это пошло еще издревле и, в каких-то ситуация оправдано. Но в целом, вести отдельный признак типа операции зачастую более оправдано и логично. Например нет дублирования типов в недвижимости как в структурах, где верхним пунктом являются Аренда и Продажа.

Опция смены логотипа через настройки поддерживается не всеми шаблонами. В Реалии шаблон меняется правкой файла /template/frontend/realia/header_contact_add.tpl в котором в 14 строке нужно указать путь к файлу с нужным лого. Или просто заменить файл /template/frontend/realia/img/logo.png своим.

#simple_search {color: white}добавить в template/frontend/realto/css/style.css

В district ставить районы области не имеет смысла, так как внутренне идет расчет, что это поле содержит разделы именно населенного пункта (районы, микрорайоны). Помещение туда иных по смыслу административных единиц вызовет путаницу. Поскольку в данный момент у нас получается градоориентированная иерархическая структура, в отличии от реального административного деления, то вариантом может быть размещение в city именно городов\населенных пунктов. В district именно административных районов городов. Так как locality-name является общим и одинаковым полем для всех типов и формируется из city, оно сформируется верно. Единственным недочетом будет то, то для сельской недвижимости придется указывать "близлежащий населенный пункт", а не просто район области, например. Тогда уточняющее положение может быть указано в описании либо геокоординатами (что логичнее). Содержимое тега district в этом случае останется обязательным только для городской недвижимости. Если в модели в district у вас будут лежать административные районы городов, тогда концептуальной проблемы не будет - можно смело в выгрузке $rs.='<sub-locality-name>'.self::symbolsClear($data_item['district']).'</sub-locality-name>'."\n";сменить на $rs.='<district>'.self::symbolsClear($data_item['district']).'</district>'."\n";Т.е. для районированных городов туда попадет район, а для мелких, этот тег будет отсутствовать, что будет соответствовать спецификации. Если же в district у вас не только административные районы, но и традиционные, например, тогда с формальной точки зрения это будет не совсем верно, но яндекс обуславливает именно наличие этого поля, а не форму его допустимого содержимого, поэтоу с ольшой долей вероятности может проглотить и это. Иного, более полно завязанного на существующем административном делении, способа увязки в данный момент я не вижу. По крайней мере способа, где не нужно было бы создавать свой отдельный обработчик.

Я только что попробовал в ЛК, картинки присоединились. Вы пробовали через админку? Попробуйте зайти на тестовом аккаунте и попробовать через ЛК, что бы понять проблема ли в точке доступа или нет. Картинки пропали, так как эти два загрузчика отличаются по принципу работы и хранения изображений. Для того, что бы новый загрузчик подхватил картинки старого, их нужно перегнать с помощью приложения Toolbox (посмотрите в списке приложений, есть ли оно уже у вас). Перед переносом следует: 1. Сделать резервную копию БД и сайта. 2. Проставить параметры для поля типа uploads Это не обязательно, но желательно А уже после этого в Toolbox выполнить Из Uploadify в Uploads указав системное имя поля типа uploads Следует помнить, что перенесутся из старого поля в новое изображения только для тех объявлений, для которых вы еще не загрузили в новое поле картинки! ПС. На вашем сайте мы делали много кастомных решений. Может иметь место ситуация, что в связи с этим изменениями некоторые новые решения не будут подхвачены автоматически. Надо будет проверить код. У вас кажется есть мой скап или аська - постучите.

Сообщения на почту с поданных заявок, в том числе и формы Написать нам в футере, отправляются по следующему принципу: формируется пул адресов из: 1. адреса указанного в поле Почта аккаунта администратора. 2. набора адресов почт пользователей у которых отмечено поле notify в данных аккаунта (при наличии такового). Т.е. на почту администратора должно уходить как минимум.

C версии twitter 1.2.3 постинг другими юзерами уже добавлен через настроечный параметр.

Это если пользоваться "в лоб" как прописано в шаблоне. Но, если проявить некоторую извращенность, то можно переписать условия на примерно такие {if $gi.premium_status==1 && $gi.bold_status==1 && $gi.vip_status==1}superclass{/if}{if $gi.premium_status==0 && $gi.bold_status==1 && $gi.vip_status==1}superclass2{/if}...и так под каждый вариант Либо (что оптимальнее) {if $gi.premium_status==1}p{else}_{/if}{if $gi.bold_status==1}b{else}_{/if}{if $gi.vip_status==1}v{else}_{/if} и получить 9 уникальных классов вида pbvpb_p_ __b__bv_ _ _....И просто прописать стили.

Маленькое замечание по выделению в сетке вип\премиум\выделенных. Эти три статуса могут встречаться как отдельно, так и все вместе на одном объявлении - технически это не запрещено. Поэтому оптимально, что бы каждый из признаков вип, премиум и болд имели свой стиль отметки. Например премиум - бекграундом, вип - рамочкой, болд - утолщением заголовка. Тогда будет возможность отобразить несколько этих свойств на одном объявлении одновременно.