ArtValensky

это уже уязвимости библиотек и протоколов из запчастей которых и писана сама cms, что именно там и как работает я не знаю к сожалению) в статье которую я давал выше про это больше написано. Могу только сказать что лучше использовать smtp)

Ещё как вариант можно использовать опции в формате "аля алиэкспресс" то есть создаёшь товару опции "гречька супчик русиано", "гречька супчик", "супчик русиано" и т.д, на али бывает по 100 видов комплектации товаров и нормально "пипл хавает". И не нужно городить сторонних модулей и прочей ахинеи. Ну и соответственно в опциях можно и цену указать опции и тогдалее. https://ru.wikipedia.org/wiki/Бритва_Оккама

Ну если в категории или в информационной какой странице такого не происходит. Значит причина в том, что есть только на странице товара или на главной) скорее всего это может быть какой нибудь модуль навроде "вы смотрели" или "хит продаж" попробуйте их пощёлкать. А ещё лучше полный лог почитать)

там релизный апдейт, ничего толком не изменилось, думаю что заработает и на 3.0.3.3, скорее всего разрабы модуля просто поленились потестить и вписать новую допустимую версию)

Будет с вероятностью 99.9%. А если не будет то поправить будет быстро и легко, там отличия то в основном в локализации, да в допиливании некоторый функций аля - оплата киви

ну если у вас vds(*nix) или ему подобное то прям по тем путям которые я указал скорее всего настройки и лежат, если хостинг то ищите что то вроде mysql wait_timeout или русский вариант может быть вроде "таймаут запроса бд" и т.д. И ещё раз повторюсь лучше копать дальше, дампать запрос который "не успел" и править именно это. Иначе потом возможны хорошие такие тормоза на сайте, а может этот запрос и все 120 секунд будет крутиться, может там рекурсия какая "нечайно случившаяся". А при выполнении какого запроса у вас происходит такая ошибка?)

/etc/mysql/my.cnf поменяй wait_timeout поставь побольше, секунд 120. не забудь systemctl restart mariadb(или чё там у тебя). Самая частая причина ухода сукеля поспать А если делать по человечески, то лучше выяснить что такое у тебя там отправляется дольше 60 стандартных секунд в сукель

Что бы перенести модификатор из файлового формата в "модификаторы" я так понимаю в установленные модификаторы, нужно создать запись в "oc_modification" все поля заполните примерно как у других модификаторов, там интуитивно понятно имя и т.д. а в поле xml запихнуть текст из самого файла модификатора. Более подробно об этом процессе вы можете узнать соответственно из admin/controller/marketplace/modification и amin/controller/marketplace/installer. И помните что каждый xml модификатор несёт с собой хаос, разруху, неподдерживаемость кода и вообще лютую попаболь для любого разраба, уж лучше сделайте контроль версий и правьте файлы самого движка)

форма <form action="index.php?module=register&actionregister" method="post" id="MyForm"> <input>[...]</input> </form> jquery $.ajax({ type : "POST", cache : false, url : $('#MyForm').attr('action'), data : $('#MyForm').serializeArray(), success : function(data) { $(".printArea").empty().append(data).css('visibility','visible'); } }); если прям лень вешать слушатели на кнопку и т.д поможет всё по запросу "form action ajax"

Я думаю это стандартная уязвимость php mail(), когда переехал на vds тоже с таким столкнулся, уж не знаю создаю эти хуцкеры свою форму и через неё шлют сообщения от вашего имени или ещё что. Но стоит включить стандартный протокол почты в опке как эти жучары сразу лезут в мою почту. Есть простой выход это использовать SMTP и любой ящик. есть более сложный с перепиливанием стандартной мейл функции и требованием капчи) А вообще если попробовать $php -a и там поковырять mail() то там в принципе кем угодно можно представиться и слать что угодно куда угодно) Ещё возможно стоит убрать формы обратной связи по почте, заменив их заказом обратного звонка, ну или хотя бы капчу туда прикрутить) Сторонние модули обратной связи повышают такой шанс в разы) Internal server error ваш связан с любой ошибкой при доступе к ящику по smtp, но их не так много, и самая частая в том что забыли дописать ssl:\\ к смтп хосту либо не так его указали. Вбиваете в гугл "настройки smtp и доменящика(yandex, mail, etc...)" и смотрите как конкретно этот провайдер предоставляет ящик под смтп Вот в кратце про уязвимость этой библы -> https://xakep.ru/2017/01/12/phpmailer-exploit/#toc02.

Ну я и написал, что "если планируется загрузка большой даты в конфиг" а не создавать таблицу на каждый чих. А создать таблицу вообще дело пары минут, да и модельку нарисовать) Если человек пишет модуль поди разберётся)

Ох спасибо) теперь я больше понимаю синглтон, я думал это просто обьект доступный во всех частях приложения, но даже не думал что он должен иметь лишь одну реализацию, и вообще кругом статика. Но я всё же думаю что сеттингсы это плохо. Всё что серве отдаёт на исполнение, вызывает startup и загрузку всех данных из oc_settings, т.е в дальнешем на каждый чих из js или ещё чего будет грузиться раздутый settings из базы)

К сказанному выше добавлю, что по вашим сеттингам движок при каждом старте формирует огромную синглтон переменную, выкачивая всё из `oc_settings` и если планируете заливать много данных. А раз встал вопрос о скорости - вы планируете. То лучше создать отдельную таблицу и записать туда. Иначе при каждом "зайду гляну чё у них там нового на главной" пользователь будет ждать пока ваш движок вытянет данные из настроек. Вообще синглтон чуть ли не антипаттерн, не советую злоупотреблять сеттингсами) Даже крупные мододелы, аля яндекс.касса или СДЕК выносят свои обьёмные данные во внешние Json файлы, но это делается ради целостности пользовательского приложения, плаг-н-плей так сказатб) ничто не мешает завести свою табличку)

Да, это sql запрос, он полностью очистит всю таблицу) и ничего страшного всё равно не случится)

oc_session можно смело затирать и забывать её) это просто данные по текущему подключению к сайту для каждого пользователя. Типо информации введённой в какое либо поле на сайте) или авторизации) можно вообще TRUNCATE `oc_session` шваркнуть и ничего не потеряется)