100napb

как вариант, используется регистрозависимый collation в базе данных (_cs на конце). Загляните через phpmyadmin в структуру таблиц oc_product или oc_product_description, например. Если действительно дело в этом, то через тот же pma можно изменить коллейшн всех таблиц и полей в выбранной базе данных (выбрать БД в левой колонке - вкладка "операции" вверху - найти в самом низу нужный блок с параметрами смены коллейшена. Прежде чем что-то менять, не забудьте сделать бэкап бд.

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

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

Напрасные опасения. Относительно бюджетное решение есть. Отписался лс

спасибо за хороший пример и ясное объяснение. На самом деле, подобная история совсем не редкость и, разумеется, имеет решение. Причем, скорее всего, оба варианта поиска, предложенные выше, справятся с подобными запросами без проблем и покажут нужные результаты, так как, скорее всего, речь о том, что бы разные части названия индексировались отдельно друг от друга могли быть найдены лишь по частичному совпадению (буквы от цифр?). Иными словами, "XYZ2000ABC" можно найти как по вхождению xyz, так и по abc, так и по 2000. Если реальный пример понятнее, то есть во многом аналогичный кейс из часовой тематики, например: когда у одной и той же модели часов есть разные регоинальные префиксы или какие-то незначительные отличия в названии. И покупатели часто пишут в поиск увиденные в каком-нибудь обзоре или отзыве "AE-1200WH-1С", которые им так понравились, в то время как в конкретно в его стране эта модель имет чуть иное название или же у модели новое поколение вышло и, в итоге, в наличии бывают именно эти же часы, но модели у них сейчас "AE-1200WH-3А", "AE-1200WH-1В" или там "AE-1200WH-5В". Я даже больше скажу. Нужные результаты в примере выше найдутся, даже если поисковый запрос будет каким-нибудь таким "AE-1200WH-1С ромашка" "ромашкаAE-1200WH-1С" или вовсе "AE-1200ромашкаWH-1С". Короче говоря, новости для вас хорошие: есть и решение, и даже выбор

на всякий случай, отмечусь и я. опечатки, неверная раскладка, транслитерация, морфология, синонимы и еще кучка всякого, типа поиска по габаритам ("2х3" = "3х2"), фильтров и пр... И да, соглашусь с постом выше: чем больше допущений, что в запросе пользователя есть ошибка и чем больше разных алгоритмов работает, тем больше "шума" в результатах - остается только пытаться ранжировать их.

как вариант, при изменении статуса заказа идет некое обращение к сторонним ресурсам каким-нибудь curl'ом (по видео можно предположить, что есть какая-то связь с монобанком). и либо api этого стороннего ресурса тупит, либо какие-проблемы с ним, но из-за этого может тупить на раз. а еще при отправке писем при изменении статуса заказа могло бы, но галочку "уведомить" Вы не ставили... а еще стоит посмотреть раздел "события" в аминке опенкарта - там так же могут быть какие-то триггеры, которые срабатывают при изменении статусов заказов...

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

1. убедитесь, что у вас качество ресайзов картинок не установлено вручную или модификатором в какие-нибудь волшебные 100% 2. типовые размеры ресайзов должны быть стандартизированы среди всех модулей в магазине, всех блоков и настройках шаблона. Иными словами, у Вас не должно быть десятка уникальных типоразмеров картинок: один для категорий, другой для блока рекомендуемых, третий там для еще какого-то места... в противном случае, для каждого изображения товара будет создан тот самый десяток ресайзов. В большинстве случаев, хватает лишь нескольких типовых размеров 3. + webp (на скрине почему-то размер подозрительно мал)

вероятно, речь не о веб-серверах, а о модуле для них, который призван выполнять ряд различных оптимизаций https://www.modpagespeed.com/ ps: в ряде случаев модуль может быть полезен; но по факту же а) требует тонкой настройки, иначе можно огрести проблем на ровном месте б) редко обновляется в) по итогу выхлоп сомнительный и как серебряную пулю его точно рассматривать не стоит. г) априори требует vps и не годится для виртуального хостинга (ну разве что если сам хостер не встроит его в панель управления и свои веб-сервера (украин.ком?)

там опечатка\ошибка была. в репозитории OCStore она осталась. Из-за этого gc срабатывает при каждом запросе страницы. После исправления работает аналогично коробочному механизму php по очистке протухших сессий и гибко настраивается. На мой взгляд, это лучшее решение детской болячки с сессиями в базе для ОС 3.* на текущий день.

И это тоже. вот действительно годное решение (рабочий механизм gc в конструкторе с учетом настроек окружения/php, ответственных за частоту срабатывания) https://github.com/opencart/opencart/blob/3.0.x.x_Maintenance/upload/system/library/session/db.php

ради того же интереса привяжите все эти товары к одной категории и попробуйте снова посмотреть ttfb. По моим наблюдениям, пока нет жирных категорий с большим количеством товаров, все более-менее терпимо работать может за рядом небольших исключений, которые так же относительно несложно фиксятся. Судя по урлам в вашем примере отсутствуют ЧПУ для всех этих товаров и категорий. В OCStore третьей версии сео_про на порядок шустрее работает чем в двойке, но, тем не менее, при таком количестве товаров именно сео_про будет изрядно тормозить, если включено кэширование урлов (json_decode всего массива с чпу будет дороже, чем простецкий атомарный запрос к бд)

я так понимаю, что речь идет об ошибке #1071 - Specified key was too long; max key length is 767 / 1000 bytes. в MySQL до 5.7 версии включительно это ограничение для InnoDB таблиц было 767 байт (1000байт для MyISAM ). Начиная с 5.7.7 вроде как лимит поднят до 3072байт. поскольку на кодирование utfmb8 нужно 4 байта, поле с типом varchar может включить либо 767/4 = 191 символ в кодировке utfmb8 на иннодб, либо 1000\4 = 250 на майисам... короче говоря, я бы обновился и не парился. если обновиться нельзя, то а) либо обрабатывал в ручном режиме подобные ошибки, предварительно проверяя, что таблица не содержит длинных значений в конвертируемых полях - иначе они "обрежутся" после того, как изменить им varchar(255) на что-то меньшее. В ряде случаев, вместо варчар возможно безболезненно использовать другой тип данных - тот же text б) есть еще вариант с ROW_FORMAT=DYNAMIC, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет...

Есть мнение, что Опенкарт с его простенькой и стабильной архитектурой априори не гонится за какими-либо трендами . Глобально в нем от версии к версии мало что меняется. Из дискурса современной разработки и даже возможностей свежих версий php он так же выпал. Какое там PSR, DI, autowiring, DRY и прочие модно\трендовые слова. Опенкарт это совсем не про хайп. Староват. Молодым специалистам он все менее интересен: там какая-нибудь лара, джнага или ангулар с реактом заманит скорее, чем дряхлеющий ОС. Иными словами, не растет семимильными шагами аудитория специалистов. Скорее даже редеет... Все это прямо или косвенно объясняет приведенные Вами графики. Тем не менее, он остается относительно простым, недорогим и потому популярным инструментом, способным решать актуальные хотелки и требования екома. Особенно в СНГ. В том числе - благодаря этому форуму. это все давно было и будет. P.S.: есть полно примеров успешных проектов, которые обрасли кастомом, сидят себе еще на 1.5.6 \ 2.3 версиях, в ус не дуют и зарабатывают без оглядки на какие-то там графики трендов опенкарта.