100napb

чем? какую задачу \ проблему Вы хотите решить? в key-vaule базах можно, но выигрыш от этого сомнительный, если сравнивать с хранением сессий в бд: если с файлами еще случаются заметные лаги при большом количестве сессий и небольшой производительности дисковой подсистемы, то с хранилищем в том же редисе или в бд лагов увидеть уже не так-то и просто. И да. мемкеш не рекомендую, так как после ребута сервера или рестарта демона все сессии с корзинками или вишлистами тю-тю.

немного оффтоп, но все же: бросились в глаза ссылки вида route=product/product&product_id=1080696305. Дело в том, что сам движок опенкарта из коробки имеет некоторые ограничения на порядковые номера - они не могут быть такими большими. Разумеется, при некотором желании эти ограничения несложно обойти. Но это случается не часто - намного чаще "особо талантливые" исполнители просто некорректно наполняют магазины спарсенными товарами. Вы попробуйте ради душевного спокойствия создать через админку опенкарта новый товар; добавить новую картинки к уже существующему товару и убедитесь, что не возникнет ошибок и во фронте все изменения отобразятся. Есть отнюдь ненулевая вероятность того, что где-то накосячили "расширяя" ограничения для использования больших порядковых номеров на id-шники.

Не забывайте, что по сути у Вас два варианта: - использовать услуги внешнего почтового провайдера и отправлять письма из опенкарта через smtp-подключения ко внешнему по отношению к вашему серверу\хостингу почтовому ящику. Как вариант, гуглите "яндекс почта для домена" и подобные. Подойдет даже обычный ящик не на вашем доменном имени, на худой конец - но выглядеть будет не солидно, хоть и письма доходить будут. - настроить свой собственный почтовый сервер (MTA) на базе какого-нибудь postfix или exim и не иметь при этом никаких ограничений на количество отправляемых писем. Тут нужен vps и немного времени. советы выше относительно dns-записей, хотя бы txt-записи об spf, mx, dkim - обязательны. Без них Вы такую картинку не увидите

нет, не сложно. нет, не навредит, поскольку боты не кладут товары в корзинку и не совершают каких-либо иных длительных взаимодействий с сайтом, которые бы были завязаны на данные, хранимые в сессиях. Однако конкретных и публичных инструкций давать постесняюсь. Если будет желание - напишите в личку. следует посмотреть accesss-логи веб-сервера и посмотреть по заголовкам, кому принадлежат эти сессии. С большой долей вероятности это может быть какой-то невежливый или даже бесполезный \ зловредный бот. Если так, то следует просто ограничить доступ к сайту для этого робота. Визиты от всяких SemrushBot, AhrefsBot, MJ12bot и прочих подобных как правило никакой ценности не несут и лишь создают нагрузку.

это норм. посещения от поисковых роботов так же стартуют сессии - а посещений от них нередко даже больше чем от клиентов. Как вариант, можно давать ботам 10минутную сессию, в отличие от длинной клиентской, что бы в самое ближайшее время она была удалена. Тогда в таблице будут копиться только живые сессии живых посетителей

решение тут. смотрите раздел Webserver Instructions

не пропустите еще проблемы с выводом мета-тэгов, которые есть в оксторе и которые не видит жорнал + сеоурлы для блога. как минимум...

когда email-адрес получателя некорректный, например.

В тройке отправка емейл-оповещений тригерится через механизмы событий, в отличие от прошлых версий, где отправка почты о заказах была буквально рядом с кодом создания заказа/ изменения статуса. проверьте раздел «события» в левом меню. Там должны быть и активны, помимо прочих, два пункта, ответственные за отправку писем клиенту и админу (поймёте по названию какие).

тогда да, Вы правы, $_SERVER['HTTP_HOST'] лучше не использовать и адрес сайта вписать руками. ну да в нем ошибиться сложно) с путями же проблем быть не должно?

просто как предложение, открытое для обсуждения\критики. На форуме полно тем с разными проблемами, причиной которых являются некорректные изменения в файлах config.php Что если константы в этом файле определять на основе суперглобальных переменных и предопределенных констант. Типа такого: потенциально это могло бы избавить новичков от множества проблем. Но я не знаю, создаст ли новые... )

карточки медленно открываются.

имейте ввиду, что php-cli у Вас, вероятнее всего, использует свой\другой файл конфигурации. в консоли выполните php --ini, что бы увидеть. Не говоря уже про то, что версия пхп может быть разной: веб-сервер может использовать одну, а по-умолчанию в системе может использоваться другая. так же, обратите внимание на COUNT_RECURSIVE и функцию array_count_values

У Вас одна из переменных, вероятно , является массивом или строкой. проверьте либо вар_дампом, либо попробуйте привести типы к float , например

В ocstore, как и в оригинальном ОС, ссть недоработка, из-за которой после смены класса кэша с файлов на, например, redis, становится невозможным очистить кэш стандартными средствами движка. как вариант, можно использовать следующее решение добавить новый метод по очистке кэша непосредственно в класс редиса upload/system/library/cache/redis.php добавить новый метод по очистке кэша в класс кэша upload/system/library/cache.php добавить новые инструкции по очистке кэша через кнопку в админке upload/admin/controller/common/developer.php К слову, так же неплохо было бы добавить где-то инструкцию, что после изменения $_['cache_engine'] = '?'; в upload/system/config/default.php стоит так же где-то (в config.php?) прописать константы со своими значениями

попробуйте для начала в этот локейшн добавить упущенную инструкцию далее, если не поможет, стоит покурить в сторону наличия модификаций seo_pro.php и ради теста, убрать все сторонние ocmod'ы, например.

@SooR ¯\_(ツ)_/¯ могу лишь такое сравнение привести со своей стороны а с промежуточной таблицей? хотя это уже почти агрегат... с ней не интересно

решил посмотреть как изменятся конкретные цифры. Спасибо. Спасибо потому, что Во-1: я немного ошибся в результатах на живом примере, которые приводил выше. они были приведены для более тяжелого варианта запроса, в котором было отключено уточнение по дате и запрос, по сути, считал вообще все заказы *смущенный смайл*. Ну на коленке же тестируем, ради интереса... Зато! С уточнением по дате, как и было в изначальном условии задачи, запрос работает даже без промежуточных таблиц быстрее: менее 0.1сек. Не так уж и плохо, хотя с агрегатом можно еще быстрее. Во-2: от варианта записи даты через adddate-interval или явно, результат 0.1сек прям заметно не меняется. хотя я согласен - должно быть быстрее, если указывать дату явно, как Вы и уточнили.

подобное время возможно при использовании предварительно вычисленных агрегатов, например. Как заметили выше - это самое очевидное и простое решение. При работе с ними, весь этот запрос превращается во что-то вроде select product_id as popular from agregate_table where category_id\path_id = ?. Как альтернативный вариант - использование иных хранилищ, взамен mysql (на мой взгляд сложнее + так же требует синхронизации данных, как и агрегаты - пересоздания) ради спортивного интереса чуть переписал этот кривенький запрос: а) вычисление популярных товаров из секции select можно вынести в отдельный джоин б) подсчет количества заказов для каждого товара категории - это не совсем корректный признак его популярности, в то время как сумма купленного количества товара должна быть более точной характеристикой. Потому Count(op.order_id) AS popular заменил на SUM(op.quantity) AS popular. На скорость это не влияет. Результаты на живом примере: при 380к активных и включенных товаров в oc_products и 40к+ заказов в oc_order время выполнения этого запроса без привязки к какой-либо категории чуть менее 0.4сек. С уточнением категории, разумеется, будет быстрее: с потенциальным минимумом, равным времени выполнения запроса из джоина с вычислением популярных товаров (на моих данных около 0.2сек). Если же этот джоин с вычислением popular заменить предварительно посчитанной таблицей, то итоговое время выполнения запроса будет еще меньше: ~0.01сек для категории с 1к товаров, например или около 0.2сек для определения топ3 среди всех 380к товаров.

вероятно, у Вас согласно параметрам в .htaccess (или конфигам nginx) кэшируется html-ответ веб-сервера. Проверить легко: откройте панель разработчика в браузере и посмотрите статус кэширования\переданный объем данных напротив запроса страницы - если ответ кэширован браузером, то Вы сразу это увидите. в .htaccess смотрите директивы типа в конфигах nginx несколько сложнее искать, но там не должно быть например вроде такого

прошу прощения что вмешиваюсь, но Жорнал3 из-коробки умеет в webp. J -> System -> Settings -> ваш магазин -> Performance -> смотрите в раздел Images. Плюс, встроенный в тему кэш (там же, в разделе Performance) работает вполне сносно. Едва ли решение от markimax будет работать лучше с этой темой, чем ее "родной" механизм кэширования

.

попробуйте так

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

для http -> https в секцию non-ssl: return 301 https://$host:443$request_uri; для субдомена www -> основной домен if ($host ~* ^www\.(.*)$) { return 301 https://$server_name$request_uri; } или создавать отдельную секцию для поддомена с www., включая инструкции с сертификатами (если сайт работает по https), и там делать редирект