abushyk

Завтра загляну к вам посмотрю. Скорее всего где-то за 50-м объявлением в тексте встретился недопустимый для xml entity типа — и т.д.

Должна же быть некоторая плата за некоторую универсальность? Вот с этого момента, как вы поняли, что запросов много, а некоторый функционал вам не нужен, и начинается реальная работа над сайтом) Есть много чего, что вам просто не нужно или не критично. Все это нужно глушить. Самый простой пример - сбор данных для формы поиска - получение макс цены для слайдера, крайних этажей и т.д. В частных случаях это либо не нужно, либо вполне может класться в куки или сессию, после первой выборки. Аналогично Новые, Спецпредложения (которые ну нафиг никому не упало обновлять и перемешивать каждый F5, достаточно даже 1 раз в час). Всякие верхние и нижние навигационные меню, которые можно собирать до готового html вообще раз в год, а не постоянно опрашивать БД на их выборку и генерацию. Я думаю идея в целом понятна.

Если передать в запросе переменную district_id=N, то искать будет именно по району с ид=N. Если же передать в запросе district_id[]=N1&district_id[]=N2&district_id[]=N3 то искать будет во всех районах от N1 до N3. Сам алгоритм поиска существует. Проблема в том, что нет нормального элемента, который нарисует на форме поиска нечто, что позволит выбрать несколько районов.

В карточке в /template/frontend/realia/realty_view.tpl перед {elseif $data_item.name eq "fio"}добавляем {elseif $data_item.name eq "currency_id"}{elseif $data_item.name eq "price"}{if intval($data_item.value)!=0}<tr><th>{$data_item.title}</th><td>{$data_item.value|number_format:0:",":" "}{if $data.currency_id.value!=0} {$data.currency_id.value_string}{/if}</td></tr>{/if}

/template/frontend/agency/realty_grid.tpl Вывод фотки {if $grid_items[i].img != '' } <a href="{$grid_items[i].href}"><img src="{$estate_folder}/img/data/{$grid_items[i].img[0].preview}" width="50" class="previewi"></a> {/if}меняем на {if $grid_items[i].img != '' } <a href="{$grid_items[i].href}"><img src="{$estate_folder}/img/data/{$grid_items[i].img[0].preview}" width="50" class="previewi"></a> {else}<a href="{$grid_items[i].href}"><img src="{$estate_folder}/img/no_foto.png" width="50" class="previewi"></a> {/if}

Если не тяжело, запишите на что именно ругается, что бы я примерно ориентировался где еще хвосты могли остаться.

http://my.digitalwerkstatt.ru/files/captcha.zip вот ссылка на капчегенератор который работает от PDO. Заменив им мускул_коннект уже будет не нужен.

В тело сайта нужно вставить код формы поиска - куда слова вводить. например в /template/frontend/realia/main.tpl (условно) после <div id="content"> ставим код формы. Если в этом коде присутствует значек фигурных кавычек "{" или "}" то всю эту вставку нужно обернуть в {literal} {/literal} Далее нужно смотреть по факту. Куда будут отображаться результаты поиска. Если как на форуме во всплывалку, то норм. Если оно может как Яндекс выдавать на отдельную страницу, то тут нужно будет посмотреть, возможно создать статическую страницу со своим шаблоном, куда вписать код приемника.

Там же в 48 строке оно скорее всего и есть. С большой долей вероятности это одно из последних подключений через mysql. Просто мы не можем изменить этот файл при обновлении, так как он относится к приватным файлам.

Данная ошибка говорит не проблеме с вотермарком, а о проблеме с картинкой загружаемой. Что-то с ней пошло не так.

phpmyadmin - это такой мощный продукт, который может даже больше самого установочного пака движка)) Он не включается в движек сайта ибо не нужен. Так как обычно он, или его аналог, всегда есть на самом хостинге в панели управления хостингом.

Нет, похоже это я увлекся добором до нужного числа и забыл поставить ограничение сверху))

В принципе возможно. В данный момент я выношу конфиг в глобальную сущность и делаю возможность подключения поверх него субдоменальных конфигов. Например на domen.ru работает стандартный конфиг из БД, а на субдомене a1.domen.ru включается стандартный конфиг, но поверх него накладывается частично набор кастомных параметров. В этом субдоменальном конфига, например, я переопределяю конфигину template. В результате на domen.ru у меня идет отображение в agency-шаблоне, а на a1.domen.ru в реалия-шаблоне при прочих равных настройках. Таким образом можно будет переопределить любой параметр указываемый в конфиге. Дальше стоит проблема распаралеливания данных. Просто сменить тему мало, я могу хотеть показывать на убдомене только объявки конкретного юзера, или некоей локации. А может сделать ограничение по цене. Вот с такими параметрами пока не ясно и я еще пробую. В общем работы ведутся, но дать сейчас что-то вменяемое я не готов. Хороша ложка к обеду. Если в наличии десятки тысяч объявлений экспорт-импорт между зеркалами может быть уже не приемлемым по причинам а) объемности самих экспортов (включая проблему экспорта-импорта графического материала), б) сложности синхронизации неполных наборов данных (например мне не нужен слепок один в один, а только фильтрованный набор) в) вообще синхронизация в больших объемах нудная штука г) дисковое пространство - каждая копия будет занимать место д) проблема сквозной авторизации, когда НУЖНО что бы пользователи имели доступ ко всем субдоменам, а не на каждом отдельный пароль-логин Есть случаи когда от такой субдоменальной репликации можно отказаться, но есть случаи когда она просто необходима и более рациональна. С точки зрения сео - это конечно зло, поэтому сайт следует не только не реплицировать столь явно, но и разносить по разным хостам на разные айпи. Но с позиции удобства юзабилити - субдомены и единая БД - это вообще сказка. А вот если играться с разными доменами (не субдоменами а именно доменными именами), то это достигается симлинками и аркованными доменами. В таком случае доменов несколько, но все они ссылаются на один и тот же физический движек. Сам сайтбилль работает в "абстрактном" режиме, т.е. он ни слухом ни духом с какого домена его вызывают, так что и куда отзываться ему тоже все равно. Естественно и папка картинок будет у них общая, так как в адресе картинки домен не фигурирует, а идет относительный адрес звавшего домена.

Номер телефона из данных объявления или из профиля пользователя?

/template/frontend/agency/top_fixed_menu.tpl.html Берем текст {$L_LOGIN_BUTTON} и меняем его на {$LT_LOGIN_BUTTON} Если нет файла /template/frontend/agency/language/ru/dictionary.ini - создаем В него вписываем строку LT_LOGIN_BUTTON="Вход"Проверяем отображение на кнопке. Меняем в последнем файле надпись "Вход" как заблагорассудится.

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

Оно самое. Выбивает старый эдитор для textarea_editor. Если у вас реалия, то он в принципе на ней плохо живет. Попробуйте для быстрого теста сменить тип поля с textarea_editor на просто textarea или переключить тип редактора на ckeditor, если такой установлен в сайте.

Тут есть еще один вариант - доступ в админку разделен между админом и "модератором" - пользователем, который не админ, но имеет право доступа к некоторым возможностям админки. С одной стороны он в админке и значит на обязательность можно забить. С другой, формально он не админ, и обязательность должен выдерживать.

Если брать смый общий случай, то я иногда делаю в шаблоне вот так:{if $some_phone_number != '' && $some_phone_number|strlen==12}{$some_phone_number|regex_replace:'/(\d{3,3})(\d{2,2})(\d{3,3})(\d{2,2})(\d{2,2})$/':'+${1} (${2}) ${3}-${4}-${5}'}{/if}Самая примитивная регулярка которая раздирает исходных набор цифр на куски и форматирует из кусочков нужное отображение. Для mobilephone, которые однотипны и имеют равную длину и числовую составляющую, работает на ура. Для прочих номеров возможно больше вариантов из-за необходимости очистки исходного номера от мусора и разной длины номеров из-за свободной формы записи.

Я сам наступаю на эти же грабли. id - означает уникальный идентификатор. И он не может состоять из двух слов (id="header-inner my-class"). Для добавления класса для стилей нужно добавить class="my-class" а потом уже все как вы делали. <div id="header-inner" class="my-class"> ПС. А вот если прочитать совет вам выше, то там новый класс добавлялся именно в секцию классов и для navbar-inner а не header-inner

Ни одна выгрузка, формируемая сайтбиллем не означает, что объявления куда-то выгружаются. Она означает, что объявление попадает в определенный поток отформатированное соответственно формату некоторого приемщика и этот поток будет выдаваться по обусловленному адресу на вашем домене. Ну или в файл какой. И все. Реальная загрузка к приемщику требует, как минимум, сообщения приемщику адреса по которому доступны ваши данные в его формате и добавление им этого адреса в свою базу, согласно которой он когда-нибудь опросит ваш поток и заберет данные. Галочка "выгружать в ЯН" просто сообщает движку, какие именно объявления следует поместить в исходящий поток.

Нет. Файл самоотдается при апросе на этот адрес. Физически по запрашиваемому адресу его не существует. Т.е. если у вас по этому пути в папке сайта реально есть такой файл, то его нужно удалить. Иначе отдастся физический файл, а не сработает приложение отдающее свежий сайтмап. 403 - значит, что бинг "не смогла", а не что файла-сайтмапа нет. По роботс у вас ограничений нет. Нужно смотреть не блоканули ли вы робота бинга другими путями, напр. через htaccess или по айпи.

Из того, что видно с кода, который опубликован, можно сказать, что будет работать с 50% вероятностью - или да, или нет) Что такое $modx? Есть ли с ним корневой класс-библиотека? Будете ли вы ее подключать, или просто вот этот же блок вставите? Не требует ли этот класс каких-то специфичных условий работы? Где инициализация $modx? Что вообще это такое? Вопросов масса. Некоторая логика в алгоритме видна, но больше вряд ли вам то-то скажет.

Похожие /template/frontend/agency/realty_view.tpl {if $similar_data[x].image.image_array|count ne 0}<a href="{$similar_data[x].href}"><img src="{$estate_folder}/img/data/{$similar_data[x].image.image_array[0].preview}" width="100" /></a>{/if}заменить на {if $similar_data[x].image.image_array|count ne 0}<a href="{$similar_data[x].href}"><img src="{$estate_folder}/img/data/{$similar_data[x].image.image_array[0].preview}" width="100" /></a>{else}<a href="{$similar_data[x].href}"><img src="{$estate_folder}/путь_к_своему_ноу_фото_от_корня_сайта" width="100" /></a>{/if}Для фотки объекта (там же) {section name=j loop=$photo}<div class="gitem"><a href="{$estate_folder}/img/data/{$photo[j].normal}" title="{$photo[j].title}" ><img src="{$estate_folder}/img/data/{$photo[j].preview}" style="max-width: none;" ></a></div>{/section}на {if $photo|count>0}{section name=j loop=$photo}<div class="gitem"><a href="{$estate_folder}/img/data/{$photo[j].normal}" title="{$photo[j].title}" ><img src="{$estate_folder}/img/data/{$photo[j].preview}" style="max-width: none;" ></a></div>{/section}{else}<img src="{$estate_folder}/путь_к_своему_ноу_фото_от_корня_сайта" />{/if}

Если очень мешает, можно удалить. Изменение от меня, в котором этого уже не будет, выйдет скорее всего только после НГ.