abushyk

самое главное, что я пытаюсь пояснить - не раскрывайте карты. Что означает с точки зрения сайта "не показывать каких-то юзеров" - это значит определить что есть заказ на непоказ со стороны клиента и решить кого следует исключить из выдачи. Это же самое с точки зрения клиента должно означать "передай признак, что ты хотел бы скрыть каких-то пользователей, обозначенных как собственники". Т.е. клиент должен вообще не понимать как обозначены собственники (привет group_id=18), потому что это не его дело и потому, что сегодня собственники в группе 18, а завтра в 18 и 22, а послезавтра группы вооще не будут отражать принадлежность к собственнику и у каждого юзера в данных профиля появится галочка "Я собственник". Он просто просит сайт сделать это, а как, кого и по каким условиям - сайт решит сам.

Задача своlbтся к стандартной задаче добавления нового элемента формы поиска и обеспечения фильтрации по нему (это если такое поведение должно быть именно с фильтра) Делается в два шага: 1. собственно добавление элемента на форму Для этого выбираем имя параметра под которым признак будет проходить в запросах. Например hide_smth. Для большей гибкости мы не будем водить этот параметр по конкретному значению, как в примере =18. Потому что если завтра мы решим как-то расширить диапазон тех, кого прячем, нам не нужно будет править это 18 на 20 или изголяться, что бы сложить туда идешки двух групп. Логику определения, что спрятать, мы уберем в код, который будет формировать запрос. А снаружи оставим только просто параметр, наличие которого будет нам говорить не "что именно нужно спрятать", а "что нам нужно в целом что-то спрятать, а ты сам реши уже что именно". ПС. Использование в той же переменной name="group_id" value="18" конкретного значения 18 приводит еще к тому, что подменяя 18 на другие ИД (15, 1, 22) я смогу управлять фильтрацией снаружи, без учета того, что хотел владелец сайта предоставить мне. Это не всегда критично, но иногда может вылезти очень сильно боком (особенно если код обработчик просто принимает это число из запроса и ставит его в условия фильтрации без каких либо внутренних проверок). ППС. Суть создания элементов поисковых форм и их обработчиков состоит не в том, что бы дать пользователю все возможности самому там ковыряться и играть вариантами, а в том, что бы дать ему ровно столько, сколько вы считаете нужным и он не мог выйти за рамки. Поэтому на форме мы размещаем хтмл вида <input class="checkbox" type="checkbox" name="hide_smth" value="1"{if intval($smarty.get.hide_smth)==1} checked="checked"{/if} /><label class="ch">Не показыват ЭТИХ</label> 2. прописывание логики поиска Что бы наш параметр учелся в поиске, мы должны его перехватить и обработать. Для этого мы используем или tempalte_search или локализацию grid_constructor. Для варианта tempalte_search внутри public function getParams() перехватываем параметр if(1===intval($this->getRequestValue('hide_smth'))){ $params['hide_smth'] = 1; } и добавляем обработку внутри public function run() if(isset($params['hide_smth'])){ $DBC=DBC::getInstance(); $hide_users=array(); /*получаем ИД юзеров из "запрещенных" групп*/ /*вместо 1,2,3,4 через запятую поставить ИД этих групп*/ $query='SELECT `user_id` FROM '.DB_PREFIX.'_user WHERE `group_id` IN (1,2,3,4)'; $stmt=$DBC->query($query); if($stmt){ while($ar=$DBC->fetch($stmt)){ $hide_users[]=$ar['user_id']; } } /*Если юзеров из запрещенных групп более нуля, то добавляем условие в выборку объектов*/ /*с исключением этих юзеров*/ if(!empty($hide_users)){ $where_array[]=DB_PREFIX.'_data.iser_id NOT IN ('.implode(',', $hide_users).')'; } }

Может быть просто код не может получить поток с фида-источника (он пуст или вылетает с ошибкой). Поэтому шапку и дату создает, далее курит, так как $offers пустой и закрывает пустой фид.

по строкам вы не угадаете. 157 - это строка если считать строки из готовой страницы. но в шаблоне это будет другая строка. Просто найдите в файле шаблона строку <img class="sp-image" - в той строке, где она есть и будет нужное вам. на ту строку, что на скрине в 157 строке - тоже можно, но это не большие картинки, а превьюшки-иконки. хотя у вас на скрине как раз исходный. но лучше найдите строку по кусочку, который я написал.

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

Самый простой способ - открываем фид в хроме. Нажмаем контрол+Ф что бі запустить поиск по странице. Вводим в поле искомой строки строку <offer internal-id=" и сбоку от введенного хром считает количество вхождений этой строки в страницу. Сколько насчитает, столько и объектов в фиде.

Сказачйте заново архив с ckeditor, удалите старую папку с ним и залейте наново. Он битый у вас сечас, или при распаковке или при закачке попортило файлы.

Внутрь нее <img src="{$estate_folder}/img/data/{$similar_data[x].image.image_array[0].preview}" class="previewi" alt="{$data.topic_id.value_string}, {$data.city_id.value_string}, {$data.street_id.value} {$data.number.value} фото {$smarty.section.j.iteration}">

В шаблонах комментировать лучше с помощью {if 1==0} тут комментируемый кусок {/if} т.е. мы оборачиваем вывод в невыполнимое условие. Можно оборачивать и в <!-- -->, но есть отличие. Оборачивание через <!-- --> в общем то только скрывает от показа то, что внутри, но в странице оно будет. Поэтому если обернуть немного неаккуратно, то внешне видно не будет, зато в сорце страницы все будет как на ладони. А первый способ скрывает полностью. Так что если вы не совсем уверенны, лучше первым способом - он более жесткий.

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

3. будет зависеть от свежести движка и, как я уже писал, того, что в шаблоне - в нем могут встрачаться явно прописанные ссылки. 4. наверное будет стоить, а может и нет. у вас же только тип ссылок поменяется, а не контент, так что индексировать особо нечего. 5. ну тут не сутки ждать прийдется, а может и месяцы, но у вас уже будет редирект с переводом на "правильные" адреса. и страницы будут склеиваться. 6. удалять страниц с слешем вам не нужно - редиректом они склеятся с такими же, но без слеша. удаляют страницы, которые лишние - например выпали из структуры или такие как ссылки с навигации по страниццам или сортировок. В остальном все примерно так и будет.

Исходите из простого правила - чем важнее и релевантнее информация к фото, тем одна должна идти раньше или ближе к началу строки. UPD Ставить альт на вот єто. <img class="sp-image" src="{$estate_folder}/img/data/{$photo[j].normal}"/>

существует куча сайтов и компаний предоставляющих полный анализ сайта с развесовкой страниц. ну или вручную в поиске прогонять запросы с ключевиками и смотреть какие страницы идут выше по каким ключам и от этого плясать.

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

В целях экономии можно, но если нужно будет перейти на другой плагин, то наличествующие альты уже будут и не нужно будет их добавлять. Ну и фиг знает как роботы себя поведут. в принципе они получают страницу в сыром виде и могут альты увидеть, но если они отрабатывают скрипты, тогда их не увидят. но шас как бы есть. т.е. я бы оставил. всякие анализаторы будут 100% бухтеть, что отсуствуют атррибуты alt на картинках (потому что они часто анализируют уже готовую страницу), но это их дело.

а что, кто-то серьезно пишет описания к картинкам в объектах?

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

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

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

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

да, верно.

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

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

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

Нет. там обычные карусельки. А так как эти блоки предназначены для вставки на другой сайт, то они "все свое несут с собой" и не сильно зависят от плагинов на сайте, куда вставляются.