HtwwtH

Пишу итоговое решение. Не удалось найти, где происходит подмена символов, уже ушло много времени на исследование вопроса, решили отключить ЧПУ-ссылки именно на странице поиска. Страницы, связанные с поиском, все равно перекрыты в robots.txt и не влияют на сео сайта: Disallow: /*route=product/search Disallow: /search/ В файле\catalog\controller\startup\seo_pro.php в функции validate(): if (rawurldecode($url) != rawurldecode($seo) && isset($this->request->server['SERVER_PROTOCOL'])) { header($this->request->server['SERVER_PROTOCOL'] . ' 301 Moved Permanently'); $this->response->redirect($seo, 301); } замена на: if (strripos($url, '/search')){ //со страниц поиска не редиректить на чпу, то есть ничего не делать } elseif ( rawurldecode($url) != rawurldecode($seo) && isset($this->request->server['SERVER_PROTOCOL'])) { header($this->request->server['SERVER_PROTOCOL'] . ' 301 Moved Permanently'); $this->response->redirect($seo, 301); } Примечание, досюда $url и $seo доходят еще нормальные и даже правильно расшифрованы, но во время редиректа с ними что-то происходит. Возможно, в WINDOWS-1251 перекодирует (хотя все страницы сайта, все таблицы базы данных, сама база, в настройке nginx установлено utf-8), такое предположение, потому что после редиректа были похожие на то закорючки в запросах (смотрела цепочку редиректов в network). Спасибо за советы, они помогли понять, в чем проблема! Жаль, пока не хватает ума полностью раскопать настройки, но какое-никакое решение есть)

Оу, так не стирает символы, теперь понятно, что проблема в SEO URL

Эх, не помогает ничего. Спасибо за ответ! Модификаций правда присутствует куча от предыдущих разработчиков. Пробовала отключать, кстати, пара связаны с поиском. Обновила модификаторы, очистила папку с кэшем - поиск все равно остался сломан. Также изменила конфиг и перезапустила nginx. Явной подмены "%8" нигде по коду не происходит. Есть пара плагинов, которые в system/storage/modification/catalog/controller/startup переписали seo_pro.php и seo_url.php: NewsBlog для новостей (но он установлен уже после того, как поиск был сломан), и OcFilter (v4.7.5) для фильтров в категории с ползунками. Вот на OcFilter есть подозрение, но если его отключить, а потом включить, там слетают настройки. По ходу, придется делать транслит, думаю воспользоваться "ГОСТ 7.79-2000 (ИСО 9-95) СИБИД. Правила транслитерации кирилловского письма латинским алфавитом" - если в поиск вбили русское слово, добавить какой-нибудь ключ в начало строки, транслитить в англ русское слово, чтобы оно дошло в таком виде до функции отправки в базу, а перед отправкой расшифровать в русский, вроде этот алгоритм позволяет точно расшифровывать. Правда, не понимаю пока, в куче разных файлов с вызовами БД, какой именно вызов БД мне нужен, буду потом как нибудь экспериментировать на локалке. Вот нашла пример транслит на js, вдруг кому пригодится А вообще интересный баг, что он принимает %8+еще символ за разделитель, может, это пошло откуда-то, где делят url на категория_подкатегория_продукт, но мне не удается найти этого причину( P.S. Я нанималась на junior frontend, а не вот это вот все

Здравствуйте! Моя голова уже вся сломалась на раздумьях о том, почему не проходит запрос в product/search на кириллице. Opencart 2 на nginx + php-fpm. Вбиваю русское слово в строку поиска (или прямо в адресную строку в /index.php?route=product/search&search=слово). Русское слово кодируется методом URIencode, например "погрузчик" -> "%D0%BF%D0%BE%D0%B3%D1%80%D1%83%D0%B7%D1%87%D0%B8%D0%BA" Идет запрос /index.php?route=product/search&search=%D0%BF%D0%BE%D0%B3%D1%80%D1%83%D0%B7%D1%87%D0%B8%D0%BA В этой строке почему то последовательности "%8?" подменяются на "_" (посмотрела в логах), соответственно, запрос превращается в /search/?search=%D0%BF%D0%BE%D0%B3%D1_%D1_%D0%B7%D1_%D0%B8%D0%BA При раскодировании получается пустая строка, которая отправляется в базу данных, поиск ничего не находит. Запросы на английском языке - работают. Запросы на русском языке - работают, если закодированное слово не содержит последовательностей "%8?", например, запрос "мини" пройдет. Статические страницы с кириллицей (которые без route) - работают. На локали на http - все работает. Подозрения на какие то особенности конфига. Конфиг домена: А это главный конфиг, предоставленный хостингом В чем же заключается эта магия?.. Старший программист предлагает русское слово перевести в транслит, а перед отправкой в базу расшифровать обратно. Но я не оставляю надежды понять, почему адресная строка себя так ведет