100napb

и правда. прошу прощения. Заголовок топика стоило бы перечитать. если при(после) открытии в админке страницы настроек фильтра в жорнале Вы не видите: - ошибок в консоли браузера - ошибок в журнале опенкарта - ошибок в логах веб-сервера(php) то... - Вы можете просмотреть список модификаторов/модифицированных ocmod'ами файлов на предметчего-нибудь интересного - например, модификации файлов админки. - по одному отключать все новые модули/модификаторы и проверять - полазить по контроллерам и моделям жорнала и попытаться понять логику работы административной панели управления фильтром (начать хотя бы с /admin/model/journal3/journal3.php, /admin/controller/journal3/journal3.php ) - попытаться создать тикет в официальном саппорте - обратиться в раздел платных услуг за помощью.

уточните версию жорнала, хотя бы. в Journal3, например, все атрибуты/опции в админке должны появляться автоматически после их добавления в опенкарте. Так же, каждый параметр фильтрации включается/выключается/настраивается отдельно. вот как тут, например Проверьте, что все нужные(новые) атрибуты или опции есть в настройках фильтра в жорнале и они включены.

Агата, как считаете, стоит ли дополнить условие для очистки сессий, типа: if ($this->db && rand(0, 100) > 99) { Что бы создать своеобразный аналог session.gc_probability и session.gc_divisor. Избыточно гонять этот sql-запрос при любом\каждом запросе страницы.

на всякий случай тыкните кнопочку, которая перечитывает атрибуты из "стандартного представления Opencart3". актуально, если указан разделитель, если не ошибаюсь J -> system -> system

да все просто. вот минимальный шаблон из трех локейшенов, которые обеспечат работу ЧПУ. выше уже писали - нужен. nginx нужен как минимум что бы разгрузить тяжеловесный апачи от отдачи статического контента. так же он несколько экономичнее в потребляемых ресурсах. ну и конфиги более прозрачные\гибкие, в целом, если не брать в расчет некоторый геморрой в переводе правил из htaccess в конфиги nginx. Nginx желательно иметь и большому и малому магазину. Либо перед апачи, либо перед php-fpm - какой-то прям космической разницы нет, при адекватных настройках.

Journal - Skins далее в левом меню в разделе pages выбрать пункт checkout . откроются настройки далее в секции general выбрать Active Checkout = Journal (если не выбрано) далее в секции Sections настроить необходимые блоки

case вполне себе применим. будет что-то вроде ... order by case when sort_1 < -1000 then sort_1 end asc, case when sort_2 > 0 then sort_2 end desc, case when sort_1 > 1000 then 3 end desc; альтернативный вариант: добавление виртуальной колоноки в таблицу с вычисляемым значением, которая бы задавала нужный порядок сортировки или эти же вычисляемые значения добавить в select-секцию и уже по ним делать сортировку.

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

в файле /system/library/seopro.php ищите public function baseRewrite. Красным выделил то условие, которое необходимо добавить. После изменения файла не забудьте обновить модификаторы на всякий случай. из коробки у J3 еще и ЧПУ блога не дружит с сео-про. но там все несколько сложнее...

.

/system/config/default.php примерно 36 строка.

Подключите дебаггер к опенкарту. Что бы и время выполнения запросов к бд на странице подглядеть, и время работы контроллеров. С высокой долей вероятности локализуете проблему. очевидно, что есть некий тяжелый участок, который благополучно кэшируется. И он требует оптимизации для быстрой работы на холодную. А что там по факту окажется - об этом и пишите/спрашивайте, если не сможете решить. Так вероятность получить ответ будет в разы выше

забейте в гугле что-то вроде "Автоматически рекомендуемые товары opencart" на этой площадке продажи модуля вроде как приостановлены были. На других он есть. Позволяет выводить в карточках блоки похожих товаров на основе гибких правил На тех.поддержку от автора можете особо не рассчитывать, но, возможно, сам модуль - именно то, что Вам нужно. Не так давно сталкивался с ним в очередной раз - автор переписал логику и теперь он работает вполне себе шустро (с полгода-год тому модуль давал конскую нагрузку на базу данных и карточки товаров тупили). Можно даже похвалит

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

как вариант, collation был разным. из-за этого запросто может быть content_top != content_top и все то, что Вы и ТС описывали. Было бы неплохо взглянуть на буржуйский скрипт - чего он там с таблицами делает. MyISAM - > InnoDB конвертнуть проще простого. Хоть так, например.

Вы определитесь, какое из этих утверждений истинное. Может, конечно, я Вас наверно понимаю, но Вы вроде как сами обозначили проблему: зашел в карточку товара, а картинки нет. Anyway, добавить особо нечего: никакие приведения картинки не крадут) либо их что-то при каких-то обстоятельствах удаляет, либо веб-сервер не отдает, либо... может быть еще какой-нибудь js-скрипт у Вас работает для встраивания картинок в html-код (дайте ссылку на сайт в личку, пж) и иногда работает некорректно...

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

Раз уж добрались до таблицы product_image, посмотрите какое там крайнее значение id. Вдруг в диапазон int не умещается.

на случай, если пропустили. вдруг то что нужно. Во всяком случае, можно и вручную баланс карточек менять, так и автоматом - при смене статусов заказов

а.. теперь теплее. в таком случае, может быть так? SELECT (SELECT t2.meta_h1 FROM table_2 t2 WHERE t2.lang_id = 1) meta_h1, (SELECT description FROM table_1 t1 WHERE t1.lang_id = 1 AND t1.store_id = 2) descriptions

эм... так вроде бы так SELECT meta_h1, description FROM table_1 t1 JOIN table_2 t2 ON t1.language_id = t2.language_id WHERE t1.language_id = 1 AND t1.store_id = 0

в админке, в левом меню Journal - Header - Main Menu - Desktop или Mobile (они разные) - в самом низу выбираете Dropdown Type (скорее всего Вам интересны будут либо Mega Menu, либо FlyOut) если FlyOut - то выбираете уже конкретный модуль для отображения из списка Journal - modules - Flyout menues если мегаменю, то прямо там же, в Builder'e создаете макет\структуру и назначаете конкретные блоки

виртуализация она такая =\ не знаю конфигурации сервера и нюансов, но стоит попробовать skip-innodb-doublewrite innodb_file_per_table tmpdir = /dev/shm tmp_table_size = 128m max_heap_table_size = 128m bulk_insert_buffer_size = 128m больше особо нечего ковырять. разве что погуглить и поиграться с thread_pool_size. Но если ядер маловато, то вреда может быть меньше, чем пользы