Лидеры

Сделал модификатор для вывода коллекций в товарах, по описанному принципу, проверил - все работает. Если кому надо, выкладываю тут. Это мой первый опыт создания модификатора.

еще не забыть про RewriteCond %{REQUEST_FILENAME} !-d

Функционал префиксов добавлен в сборку. https://github.com/OpenCart-Club/opencart/commit/0bbda1070e2505d8add2ca7c18bd55d65e7b3726 Настраивается в коде библиотеки catalog/controller/startup/seo_url.php

Решение для Seopro, для тех кому нужен префикс по принципу : сайт/catalog/категория сайт/catalog/категория/товар Префикс catalog можно сменить на любой свой. Подробности в ридми внутри архива. seopro_prefix.ocmod.zip

можете попробовать вот так. фиолетовым выделил критичные для Вас строки конфига. Это упрощенный пример конфига проекта, где этот модуль мультиязыка исправно работает ... location / { try_files $uri $uri/ @opencart; location ~ [^/]\.ph(p\d*|tml)$ { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?_route_=$1 last; } try_files /does_not_exists @php; } ... } location @opencart { rewrite ^/(.+)$ /index.php?_route_=$1 last; } location @php { fastcgi_index index.php; fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f webmaster@???"; fastcgi_pass unix:/var/www/php-fpm/1.sock; fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$; try_files $uri =404; include fastcgi_params; } ...

Не хватает очень важной настройки. Да и в принципе не раскрыта тема настройки конфига для самого php-fpm, а его настройка по-умолчанию оставляет желать лучшего. Как известно, режим nginx+ php-fpm чреват "сюрпризами" в виде утечки памяти. Это в конце концов приводит к тому, что спустя несколько дней память будет использована под 100%, а сервер, соответственно, ляжет. Поиск через поисковики показывает, что проблема эта глобальная и давняя. Т.е. это не единичные случаи, это повальная проблема. Разрастаются в потреблении памяти дочерние процессы php-fpm. Проявляется не на всех версиях php, в частности на 5.6 я этой проблемы не наблюдал, но на 7.* - это будет почти всегда. поэтому к конфигурации самого php-fpm нужно подходить не менее тщательно, чем к конфигурации nginx. Я неоднократно писал об этой проблеме на разных форумах. И неоднократно же ко мне обращались за решением данной проблемы. pm.max_requests = 1500 Слишком малое значение не стоит устанавливать. Это значение зависит от доступного объема памяти сервера. Конечное значение подбирается опытным путем. Это максимальное количество запросов max_requests до перезапуска процессов FPM. На остальные параметры также обратите внимание. На скриншоте файл конфигурации, редактируемый через панель управления aapanel, но сама панель управления не имеет значения, т.к. принципы едины.

Встроен. Только у вас то не это , а OpenCart 3.0.3.8 (Русская сборка) и чей то иной модуль Seopro. Его в OcStore в отдельном виде нет. Это часть этой сборки неотъемная. Вы кстати на этом форуме можете посмотреть сборку. В ней и преимущества Ocstore и вот эти суффиксы из настроек задаются. https://opencart.club/forums/topic/9-opencart-3-club-edition-russkoyazychnaya-sborka-openkart-support/

Поправил

Все правила лучше вносить в общую секцию "location /" Чтобы не получить приключений, там где не надо. Так же в эту секцию стоит внести и конфиг для php, который подключается. И при этом надо не сделать конфликтов для панели, когда там редактируются параметры, панель тоже меняет конфиг частями.

Фишка эта обычно нужна для переезда с иных CMS. Как насчёт префикса только в категории? сайт/catalog/категория сайт/catalog/категория/товар То есть без "product". В практике часто именно так выглядят ссылки.

if ($host ~* www\.(.*)){ set $host_without_www $1; rewrite ^(.*)$ http://$host_without_www$1 permanent; }

Поддерживает. Но автор указал , что из сборки OcStore. Речи о сторонних модулях (всех подряд) не шло.

В вашем случае нет готового решения. Так как у вас используется сторонний модуль Seopro который ни учтён в данном топике.

@ncv Готов обкатать и дальше развивать, как появится время и скилы, на своём проекте.

Создаёте в корневой папки сайта папку, например www, и в неё помещаете сайт, а в настройках домена aaPanelи указываете папку www как папку для запуска сайта, а папку storage располагаете рядом с папкой www. Таким образом бэкапиться будет всё содержимое корневой папки сайта.

Не хватает решения для брендов. В опенкарт по-умолчанию сайт/brands И сайт/название бренда Теряется префикс /brands/

Это зависит от используемой сортировки. Можно отсортировать по нужному критерию и они будут те же. Можно сделать сортировку по RAND() и они будут всё время разные.

Скачал оба. Но ссылки всё равно вида сайт/catalog/категория и сайт/product/категория/товар А не сайт/catalog/категория сайт/catalog/категория/товар без "product".

В конфиге nginx должно присутствовать правило примерно вот такого вида: location @php { fastcgi_index index.php; fastcgi_param PHP_ADMIN_VALUE "sendmail_path = /usr/sbin/sendmail -t -i -f webmaster@???"; fastcgi_pass unix:/var/www/php-fpm/1.sock; fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$; try_files $uri =404; include fastcgi_params; } Оно может отличаться по параметрам в зависимости от настроек окружения. Именно на него и идёт ссылка "@php" Если его не будет, то это и приведёт к ошибке.

100napb, попробовал ваш вариант, вроде все работает без ошибок, если найду ошибки то отпишусь в теме. Большое вам спасибо!

Дождались. ioncube исправили собственную ошибку в лоадере. версия 12.0.4 Они эту ошибку четко признали. лоадеры до (более ранние) версии 12.0.4 (исключая это версию) содержат ошибки. Горе тем хостерам, которые бегут впереди паровоза и спешат ставить сырой софт, не думаю о своих пользователях. Зачем спешили? Опытные хостеры всегда выдержат паузу в несколько месяцев когда в сыром продукте отловят большинство багов, и опытные хостеры не превращают свой хостинг в площадку для экспериментов и вылавливания багов. Да, ошибка именно в лоадере, т.е. покупка нового ioncube энкодера и перекодирование кода проблему никак не решили бы.

В настоящий момент с точностью 100% известно, что в ioncube loader 12 присутствует баг. И вызывает его всего одна строчка абсолютно валидного кода. Если вы после этой строчки (в любом месте) сделаете код (любые операции с переменными-строками вызывают строки с "нулями"): $x=''; echo $x; то получите вывод тех самых битовых "нулей" вместо пустой строки. Т.е. неработоспособную программу (для теста) достаточно написать из двух-трех строк. Баг возникает не в движке PHP, а именно в ioncube loader 12, в одной из ее функций, которая в предыдущих версиях (10, 11) работала исправно (т.е. на протяжении 6 лет), но дала сбой в 12-й версии. К сожалению компания ioncube крайне закрыта в плане общения и информации, обсуждения и подтверждения багов и т.д. Вы даже через поиск не найдете форум самой ioncube , хотя он был раньше, и на нем обсуждались проблемы ioncube . Они просто удалили форум как "ненужный" элемент поддержки пользователей и спокойно сообщили об этом: https://blog.ioncube.com/2022/04/01/what-happened-to-the-forum/ А то мало ли что... Станут пользователи публично сообщать на форуме о найденных багах. Раньше писали же. Ну разве это нужно компании?

От аномального поведения невозможно избавиться. удаляем NULL байты, но вместо удаления либо появляются новые, либо удаляются только конечные и начальные. Чудеса! Точнее, это баги. Пробовал так бороться: $pattern_for_tags = ''; $pattern_for_tags = str_replace("\0", '', $pattern_for_tags); echo "\nЭто тоже после удаления NULL-ей pattern_for_tags\n"; echo $pattern_for_tags; $pattern_for_tags = trim($pattern_for_tags); echo "\nЭто тоже после TRIM pattern_for_tags\n"; echo $pattern_for_tags; Но, как говорится фиг вам. php с кубом стоят на своем. видимо, без покупки енкодера 12 удивительный баг не побороть. Хороший маркетинговый ход у разработчиков ионкуба. Создать баг в новом loader-е, для исправления которого нужно купить новый энкодер 12-й версии за $300. И то, если его еще продадут вам. Разработчик то в Англии. Видать, с продажами энкодера 12-го совсем плохо. Да и зачем он нужен то? Поддержки php 8 в нем нет и не будет. А кому нужна поддержка 8.1, собственно, для которой он и сделан? И, не факт, что применение 12-го энкодера позволит решить проблему. Это как лотерея. Может быть, что это неустранимый баг 12-й версии ioncube loader-а.

PHP Warning: [obfuscated](): Null byte in regex in вот такая ошибка движка PHP появляется при смене ioncube loader на 12-ю версию. сопровождаться может также 503-й ошибкой сервера и т.д. на деле нет никаких null byte в regex. Речь про исходный код и про переменные в процессе выполнения. Специально смотрел с отладкой. Чистой воды баг от ионкуба. Если в журнале ошибок опенкарт увидите вышеприведенную ошибку (Null byte in regex), то смотрите версию ионкуба. через phpinfo(). Ее генерирует именно 12-й ионкуб. Версию ioncube loader меняет хостер на общем хостинге. Релиз 12-й ioncube loader стартовал в середине августа 2022-го. Т.е. пока крайне сырая версия, но некоторые хостеры поспешили уже перейти с 11-й на 12-ю. Хотя обычно дают устаканиться сырому продукту, т.е. дожидаются когда массовые баги отловят в первые несколько месяцев. Месяц-два - это не срок чтобы такого рода продукт перестал быть сырым. Пользователям VDS автоматический переход на 12-ю не грозит. Не возникает проблем на любой версии PHP от 5.6 до 7.4 включительно с ioncube loader 10-й или 11-й веток. Многие хостеры дают возможность выбора версии ioncube loader. Во избежание проблем выбирайте 10-ю или 11-ю версию. По идее компания ioncube старается обеспечить обратную совместимость программ (и энкодеров более ранних версий) со всеми версиями ioncube loader. Но когда это не получается у компании ioncube , то она предлагает перекодировать программы новым энкодером, т.е. энкодером 12-й версии чтобы не было проблем с ioncube loader 12-й версии. Так компания ioncube видит работу над устранением багов, порожденных самой же компанией ioncube. Чтобы устранить баг компания ioncube предлагает купить 12-й энкодер.

Да, не учел) Вроде как, решается парой строк, на неделе обновлю файлы. Спасибо!

Ну из тех просьб, что мне озвучивают чаще это первые скажем несколько символов в названии, так как обычно полное название содержит уже какие то особенности. Как вариант магазины мебели (шкаф, кровать, диван, банкетка). Рыболовные снасти (леска, удилище, блесна). Ну итд итп.

Все правильно написано, чуть дополню... Универсальных настроек конечно не существует, каждый сервер настраивается под определенный проект. request_terminate_timeout - переменная отвечающая за максимальное время выполнения процесса прежде чем он будет уничтожен. pm.max_requests - в данной переменной выставляется максимальное количество запросов, после чего произойдет сброс процесса и память не будет переполняться. Маленькое значение плохо, так как приведет к частым перезапускам процессов и следовательно к уменьшению производительности. Узнать потребление памяти Active и Inactive можно командами по SHH: free -h (в гигабайтах) free -m (в мегабайтах) или cat /proc/meminfo --------------------------- Очистка cashe памяти, три варианта без прерывания каких-либо процессов или служб. 1. Clear PageCache only. sync; echo 1 > /proc/sys/vm/drop_caches (очистка кеш страниц PageCache) 2. Clear dentries and inodes. sync; echo 2 > /proc/sys/vm/drop_caches 3.Clear PageCache, dentries and inodes.(очистка сразу всего, не рекомендуется сразу) sync; echo 3 > /proc/sys/vm/drop_caches --------------------------- Что потребляет больше всего оперативной памяти? Команды: top Сортировка по объёму памяти: shift+M Сортировка по времени shift+T Cортировка в одну или в другую сторону (использовать, чтобы больший параметр был вверху) shift+R Клавиша «Q» — выйти из команды Top.

разумеется, что все имеет значение. минимально, что стоит сделать - это подстраховаться от утечек памяти. т.е. это нужно прописывать обязательно. Даже можно немножко пожертвовать производительностью, но увеличить стабильность. Просто для тех, кто решил перейти на php-fpm, утечка памяти - это самая распространенная неожиданность. Крайне неприятная неожиданность. И это не зависит от самого веб-сервера, это может быть Апачи или Nginx, в данном случае не имеет значения, т.к. корень проблемы кроется именно в процессах php-fpm, которые в принципе могут быть вообще и без веб-сервера. Тонкую настройку можно сделать после, но подстраховку от утечек нужно делать сразу. Это чтобы не перезапускать весь сервер пару раз в неделю после очередного зависания.

Да. Тут даже и не весь конфиг описан по настройки самого nginx. Цель была сделать упор именно на особенность настройки для OpenCart. Кстати уже не на первом проекте замечаю, что такая беда уже имеет не такой повальный характер как раньше. Прогресс всё же не стоит на месте. И уже не везде встречается пила по потреблению памяти. В последнее время сервера попадались Debian и Ubuntu (для справки). Настройке параметров процессов можно отдельную статью посвятить. Но там уже не всё так просто, т.к. зависит от ресурсов сервера. Да и от посещаемости тоже зависит.