abushyk

да, и такое может случиться. в фтп папке точно нельзя. да и файлы сами по себе не работают. все равно его нужно запускать "от сайтбилля", так как он обязательно будет использовать что-либо из системы. или включенные в нем. вообще по любому чиху можно. на самые извращенные требования к набору. Все равно логика не будет линейной. Вы не сможете просто отдавать фиды вида userNNN.xml, так как вы раскроете все свои объекты, да еще фасованные по юзерам, наружу. Нужно будет как-то определять кто может выгружать, в каком количестве, какой набор (даже тут есть варианты). Это будет все в приложении, но не раньше чем оно будет переписано полность. Сейчас его расширять еще таким уже накладно.

Если есть такая страница, то тогда все норм, менять не нужно.

Поменяли в єлементе выбора ключи. Но, атк как у вас ранее были ключи "первичная продажа","переуступка", то они наверное так и дальше хранятся как значения у объявлений. После смены ключей, вы же не перепроставляли значения в объектах. И иным способом не меняли их.

А где выгрузка?

все, что было реализовано в папке шаблона (шаблоны вывода, локальные приложения, какие-то модификации внутри main.php), то нужно будет переносить. стандартные части - сами меню, но не их вывод в шаблоне, объекты - останутся.

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

RewriteCond %{QUERY_STRING} ^option=com_zoo RewriteRule ^.*$ /404.html? [R=301,L] это должно перенаправить все у кого есть "option=com_zoo" Последние можно выхватить как RewriteCond %{QUERY_STRING} ^(.*)controller=searchjbuniversal&task=filter RewriteRule ^.*$ /404.html? [R=301,L] Только точку перенаправления указать какую-то реальную.

в зависимости от окна спан9 - 870px\700px\538px\100% спан3 - 270px\220px\166px\100%

Два раза подключить его нельзя.

да да да да

Возможно что да. В \template\frontend\realia\css\bootstrap.corrections.css добавляем стили body #wrapper-outer #wrapper { display: block; height: auto; } body #wrapper-outer #wrapper #wrapper-inner { display: block; height: auto; } body #wrapper-outer #wrapper #footer-wrapper { display: block; height: auto; } Они отменят некоторую встроенную в реалию стилизацию и дадут возможность фотораме нормально позиционироваться. Хром, эмуляторы в хроме и фф отрабатывают без поломок. В остальных браузерах я не тестировал.

{if $smarty.section.i.iteration==5} ------> {if $grid_items|count>10 && $smarty.section.i.iteration==5}

if(preg_match('/бел.руб/i',$currency_string)){ измените на if(preg_match('/бел\.руб/i',$currency_string)){ В контексте регулярного выражения, которое вы написали, точка означает буквально "любой символ". А слешик ее экранирует и будет означать именно "точка".

Да, вполне будет. Главное помнить, что значение iteration показывает номер текущего прохода цикла, но начинает отсчет с 1.

Вот стандартный цикл вывода объявлений {section name=i loop=$grid_items} тут вывод объявлений {/section} Добавить вставку через каждые 4 записи {section name=i loop=$grid_items} тут все что было внутри {if $smarty.section.i.iteration%4==0} {include file="включаемый шаблон"} {/if} {/section} для другой периодичности сменить четверку в $smarty.section.i.iteration%4 на нужное число

Точно. Я совершенно упустил момент ее смены летом 2016 года. Тогда вам нужно еще временно в файлах \apps\yandexrealty\admin\admin.php \apps\yandexrealty\site\site.php найти строку if(preg_match('/белорусский/i',$currency_string)){ return 'BYR'; } и заменить на if(preg_match('/белорусский/i',$currency_string)){ return 'BYN'; }

С вероятностью близкой к 100% Менеджер активнее развивался, чем выгрузка, поэтому и данные у него более свежие. И речь о названии валюты, а не о ее коде. Сечас все определяется от названия, а оно может быть любым. Код же должен быть реальным официальным кодом. С нового обновления выгрузки "понимание" валют будет идти уже ТОЛЬКО от кодов в менеджере валют. Либо навесить чекбокс выгружаемости только на российские объявления, либо завести свой адрес и на нем распараллеливанием, собрать только российские объекты. В самом приложении ограничить так не выйдет.

Откройте статью эту на редактирование. Поставьте мышку в конец текста и потяните ее вниз держа левую кнопку, как буд-то выделяете. Увидите, что у вас там после текста еще штук 8 строк пустых.

Просто уберите в тексте статьи лишние переносы строк в ее конце.

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

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

Ему это не нужно - это стандартный хтмл чекбокса. Если он принимает хтмл, то он поймет это как выделенный чекбокс, если не понимает, то не поймет сразу весь кусок разметки.

Путем локализации и обработки географии самостоятельно. Например у меня на сайте в стране Испания есть регион Коста-Бланка. Это не административный регион, а полоса пляжей включающая много разных городов. И уже в этот регион включены города. Каждому городу у меня сопоставлены данные, которые соотвествуют его реальной административной цепочке. Т.е. на сайте у меня Испания - Коста-Бланка - Ориуэлла, но сама Ориуэлла имеет ссылку в БД в отдельной таблице еще и реальную цепочку Испания - Валенсия - Аликанте - Ориуэлла. На сатйе все идет по первой цепочке, через пляж. При потребности выгрузить с данными об административном положении я отдельным запросом вытягиваю данные о реальной цепочке данного города и выгружаю именно ее. Для меня это приемлемый вариант. Возможно. Это почти как автокомплит с добавлением, только от яши. И разбирать ответ яши, а он довольно большой по объему данных будет, нужно будет вам. Иными словами некую модерацию хоть на этапе написания обработчика, не исключить. Но основой для вытягивания георафических данных из того же яши должно быть или сравнительно полное текстовая строка с адресом или геокоординаты положения. Так же вытягивание данных из яши не дает однозначной вложенности, так как админструктура ветвиста и запутана, поэтому в ответ обычно получают пачку сущностей условно отранжированных по соотвествию и какие-то части родительских локаций. Тут же становится вопрос, что если вам не понравится как в яше называется эта локация, то вам придется засунуть свое недовольство в карман, поскольку тут уже оно будет диктовать вам как и что называть. Ну и это не решит проблемы организации улиц. Оно и не должно. Оно даже на сайте не должно показываться. Его задача дать возможность клиенту подать вам знак, что ему мало ваших городов и он хотел бы добавить свой. А вы, увидев этом маячек, можете добавить такой город и перепривязать этот объект к нему или не добавить, посчитав, что оно вам такое не нужно.

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