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 версиях, в ус не дуют и зарабатывают без оглядки на какие-то там графики трендов опенкарта.

для особо одаренных и настойчивых и twig не помеха, к сожалению. подобное стоит расценивать как своеобразный показатель качества шаблона: увидев методы-аналоги getProduct или imageResize во view, можно сразу начинать грустить

все Вы верно выразились в стартовом посте. Просто куки могут быть разными и там, где сайт перестает узнавать своих посетителей после закрытия браузера всего-лишь используются сессионные куки, которые вместе с закрытием браузера удаляются. Решение банальное: а) необходимо в настройках вашей версии php изменить session.cookie_lifetime = 3600 * Nчасов б) если не ошибаюсь, для 2.3 нужно в /system/library/session.php в районе 50й строчки сделать так в) так же стоит обратить внимание на параметры session.gc_probability, session.gc_divisor, session.gc_maxlifetime и учесть, что длинные сессии будут давать определенную нагрузку на хранилище в момент работы сборщика мусора (механизма удаления "протухших" сессий).

на всякий случай. 1) после изменения $_['cache_engine'] = '?'; в upload/system/config/default.php стоит так же где-то (в config.php?) прописать константы со своими значениями вот тут чуть больше инфы 2) большое значение имеет версия php-расширения для взаимодействия с сервером редиски. например, для php 5.6 максимально возможной является версия модуля\расширения redis 4.3.0 если мне не изменяет память, класс redis, которые идет из коробки в опенкарте, так же с более новыми версиями php-redis расширений не дружит, так как там ряд методов стал depricated \ переименовался. проверьте версию модуля. если что - установите нужную через pecl.

все что стоит знать о квери кэше на сегодняшний день ко всему прочему, кэширование атомарных запросов - плохая практика, чреватая скорыми последствиями. Впрочем, первые плоды Вы уже пожинаете - и это только верхушка айсберга ненужных приключений и проблем, связанных с инвалидацией этого кэша. нет, нельзя. Но если очень хочется есть кактус, то в select clouse избранных запросов стоит добавить директиву SQL_NO_CACHE; или зайти с обратной стороны: включить квери кэш в режим работы только для ряда запросов, помеченных директивой SQL_CACHE. хорошей практикой будет обычное кэширование на уровне приложения: хоть в файлы, хоть в редис. средствами опенкарта это делается довольно просто. что-то вроде

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

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

Совершенно очевидно, что у ТС проблемы попроще. По пути к онлайну в 1,5к уников опенкарт будет ждать 1001 других bottleneck'ов - более серьезных, чем выбор и тюнинг хранилища сессий. Но вы конечно же так написали, словно не бывает никаких машин кроме бугатти, а если и бывает, то ездить они не способны. Впрочем, мы уже давно знаем, что Вам подобная манера свойственна: крайности, преувеличения, демагогия и всяческие попытки выставить других в плохом свете.

J - skins - ваш скин - Product Listing - Products per Page

Так вы задайте вопрос исполнителям, которые Вам такие id-шники насоздавали. Это вопрос на уровне базы данных, с которой работает опенкарт (типы данных полей). Дело ведь не только в коробочном функционале опенкарта, который может и скорее всего пострадал. Речь так же и об элементарной совместимости с огромным количеством имеющихся модулей на рынке, которые не умеют работать с такими большими цифрами

ура? ко всему прочему а) очистка таблицы сессий - событие не частое. б) таблица в innodb и блокировок параллельных запросов не происходит при очистке. Итого - если у Вас не миллионы трафика, то проблемы как бы и нет.