100napb
-
Публікації
423 -
З нами
-
Відвідування
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Повідомлення, опубліковані користувачем 100napb
-
-
22.02.2023 в 21:32, The_KriptoniT сказал:
есть ли какая нибудь альтернатива данному модулю поиска?
достойных альтернатив, которые бы умели в морфологию и всякие плюшки, да еще и в виде готовых модулей, которые можно было бы купить на форуме или маркетплейсе - нет. Но существуют частные разработки на базе движков полнотекстового поиска, которые сложно\мало интересно оформлять в виде универсальных модулей
я, например, могу "умный" поиск с ocfilter подружить, что бы типа так, не говоря уже про продвинутый живой поиск, который легко и лям товаров тащит
Скрытый текст
-
On 11/2/2022 at 11:23 AM, KIRKIRKIR said:
Очень надеюсь на обратную связь!
Или если есть ещё варианты для хорошего качественного поиска -открыты и готовы обсудить
есть богатый опыт, экспертиза и живые примеры. а так же возможность подготовить демку поиска на ваших данных, что бы потестить вживую.
пишите в лс. -
On 7/4/2022 at 4:15 PM, Michael78 said:
Спасибо за ответы!
Подозреваю, что эти новости сильно не бесплатные и вряд ли по карману моему личному "Авито". Просто хотел даже свою барахолку сделать как надо, а получится как и у подавляющего большинства крупных магазинов, которые этим не парятся. :)
Напрасные опасения. Относительно бюджетное решение есть. Отписался лс
-
1
-
-
On 7/4/2022 at 4:18 AM, Michael78 said:
Объясню для чего это нужно.
спасибо за хороший пример и ясное объяснение.
На самом деле, подобная история совсем не редкость и, разумеется, имеет решение. Причем, скорее всего, оба варианта поиска, предложенные выше, справятся с подобными запросами без проблем и покажут нужные результаты, так как, скорее всего, речь о том, что бы разные части названия индексировались отдельно друг от друга могли быть найдены лишь по частичному совпадению (буквы от цифр?). Иными словами, "XYZ2000ABC" можно найти как по вхождению xyz, так и по abc, так и по 2000.
Если реальный пример понятнее, то есть во многом аналогичный кейс из часовой тематики, например: когда у одной и той же модели часов есть разные регоинальные префиксы или какие-то незначительные отличия в названии. И покупатели часто пишут в поиск увиденные в каком-нибудь обзоре или отзыве "AE-1200WH-1С", которые им так понравились, в то время как в конкретно в его стране эта модель имет чуть иное название или же у модели новое поколение вышло и, в итоге, в наличии бывают именно эти же часы, но модели у них сейчас "AE-1200WH-3А", "AE-1200WH-1В" или там "AE-1200WH-5В".
Spoiler
Я даже больше скажу. Нужные результаты в примере выше найдутся, даже если поисковый запрос будет каким-нибудь таким "AE-1200WH-1С ромашка"
"ромашкаAE-1200WH-1С" или вовсе "AE-1200ромашкаWH-1С".Короче говоря, новости для вас хорошие: есть и решение, и даже выбор
-
на всякий случай, отмечусь и я.
опечатки, неверная раскладка, транслитерация, морфология, синонимы и еще кучка всякого, типа поиска по габаритам ("2х3" = "3х2"), фильтров и пр...
Spoiler
И да, соглашусь с постом выше: чем больше допущений, что в запросе пользователя есть ошибка и чем больше разных алгоритмов работает, тем больше "шума" в результатах - остается только пытаться ранжировать их.
-
25 minutes ago, AlexMax13 said:
Что может быть?
как вариант, при изменении статуса заказа идет некое обращение к сторонним ресурсам каким-нибудь curl'ом (по видео можно предположить, что есть какая-то связь с монобанком). и либо api этого стороннего ресурса тупит, либо какие-проблемы с ним, но из-за этого может тупить на раз. а еще при отправке писем при изменении статуса заказа могло бы, но галочку "уведомить" Вы не ставили...
а еще стоит посмотреть раздел "события" в аминке опенкарта - там так же могут быть какие-то триггеры, которые срабатывают при изменении статусов заказов...
-
8 minutes ago, chukcha said:
Это сложный вопрос
поясню в двух словах
Для каждого разрешения экрана можно генерить свои размеры, при этом указывая для какого разрешения
ГС такое любит, да и браузеры подтягивают нужное им разрешение картинкибезусловно, это отличное решение, особенно для клиентов на мобильных устройствах. Однако без ведома ТС подобное едва ли появится вместе с каким-нибудь модулем или шаблоном и он был бы в курсе )
12 minutes ago, wwizard said:1. Настройки картинок
не знаю как Вы, а я не вижу необходимости и большой разницы между целым рядом размеров. Там половину можно унифицировать и зафиксировать нужные размеры в верстке\стилях: при небольшой разнице в размерах картинки и ее реальных габаритам в макете html даже гугл ругаться не будет в своем пейджспиде.
18 minutes ago, wwizard said:в Либери, у меня нет такого файла((
странно... в тройке он вроде как должен быть из коробки. вероятно какой-то модификатор или модуль подменяет собой этот функционал. и, вестимо, спрашивать и искать начать стоит именно с него.
19 minutes ago, wwizard said:Может он их создает под каждый магаз?
нет ничего проще проверить и убедиться - посмотрите "глазами" внутри папки кэша, какие там ресайзы создаются для какой-нибудь выбранной картинки какого-нибудь выбранного товара. и сколько их \ с какими названиями
-
11 minutes ago, wwizard said:
Сама папка со всеми картинками 5 гигов, а кеш за 2 недели - уже 28 Гигов.
1. убедитесь, что у вас качество ресайзов картинок не установлено вручную или модификатором в какие-нибудь волшебные 100%Spoiler/system/library/image.php
public function save($file, $quality = 90) {
2. типовые размеры ресайзов должны быть стандартизированы среди всех модулей в магазине, всех блоков и настройках шаблона. Иными словами, у Вас не должно быть десятка уникальных типоразмеров картинок: один для категорий, другой для блока рекомендуемых, третий там для еще какого-то места... в противном случае, для каждого изображения товара будет создан тот самый десяток ресайзов. В большинстве случаев, хватает лишь нескольких типовых размеров
3. + webp (на скрине почему-то размер подозрительно мал)
-
1
-
-
1 hour ago, antiuser said:
к пакетам оптимизации это не имеет никакого отношения.
вероятно, речь не о веб-серверах, а о модуле для них, который призван выполнять ряд различных оптимизаций
ps: в ряде случаев модуль может быть полезен; но по факту же а) требует тонкой настройки, иначе можно огрести проблем на ровном месте б) редко обновляется в) по итогу выхлоп сомнительный и как серебряную пулю его точно рассматривать не стоит. г) априори требует vps и не годится для виртуального хостинга (ну разве что если сам хостер не встроит его в панель управления и свои веб-сервера (украин.ком?)
-
1
-
-
2 hours ago, LEOnidUKG said:
Всё тоже самое, долбёжка БД через раз на удаление сессий.
там опечатка\ошибка была. в репозитории OCStore она осталась. Из-за этого gc срабатывает при каждом запросе страницы. После исправления работает аналогично коробочному механизму php по очистке протухших сессий и гибко настраивается. На мой взгляд, это лучшее решение детской болячки с сессиями в базе для ОС 3.* на текущий день.
Spoilerif (mt_rand() / mt_getrandmax() > $gc_probability / $gc_divisor) {
vs
if (mt_rand() / mt_getrandmax() < $gc_probability / $gc_divisor) {
-
23 minutes ago, nikifalex said:
а может проблема просто в том что нет индекса по expire?
И это тоже.
вот действительно годное решение (рабочий механизм gc в конструкторе с учетом настроек окружения/php, ответственных за частоту срабатывания)https://github.com/opencart/opencart/blob/3.0.x.x_Maintenance/upload/system/library/session/db.php
-
1 hour ago, fanatic said:
стало интересно попробовать на тройке
20 категорий по 10 под категорий в категории 2000 товаров. = 400000 товаров.
ради того же интереса привяжите все эти товары к одной категории и попробуйте снова посмотреть ttfb. По моим наблюдениям, пока нет жирных категорий с большим количеством товаров, все более-менее терпимо работать может за рядом небольших исключений, которые так же относительно несложно фиксятся.
Судя по урлам в вашем примере отсутствуют ЧПУ для всех этих товаров и категорий. В OCStore третьей версии сео_про на порядок шустрее работает чем в двойке, но, тем не менее, при таком количестве товаров именно сео_про будет изрядно тормозить, если включено кэширование урлов (json_decode всего массива с чпу будет дороже, чем простецкий атомарный запрос к бд)
-
25 minutes ago, AlektroNik said:
Может у Вас есть какой-то вариант?
я так понимаю, что речь идет об ошибке #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, но там потребуются правки конфигов демона бд, т.е. на шаред-хостинге не выйдет...
-
1
-
-
1 hour ago, tdslava said:
Кто как считает, что это все значит? Почему Опенкарт падает быстрей общего тренда?
Есть мнение, что Опенкарт с его простенькой и стабильной архитектурой априори не гонится за какими-либо трендами . Глобально в нем от версии к версии мало что меняется. Из дискурса современной разработки и даже возможностей свежих версий php он так же выпал. Какое там PSR, DI, autowiring, DRY и прочие модно\трендовые слова.
Опенкарт это совсем не про хайп. Староват. Молодым специалистам он все менее интересен: там какая-нибудь лара, джнага или ангулар с реактом заманит скорее, чем дряхлеющий ОС. Иными словами, не растет семимильными шагами аудитория специалистов. Скорее даже редеет...
Все это прямо или косвенно объясняет приведенные Вами графики. Тем не менее, он остается относительно простым, недорогим и потому популярным инструментом, способным решать актуальные хотелки и требования екома. Особенно в СНГ. В том числе - благодаря этому форуму.
1 hour ago, tdslava said:Маркетплейсы и магазины в соцсетях сжирают мелкий еком? Общее падение доходов и торговли? Какие-то еще движки поджимают?
это все давно было и будет.
P.S.: есть полно примеров успешных проектов, которые обрасли кастомом, сидят себе еще на 1.5.6 \ 2.3 версиях, в ус не дуют и зарабатывают без оглядки на какие-то там графики трендов опенкарта.
-
3 hours ago, RomanZUB said:
Про одаренных с кодом в шаблоне можете объяснить ?
для особо одаренных и настойчивых и twig не помеха, к сожалению. подобное стоит расценивать как своеобразный показатель качества шаблона: увидев методы-аналоги getProduct или imageResize во view, можно сразу начинать грустить
-
3
-
-
2 hours ago, stanr said:
Может я не так выразился.
все Вы верно выразились в стартовом посте. Просто куки могут быть разными и там, где сайт перестает узнавать своих посетителей после закрытия браузера всего-лишь используются сессионные куки, которые вместе с закрытием браузера удаляются.
Решение банальное:
а) необходимо в настройках вашей версии php изменить session.cookie_lifetime = 3600 * Nчасов
б) если не ошибаюсь, для 2.3 нужно в /system/library/session.php в районе 50й строчки сделать так
Spoilerif ($key != 'PHPSESSID') {
setcookie($key, $this->session_id, time() + ini_get('session.cookie_lifetime'), ini_get('session.cookie_path'), ini_get('session.cookie_domain'), ini_get('session.cookie_secure'), ini_get('session.cookie_httponly'));
}НЕ ЗАБЫВАЙТЕ сделать бэкап файла. А сразу после пункта а) и б) следует проверить выполненную работу и корректность авторизации в той же админке.
в) так же стоит обратить внимание на параметры session.gc_probability, session.gc_divisor, session.gc_maxlifetime и учесть, что длинные сессии будут давать определенную нагрузку на хранилище в момент работы сборщика мусора (механизма удаления "протухших" сессий).
-
7 minutes ago, AlexChapman said:
Понг в консоли отвечает. Да и ISPmanager показывает что редис включен и прекрасно работает как расширение PHP
29 minutes ago, AlexChapman said:Получаю белый экран вместо сайта
на всякий случай.
1) после изменения $_['cache_engine'] = '?'; в upload/system/config/default.php стоит так же где-то (в config.php?) прописать константы со своими значениями
define('CACHE_HOSTNAME', 'localhost');
define('CACHE_PORT', '6379');
define('CACHE_PREFIX', 'oc_');вот тут чуть больше инфы
Spoiler2) большое значение имеет версия php-расширения для взаимодействия с сервером редиски.
например, для php 5.6 максимально возможной является версия модуля\расширения redis 4.3.0
если мне не изменяет память, класс redis, которые идет из коробки в опенкарте, так же с более новыми версиями php-redis расширений не дружит, так как там ряд методов стал depricated \ переименовался.
проверьте версию модуля. если что - установите нужную через pecl.
-
1 hour ago, AlexChapman said:
В общем, подключил Query_Cache
все что стоит знать о квери кэше на сегодняшний день
SpoilerThe query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0.
ко всему прочему, кэширование атомарных запросов - плохая практика, чреватая скорыми последствиями. Впрочем, первые плоды Вы уже пожинаете - и это только верхушка айсберга ненужных приключений и проблем, связанных с инвалидацией этого кэша.
1 hour ago, AlexChapman said:Возможно ли как-то исключить из кэширования некоторые таблицы базы? Например в админке приходится обновлять страницу через CTRL-F5 для отображения новых заказов.
нет, нельзя. Но если очень хочется есть кактус, то в select clouse избранных запросов стоит добавить директиву SQL_NO_CACHE; или зайти с обратной стороны: включить квери кэш в режим работы только для ряда запросов, помеченных директивой SQL_CACHE.
хорошей практикой будет обычное кэширование на уровне приложения: хоть в файлы, хоть в редис. средствами опенкарта это делается довольно просто. что-то вроде
Spoiler$cache_key = 'foobar.' .(int)$this->config->get('config_store_id');
$data = $this->cache->get($cache_key);
if(!$data){
// .. ваши сложные и долгие вычисления тут$this->cache->set($cache_key, $data);
}-
1
-
-
3 hours ago, PutinVV said:
у меня сервер на reg.ru . ничего не помогает. тормозит при расчете стоимости и все! https://wentklimat.ru . OCStore 3.0.2 с simple
у Вас используется несколько модулей доставки, каждый из которых отправляет запросы на сторонние сервера для расчета стоимости. Разумеется, это требует времени. Ради беглого теста попробуйте отключить в админке опенкарта все эти модули и проверьте, как изменится скорость открытия страницы чекаута; затем включайте по одному и поймите, какой из модулей дает наибольшую задержку. Ну а дальше, когда Вы более-менее установите проблему, ищите решение \ исполнителя.
-
4 hours ago, dmitreach said:
Может кто-то встречался с подобным ?
для больших городов список пвз слишком длинный и не помещается в лимиты, установленные для колонки с данными в бд. просто "расширьте" эти лимиты, изменив тип данных для колонки. например так
Spoiler-
1
-
-
24 minutes ago, Yoda said:
Ну ну, а сколько на трафике в полторы тысячи онлайн эти 0.014 сек, которые не будут 0.014, потому что на больших магазинах таблица огромна. будут выполняться и сколько сьедят ресурсов ?
Совершенно очевидно, что у ТС проблемы попроще. По пути к онлайну в 1,5к уников опенкарт будет ждать 1001 других bottleneck'ов - более серьезных, чем выбор и тюнинг хранилища сессий.
Но вы конечно же так написали, словно не бывает никаких машин кроме бугатти, а если и бывает, то ездить они не способны. Впрочем, мы уже давно знаем, что Вам подобная манера свойственна: крайности, преувеличения, демагогия и всяческие попытки выставить других в плохом свете.
-
5
-
-
2 hours ago, Ebanko said:
Кто-нибудь знает как увеличить кол-во выводимых товаров в категории?
Тема Journal3
J - skins - ваш скин - Product Listing - Products per Page
Spoiler-
1
-
-
1 hour ago, La_Rina said:
Вот только бы еще знать где это поправить .....
Так вы задайте вопрос исполнителям, которые Вам такие id-шники насоздавали. Это вопрос на уровне базы данных, с которой работает опенкарт (типы данных полей).
Дело ведь не только в коробочном функционале опенкарта, который может и скорее всего пострадал. Речь так же и об элементарной совместимости с огромным количеством имеющихся модулей на рынке, которые не умеют работать с такими большими цифрами
-
1 hour ago, Twissell said:
Тем, что Опенкарт проверяет табличку из 10 тыс. строк не истекла ли сессия и эти запросы попадают в slow_log MySQL.
Spoilerдо создания индекса по полю с датой протухания сессии - фулскан таблицы
ALTER TABLE oc_session ADD INDEX IDX_expire(expire);
после создания индекса.
0.014сек без индекса и буквально мгновенно с индексом.
ура?
ко всему прочему а) очистка таблицы сессий - событие не частое. б) таблица в innodb и блокировок параллельных запросов не происходит при очистке.
Итого - если у Вас не миллионы трафика, то проблемы как бы и нет.
-
3
-
Не работает поиск на сайте
в Opencart 3.x: Налаштування та оптимізація
Опубліковано:
как вариант, используется регистрозависимый collation в базе данных (_cs на конце). Загляните через phpmyadmin в структуру таблиц oc_product или oc_product_description, например.
Если действительно дело в этом, то через тот же pma можно изменить коллейшн всех таблиц и полей в выбранной базе данных (выбрать БД в левой колонке - вкладка "операции" вверху - найти в самом низу нужный блок с параметрами смены коллейшена. Прежде чем что-то менять, не забудьте сделать бэкап бд.