STh

РЕШЕНО. Спасибо за помощь@Prooksius . Ранее я полностью удалял этот SEO Backpack на тестовом сайте - каноникалы везде восстанавливались штатные (если они были прописаны в файлах шаблона ОС). Другое дело, что создателями сайта этот SEO Backpack был изначально предустановлен, т.к. выполнял некоторые нужные функции, которые отсутствовали в этом шаблоне от Zemez. Так что просто так удалить его я не мог. Пришлось дорабатывать. В этом SEO Backpack и других, более мелких косяков было предостаточно. Некоторые из них были мною исправлены. Т.к. это всё же было проще, чем переделывать\делать заново недостающий функционал шаблона. Но насчёт его непродуманности - полностью согласен. Это ещё мягко сказано. Так что лучше не ставьте этот модуль вообще. Где-то здесь на форуме уже была тема, где этот модуль обсуждался - гадость ещё та. С другой стороны, если бы на сайте не было Simple-блога, то и этой проблемы бы не было . Хотя этот SimpleBlog - отдельная головная боль... Но, как говорится, иногда выбирать не приходится.

РЕШЕНО. Спасибо за помощь@Prooksius . Ранее я полностью удалял этот SEO Backpack на тестовом сайте - каноникалы везде восстанавливались штатные (если они были прописаны в файлах шаблона ОС). Другое дело, что создателями сайта этот SEO Backpack был изначально предустановлен, т.к. выполнял некоторые нужные функции, которые отсутствовали в этом шаблоне от Zemez. Так что просто так удалить его я не мог. Пришлось дорабатывать. В этом SEO Backpack и других, более мелких косяков было предостаточно. Некоторые из них были мною исправлены. Т.к. это всё же было проще, чем переделывать\делать заново недостающий функционал шаблона. Но насчёт его непродуманности - полностью согласен. Это ещё мягко сказано. Так что лучше не ставьте этот модуль вообще. Где-то здесь на форуме уже была тема, где этот модуль обсуждался - гадость ещё та. С другой стороны, если бы на сайте не было Simple-блога, то и этой проблемы бы не было . Хотя этот SimpleBlog - отдельная головная боль... Но, как говорится, иногда выбирать не приходится.

Более подробное описание проблемы здесь:

Да, пожалуйста - всё актуально. Основной сайт - https://nspvip.com . Я сделал его полную копию на .RU-домене, чтобы было удобнее ковырять. Отписал вам в личные. Если ещё кто желает помочь - пишите.

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

в логах модификаторов, например, есть такая запись: MOD: SEO Backpack FILE: catalog/controller/startup/seo_url.php CODE: public function rewrite($link) { LINE: 74 CODE: $url .= '/' . $query->row['keyword']; LINE: 89 LINE: 100 CODE: if ($product_info) { LINE: 210 CODE: $category_info = $this->model_catalog_category->getCategory($category_id); LINE: 123 CODE: parse_str($url_info['query'], $data); LINE: 127 CODE: return $url_info['scheme'] . '://' . $url_info['host'] . (isset($url_info['port']) ? ':' . $url_info['port'] : '') . str_replace('/index.php', '', $url_info['path']) . $url . $query; LINE: 186 CODE: if (isset($this->request->get['_route_'])) { LINE: 76 CODE: if ($url) { LINE: 238 CODE: public function rewrite($link) { LINE: 152 CODE: public function index() { LINE: 14 CODE: public function rewrite($link) { LINE: 181 и ещё несколько похожего по seo_url для category, product и manufacturer. Но на сайте включен seo_pro. Для эксперимента я временно вернул оригинальный seo_url.php - ничего не изменилось.

там 2 таких блока - для, собственно, категорий блога и для 404-страниц (они у него как бы свои). изначально я этот addLink и прописывал перед блоком $data['header']...['footer'] - т.е. там же, где этот addLink прописан и в магазинных категориях. но, как вы и посоветовали - сейчас вставил конкретно перед $data['header'] = $this->load->controller('common/header');. Ничего не поменялось - также не выводится. Если вставлять перед нижним блоком с $data['header'] = $this->load->controller('common/header');- то не выводится даже prev/next.

Возможно. Тоже думал об этом. Есть там такая штуковина, SEO Backpack называется (кто в теме, думаю, знает о чём речь). Полностью от него отказаться нет возможности, оно шло сразу с шаблоном, выводит в нём микроразметку, прописывает нужные meta robots на технических страницах, используется как массовый генератор title\description (ибо в этом шаблоне нет своего генератора). Настройки canonical в нём тоже есть, но они отключены. Все остальные функции тоже отключены (ибо почти всё ненужное, либо стрёмное). За исключением вышеописанного. Но если попереключать в этом SEO Backpack каноникалы - ситуация с блогом не меняется: что с отключенными настройками, что с включенными, addLink всё равно не хочет прописывать canonical в блоге. Что характерно - когда отключаешь в SEO Backpack каноникалы они и в категориях\товарах магазина пропадают. Возможно, дело всё-таки в этом - что с отключенными, что с включенными настройками этот Backpack как-то перехватывает функции AddLink по "канонической части"? А можно ли как-то это проверить, не удаляя его полностью? Ибо как к блокировщику технических страниц от индекса через meta robots и генератору микроразметки к этому Backpack претензий нет - всё это он делает корректно.

не совсем понимаю, как это посмотреть (не знаю так хорошо OC, как вы). но prev / next нормально отображается. Если prev / next удалить - canonical всё равно не выводится. Если $this->url->link('simple_blog/category', 'simple_blog_category_id=' . $this->request->get['simple_blog_category_id']); присвоить переменную и вывести её print_r - выводится правильный адрес текущей категории. /system/library/document.php оригинальный.

Что значит не то? Метод addLink - штатный. Ошибок в синтаксисе нет. Этим же методом в НЕ блоговых ресурсах всё отлично я вывел. Да и в блоговых ресурсах этих методом выводится всё остальное. Не срабатывает только 'canonical' в блоге. При этом ошибок в логах ОС нет. Я даже готов на платную подсказку, если это поможет решить эту проблему. Там всё равно ещё много чего нужны подсказки. Хочется всё-таки обойтись без "костылей", насколько это возможно.

Разумеется - это было первое, что я проверил. Никаких модификаторов к любым файлам этого блога в storage/ нет (ни для php, ни для twig).

- насчёт модификаторов. Тут шаблон, причём, довольно сильно переделанный этими Zemez. Поэтому, разумеется, в нём прилично всяких модификаций + штук 40 их же доп. модулей. Собственно, потому и возник вопрос, кто с таким сталкивался - может есть какой проверенный способ, как отследить, где что мешает. Кроме как отключить всё и вернуться к голому ОС (сайт уже наполнен и используется в работе) - т.е. это не вариант.

OC 3.0.2.0 "Русская сборка" Тема "Zemez" с уже встроенным блогом на основе Simple_Blog. (seo_pro включен). Необходимо было прописать в категориях блога тэг "canonical". В категориях\товарах магазина всё прописывается и выводится через стандартный метод document - addLink(...). Например, "$this->document->addLink($this->url->link('product/category', 'path=' . $category_info['category_id']), 'canonical');" в category.php и т.п. Работает. Аналогично выводится и rel="prev/next". С блогом такой вариант не срабатывает. Точнее, оно там как-то наполовину срабатывает - rel="prev/next" выводит, а "canonical" - нет. Например: "$this->document->addLink($this->url->link('simple_blog/category', 'simple_blog_category_id=' . $this->request->get['simple_blog_category_id']), 'canonical');" в php-категории блога - не выводит ничего. Однако если написать, скажем, так: "$this->document->addLink($this->url->link('simple_blog/category', 'simple_blog_category_id=' . $this->request->get['simple_blog_category_id']), 'canonical_');" - оно отлично выводится. Только роботы ПС такой 'canonical_', разумеется, не воспринимают. - Подскажите, пожалуйста, кто сталкивался с такой ситуацией - что может мешать? Почему не срабатывает именно с 'canonical'? Может, где-то что-то конфликтует, как это проверить? Или я что-то не так делаю? Сделал временный "костыль": echo '<link href="' . $this->url->link('simple_blog/category', 'simple_blog_category_id=' . $this->request->get['simple_blog_category_id']); echo '" rel="canonical" />'; - всё работает, однако выводится оно над <!DOCTYPE html>, что не есть правильно. Попутно ещё вопрос - как это вывести сразу из php в нужное место в DOM?

С этим не спорю и согласен с вами. Возможно, я не совсем понятно выразился - я имел ввиду, что после включения SeoPro, действительно, "эта 10-летняя беда" пропадает, зато вместо неё появляется другая - вот эта вот моя позавчерашняя проблема. Поэтому я и не мог его включить

- как видите, в некоторых случаях есть. Моя тема тому пример. Ибо если бы в SeoPro было изначально прописано это условие, то у меня бы не возникло циклического редиректа главной. Хотя я делал абсолютно чистую установку (уже 2 года работаю в этой сборке XAMPP). И ЧПУ - это первое, что я начал настраивать. Потом 2 дня перебирал все возможные комбинации настроек и htaccess, чтобы понять, что я мог сделать не так. Оказалось, проблема в 3х строчках кода SeoPro, а у меня всё было настроено правильно. После же добавления этого когда (или вашего) - теперь я могу ставить любые настройки: отключать\включать ЧПУ, дубли, слэши и т.п. И всё норм. открывается, никаких глюков с редиректами и прочим подобным. Но всё равно, как я уже писал ранее, с точки зрения SEO - разработчики правильно сделали, что включили этот SeoPro в стандартный комплект ocStore. Из 2х зол, как говорится... Лучше побороться с одним глюком (как мой случай), чем постоянно "клеить заплатки" на 10 других глюков ("детских болячек"), если бы SeoPro не было. Да, возможно, на фоне других масштабных доработок и возможностей, что реализовано (или допиливается) в OpenCart - моя проблема ничтожна. Поэтому её до сих пор никто и не запулил в Git. Разработчики заняты более важными вещами. Но SEO в наше время - тоже очень важная составляющая успеха любого интернет-магазина. Поэтому такие проблемы всё же нельзя полностью игнорировать.

- это вряд ли. 10 лет на форумах мусолят тот же извечный "?route=common/home", а они до сих пор не могут эти 3 строчки кода добавить...

Решено. В общем, окончательное проверенное решение, на котором я остановился и избавился от всех вышеописанных недостатков, такое: } elseif ($data['route'] == 'common/home') { $url .= '/'; unset($data[$key]); } - добавил после 129 строки оригинального seo_url.php в \catalog\controller\startup\ . Вроде, всё красиво, без костылей. В SeoPro включено всё, кроме добавления конечного слэша. "Погонял" штатную тему, все ЧПУ-URL работают как надо. Кроме, разумеется, служебных страниц (Личный кабинет, Производители...) - на них, по "старому-доброму" обыкновению OpenCart'а "из_коробки", почему-то ЧПУ не распространяются. Это уже отдельная тема для исправления. Если вас не затруднит - можете в ответ скинуть ссылки на проверенные варианты, как это исправить без доп. модулей для ocStore 3.0.2.0 ? На форуме уже где-то предлагались такие решения через Базу Данных. Всех благодарю за ответы. Прилагаю исправленный файл seo_url.php, чтобы сэкономить время на правки, вдруг кому-то ещё будет полезно:

- да, спасибо - это было самое первое что я проверил в настройках SEO URL, в том числе и в БД.

- проверил ваш код - всё везде заработало нормально! Спасибо! Все типовые "SEO-болячки" с URL'ами с этим кодом и включённым SeoPro отрабатывают на отлично (двойные слэши, дубли и т.п. - всё вырезается), и главная норм. открывается, без "мусора". Всё таки, при некоторых "танцах с бубном", когда у клиента не хватает денег на полную доработку сайта под SEO - этот вшитый SeoPro приносит гораздо больше пользы, чем вреда (как тут многие пишут). Однако с вашим кодом проявляется один незначительный нюанс, который немного нехорошо смотрится с точки зрения SEO. На сайте все ссылки на главную становятся без завершающего слэша (в конце доменного имени). Тот самый "незримый" слэш, который всегда обязательно присутствует в конце домена (имени сайта). Что вызывает некоторое несоответствие в коде html ссылок на главную. Например: <base href="http://shop3.com/" />, но <link href="http://shop3.com" rel="canonical" /> - обычно для роботов ПС одна и та же страница со слэшем и без - это 2 разные страницы (дубли). Поэтому, например, те же каноникалы главной, я прописываю в точности, как в base href - т.е. со слэшем. А тут слэш принудительно обрезается - фиг его знает, правильно ли робот обработает такую ссылку. Кстати, вот ещё про заморочки настроек SeoPro, если интересно:

- про незримый слэш - это верно. А на счёт браузера - то здесь это зависит от его настроек. Я, например, свой Firefox настроил так, чтобы он всегда отображал этот "незримый" слэш. Но большинство современных браузеров, действительно, "из коробки", этот слэш не показывают. - с главной на главную, грубо говоря. .htaccess со своими ЧПУ-правилами "вырезает" довесок-роут и редиректит на главную, а на главной ocStore добавляет route=common/home... и так по кругу (или наоборот). Что-то типа того. Вполне возможно, если бы сайт не был установлен в подпапку, то этого бы не происходило. В этом случае где-то в коде не учтён этот нюанс (не хватает условия проверки), когда используется настройка "Без завершающих слэшей" и "ЧПУ без дублей" (в SeoPro) - получается конфликт.

- но в демке-то (demo.ocstore.com) всё работает. Прочитайте, пожалуйста, пост выше. В смысле, что в демке и SeoPro стоит, и ЧПУ включены и завершающий слэш отключен - и главная открывается отлично, никаких цикличных редиректов.

- спасибо вам, конечно, за варианты догадок, но всё это я уже проверял. Конфиг создал сам установщик ocStore 3.0.2.0 (ориг. дистр. с Гитхаба по оф. ссылке), при установке сразу в папке /shop3/ . Я сравнивал с конфигами ocStore 2.х.х.х, установленных точно таким же образом - там всё аналогично. Да и если бы в конфигах что-то было неправильно, то вариант со слэшем не работал бы вообще. .htaccess'ы тоже у них абсолютно одинаковые (кроме роутов на карту Гугла и Googlebase). Интересно то, что у ocStore 3.0.2.0, установленного на демке (demo.ocstore.com) я своей проблемы не наблюдаю. Там, как я понял, включены ЧПУ и отключен завершающий слэш - и всё отлично с главной, никаких цикличных редиректов. Никакой SP OcStore 3 SeoPro Fix там не используется и всё ж нормально. https://demo.ocstore.com/desktops/mac/about_us (добавления статьи к категории) - вот этот косяк, да, есть, но к моей проблеме это не имеет отношения. Ещё информация о настройках. Если отключить ЧПУ на вкладке Сервер (и деактивировать .htaccess) - то всё отлично работает! В независимости от того, включен ли завершающий слэш на вкладке SeoPro или нет. Я могу ошибаться, но мне кажется, что у настроек ЧПУ ОпенКарта (при их включении) возникает какая-то несовместимость с вшитым SeoPro, если сайт установлен НЕ в корень хостинга, а в отдельную папку. Где-то конфликт реврайтов (условий) в php с теми, что применяются в htaccess, который нужно активизировать при включении ЧПУ. Поэтому зачем-то ему и нужно обязательно активировать завершающий слэш. Не могу понять, где что можно попробовать изменить, чтобы найти, из-за чего это происходит. А ЧПУ нужно. Ведь при точно таких же установках ocStore 2.х.х.х - проблем нет (тоже ставил в под-папку). Другое дело, что в ocStore 2.х.х.х и вшитого SeoPro нет...

Исходные данные: Чистая новая установка ocStore 3.0.2.0 на вирт. сервер xampp в локальную папку /shop3/. Включены ЧПУ во вкладке Сервер, во вкладке SeoPro включено "Включить SeoPro" и "ЧПУ товаров с категориями". Все остальные настройки - по-умолчанию. .htaccess активирован, базовый Rewrite - /shop3/ - прописан. Больше ничего не менялось. Суть проблемы: ЧПУ работают, категории и товары открываются нормально. Только главная страница выдаёт бесконечный редирект (не открывается). Админка работает без проблем. Если в настройках вкладки SeoPro ещё включить "Добавить слэш в конец ссылки", то всё открывается нормально, включая главную. Но везде в конце URL добавляется слэш. Нужно чтобы работало без этого слэша. Вопрос: Как избавиться от бесконечного редиректа главной, не включая конечный слэш? На этом же xampp'е запускается ещё пару магазинов на ocStore 2.x.x.x и блог на Wordpress (в своих подпапках) - там таких проблем нет: можно включать конечный слэш или отключать, всё работает без проблем.