Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

100napb

Пользователи
  
  • Публикаций

    423
  • Зарегистрирован

  • Посещение

Все публикации пользователя 100napb

  1. чем? какую задачу \ проблему Вы хотите решить? в key-vaule базах можно, но выигрыш от этого сомнительный, если сравнивать с хранением сессий в бд: если с файлами еще случаются заметные лаги при большом количестве сессий и небольшой производительности дисковой подсистемы, то с хранилищем в том же редисе или в бд лагов увидеть уже не так-то и просто. И да. мемкеш не рекомендую, так как после ребута сервера или рестарта демона все сессии с корзинками или вишлистами тю-тю.
  2. немного оффтоп, но все же: бросились в глаза ссылки вида route=product/product&product_id=1080696305. Дело в том, что сам движок опенкарта из коробки имеет некоторые ограничения на порядковые номера - они не могут быть такими большими. Разумеется, при некотором желании эти ограничения несложно обойти. Но это случается не часто - намного чаще "особо талантливые" исполнители просто некорректно наполняют магазины спарсенными товарами. Вы попробуйте ради душевного спокойствия создать через админку опенкарта новый товар; добавить новую картинки к уже существующему товару и убедитесь, что не возникнет ошибок и во фронте все изменения отобразятся. Есть отнюдь ненулевая вероятность того, что где-то накосячили "расширяя" ограничения для использования больших порядковых номеров на id-шники.
  3. Не забывайте, что по сути у Вас два варианта: - использовать услуги внешнего почтового провайдера и отправлять письма из опенкарта через smtp-подключения ко внешнему по отношению к вашему серверу\хостингу почтовому ящику. Как вариант, гуглите "яндекс почта для домена" и подобные. Подойдет даже обычный ящик не на вашем доменном имени, на худой конец - но выглядеть будет не солидно, хоть и письма доходить будут. - настроить свой собственный почтовый сервер (MTA) на базе какого-нибудь postfix или exim и не иметь при этом никаких ограничений на количество отправляемых писем. Тут нужен vps и немного времени. советы выше относительно dns-записей, хотя бы txt-записи об spf, mx, dkim - обязательны. Без них Вы такую картинку не увидите
  4. нет, не сложно. нет, не навредит, поскольку боты не кладут товары в корзинку и не совершают каких-либо иных длительных взаимодействий с сайтом, которые бы были завязаны на данные, хранимые в сессиях. Однако конкретных и публичных инструкций давать постесняюсь. Если будет желание - напишите в личку. следует посмотреть accesss-логи веб-сервера и посмотреть по заголовкам, кому принадлежат эти сессии. С большой долей вероятности это может быть какой-то невежливый или даже бесполезный \ зловредный бот. Если так, то следует просто ограничить доступ к сайту для этого робота. Визиты от всяких SemrushBot, AhrefsBot, MJ12bot и прочих подобных как правило никакой ценности не несут и лишь создают нагрузку.
  5. это норм. посещения от поисковых роботов так же стартуют сессии - а посещений от них нередко даже больше чем от клиентов. Как вариант, можно давать ботам 10минутную сессию, в отличие от длинной клиентской, что бы в самое ближайшее время она была удалена. Тогда в таблице будут копиться только живые сессии живых посетителей
  6. решение тут. смотрите раздел Webserver Instructions
  7. не пропустите еще проблемы с выводом мета-тэгов, которые есть в оксторе и которые не видит жорнал + сеоурлы для блога. как минимум...
  8. 100napb

    Смена пароля на сервере

    когда email-адрес получателя некорректный, например.
  9. В тройке отправка емейл-оповещений тригерится через механизмы событий, в отличие от прошлых версий, где отправка почты о заказах была буквально рядом с кодом создания заказа/ изменения статуса. проверьте раздел «события» в левом меню. Там должны быть и активны, помимо прочих, два пункта, ответственные за отправку писем клиенту и админу (поймёте по названию какие).
  10. тогда да, Вы правы, $_SERVER['HTTP_HOST'] лучше не использовать и адрес сайта вписать руками. ну да в нем ошибиться сложно) с путями же проблем быть не должно?
  11. просто как предложение, открытое для обсуждения\критики. На форуме полно тем с разными проблемами, причиной которых являются некорректные изменения в файлах config.php Что если константы в этом файле определять на основе суперглобальных переменных и предопределенных констант. Типа такого: потенциально это могло бы избавить новичков от множества проблем. Но я не знаю, создаст ли новые... )
  12. имейте ввиду, что php-cli у Вас, вероятнее всего, использует свой\другой файл конфигурации. в консоли выполните php --ini, что бы увидеть. Не говоря уже про то, что версия пхп может быть разной: веб-сервер может использовать одну, а по-умолчанию в системе может использоваться другая. так же, обратите внимание на COUNT_RECURSIVE и функцию array_count_values
  13. У Вас одна из переменных, вероятно , является массивом или строкой. проверьте либо вар_дампом, либо попробуйте привести типы к float , например
  14. В 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?) прописать константы со своими значениями
  15. попробуйте для начала в этот локейшн добавить упущенную инструкцию далее, если не поможет, стоит покурить в сторону наличия модификаций seo_pro.php и ради теста, убрать все сторонние ocmod'ы, например.
  16. @SooR ¯\_(ツ)_/¯ могу лишь такое сравнение привести со своей стороны а с промежуточной таблицей? хотя это уже почти агрегат... с ней не интересно
  17. решил посмотреть как изменятся конкретные цифры. Спасибо. Спасибо потому, что Во-1: я немного ошибся в результатах на живом примере, которые приводил выше. они были приведены для более тяжелого варианта запроса, в котором было отключено уточнение по дате и запрос, по сути, считал вообще все заказы *смущенный смайл*. Ну на коленке же тестируем, ради интереса... Зато! С уточнением по дате, как и было в изначальном условии задачи, запрос работает даже без промежуточных таблиц быстрее: менее 0.1сек. Не так уж и плохо, хотя с агрегатом можно еще быстрее. Во-2: от варианта записи даты через adddate-interval или явно, результат 0.1сек прям заметно не меняется. хотя я согласен - должно быть быстрее, если указывать дату явно, как Вы и уточнили.
  18. подобное время возможно при использовании предварительно вычисленных агрегатов, например. Как заметили выше - это самое очевидное и простое решение. При работе с ними, весь этот запрос превращается во что-то вроде 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к товаров.
  19. 100napb

    Кэшируется админка

    вероятно, у Вас согласно параметрам в .htaccess (или конфигам nginx) кэшируется html-ответ веб-сервера. Проверить легко: откройте панель разработчика в браузере и посмотрите статус кэширования\переданный объем данных напротив запроса страницы - если ответ кэширован браузером, то Вы сразу это увидите. в .htaccess смотрите директивы типа в конфигах nginx несколько сложнее искать, но там не должно быть например вроде такого
  20. прошу прощения что вмешиваюсь, но Жорнал3 из-коробки умеет в webp. J -> System -> Settings -> ваш магазин -> Performance -> смотрите в раздел Images. Плюс, встроенный в тему кэш (там же, в разделе Performance) работает вполне сносно. Едва ли решение от markimax будет работать лучше с этой темой, чем ее "родной" механизм кэширования
  21. спасибо и Вам. от себя добавлю лишь, что кэширование корзины предложенными выше способами корректно работало и было необходимо. Но этого было недостаточно, так как на данном конкретном проекте на странице чекаута для каждого товара выполнялись доп.запросы в базу, заложенные сторонним модулем\шаблоном, которые и создавали ощутимую нагрузку-задержку..
  22. для http -> https в секцию non-ssl: return 301 https://$host:443$request_uri; для субдомена www -> основной домен if ($host ~* ^www\.(.*)$) { return 301 https://$server_name$request_uri; } или создавать отдельную секцию для поддомена с www., включая инструкции с сертификатами (если сайт работает по https), и там делать редирект
×
×
  • Создать...

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.