Wild

Или может тупо сделать редирект на 404, как вы думаете?

Я тупанул... getTotalProducts ведь просто получает количество ВСЕХ товаров с учетом фильтра по категориям и выбранному фильтру (простите за тавтологию). Лимиты, сортировка, порядок и стартовая позиция ей пофигу. Спасибо. Но возникла другая проблема... Сделав $page=1, я получаю корректные данные, но в строке адреса все равно светится ?page=999. Т.е. фактически мы находимся на странице 999 с данными от 1. Как грамотно сделать корректный редирект?

Просто в контроллере сначала строится массив фильтра со стартовой страницей ($page - 1) * $limit и другими параметрами. потом на его основании получаем список продуктов getProducts потом получаем их общее количество через getTotalProducts и только потом уже можем рассчитать реальное количество страниц. Т.е. при указанной page=999999 по факту мы уже получили ПУСТОЙ массив товаров с учетом фильтра. Вот сижу и туплю... Сделать перед основной выборкой товара такой же запрос и на основании его результата выставить $page=1 повторить его уже с этим параметром? Кривоватый костыль... Я не перфекционист, но все же может подскажете более красивое решение? Или я чего-то упустил в логике работы?

Поторопился... )) Забыл отбросить несуществующие ключи сортировки. Верный вариант: // Set necessary order $orderArray = array('route','path','manufacturer_id'); // Apply it $orderArray = array_intersect($orderArray, array_keys($data)); $data = array_merge(array_flip($orderArray), $data);

Сделал управляемую сортировку. Перед $route = $data['route']; добавить: // Set necessary order $orderArray = array('route','path','manufacturer_id'); // Apply it $data = array_merge(array_flip($orderArray), $data);

К примеру в некой категории 15 страниц товаров. Если, к примеру, ввести ссылку ?page=17, то получаем страницу без товаров. Как в этом случае сделать редирект на последнюю (или первую) страницу?

Что ЭТО? Мой вопрос, который я задал? Какая именно его часть вас смущает?

Пользуюсь своей, нормальной. Просто интересно поведение поисковиков в случае разных дат. Чаще ли они будут индексировать и как отреагируют на их несоответствие.

Поле date_modified штатно присутствует в products и categories. В info и manufacturers этих полей по умолчанию нет. Понимаю, что можно добавить их в базу и модифицировать модели и контроллеры. Вы используете подобный метод?

Спасибо! Как всегда оперативно, понятно, доступно. Если не секрет, вы используете эти тэги? Если да, то какие данные вы ставите в эти поля?

В этом топике обсуждается Last-Modified в заголовках страниц, кроме того есть модули для OC, которые добавляют LastMod в SiteMap. В карте сайта эти модули ставят текущую дату (читай дату генерации), а в заголовки ставят реальную дату изменения контента. Понимаю, что в сайтмапе текущая дата устанавливается якобы для улучшения индексации, чтобы робот почаще обходил страницы. Как поисковики относятся к такому разночтению? Как лучше поступить? Оставить разные или лучше сделать одинаковыми?

Окэ, спасибо за разъяснения.

На текущий момент модуль актуален для всех веток OC? Просто никогда не сталкивался с подобными проявлениями, вот и спрашиваю. Лучше перебдеть, чем недобдеть.

OC v2.0.3.1

В данном случае не принципиально. Там то же самое. Попробовал. Ссылка стала генериться правильно, но почему-то при этом "Запрашиваемая страница не найдена!". Ошибок в логах нет. Данные подменяются корректно. Пробовал на обоих версиях SeoPro.

Спасибо, будет время, покопаюсь.

SeoPro от Freelancer или Jazz? Будет ли работать на 2.0.3.1?

Но при таком раскладе они ОБЕ уйдут из индекса или только одна?

Сайт в разработке, по этому еще не все данные занесены (описания). Заголовки и мета теги уникальны. Просто как я писал выше, товары первой страницы некой категории полностью соответствуют первой странице товара одного из производителей. Так сложилось при дефолтной сортировке. Я обратил на это внимание и поинтересовался возможными проблемами. Не понимаю ваш сарказм.

На сайте установлен и включен SeoPro от Jazz. Если открыть страницу с URL вида (товары из категории конкретного производителя): site.ru/index.php?route=product/category&path=111_222&manufacturer_id=333 то она приобретет вид: site.ru/category/subcategory/manufacturer Если поменять местами параметры path и manufacturer_id: site.ru/index.php?route=product/category&manufacturer_id=333&path=111_222 то в результирующем адрес соответственно получится site.ru/manufacturer/category/subcategory Т.е. категории с производителем меняются местами. Можно как-то при создании адреса упорядочить их в одной последовательности, чтобы небыло разночтений (читай дублей).

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

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

Полезный модуль. Попробовал поставить на OC 2.0.3.1 версию для 2.1. Запустилось и в целом работает, но..... 1. При включении подсчета размера кэша, выдает только общую цифру суммарного объема: 2. При попытке почистить системный кэш выдает ошибку: В папке system/cache/ есть временный каталог модуля ExcelPort, в который он складывает файлы с данными для импорта. Сами файлы затираются, но там еще лежит .htaccess вида: Он не удаляется и это правильно, но генерируется вышеуказанная ошибка. Вот бы поправить эти 2 момента...

Еще странноватый результат выборки. Не попадают в нее некоторые категории 3-го уровня. Проблема наверняка не в уровне вложенности. Понимаю, что у каждого свои тараканы на реальных данных, но все же... P.S. Ограничение на main_category ускоряет запрос раза в 4 (+/-), но всеравно медленно.

Попробовал убрать вложенные группировки, оставив последнюю. Ситуация та же, быстрее не стало.