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` шваркнуть и ничего не потеряется)

Для начала смотрим что делает движок когда открывает ваш файл $files = glob(DIR_CACHE . 'cache.' . preg_replace('/[^A-Z0-9\._-]/i', '', $key) . '.*'); if ($files) { $handle = fopen($files[0], 'r'); собирает из кеша все похожие на клуч "имя файла" файлы, и у него как бы должно быть расширение, на что нам намекает ".*" в конце регулярки. далее он этот файл пытается фопнуть) и сунуть в переменную, а место открытого потока получаем тот самый Булеан из ошибка, т.к когда файл не открылся фопен плюётся в нас fals`oм. Из чего делаем вывод что нужно выложить сюда var_dump переменной $files и уже думать почему за такое название файла фопен плюётся falsами. Ещё неплохо было бы на само название файла глянуть) Ну и конечно движок может плюнуть в нас фолсом за неправильные права доступа на файл, допустим бэкапнули вы его в своём *юниксе и суёте туда, а бэкапали вы его под рутом, права сохранились, наны красная шапочка)

Восстановление базы через админку идёт асинхронными запросами т.е время выполнения и связь тут не при чём, так что вам нужно либо менять максимальный размер файла который скушает ваш сайт, искать "max_upload_file" в конфигах хостинга и увеличивать. Но это тоже скорее всего не то, ошибку опка кидает обычно при задвоении ключевых полей, нужно смотреть в неё и чистить в базе повторяющиеся поля) К томуже если вам ещё и phpmyadmin то же самое говорит, то это скорее всего повторяющиеся поля

Как правильно сказали выше, не должны пересекаться ключевые поля таблиц, т.е в таблице которую будете переносить нужно поправить ключевые поля, "подвинув" их что бы они были далеко за пределами полей в текущей базе. Например UPDATE `oc_u-table` set `id` =`id` + 10000, или вроде того. Далее можно прямо средствами админки(система-обслуживание-восстановление) выгрузить эти таблицы из старой базы, или если к той базе опк уже не подключен, то сделать это из phpmyadmin и так же средствами админки или phpmyadmin подгрузить эту таблицу в текущую базу ) Не заменить таблицу а именно импортировать когда движок использует для загрузки таблицы Insert по каждому её полю (режим SQL)

Ну тут нужно посмотреть как выглядит query из `oc_seo_url` или какую там таблицу юзает UNI сео. Если ту же самую, то может сам keyword как то не так записан, либо не для обоих языков, а так же удалился ли старый query для этого keyword мб он так и пытается в ту категорию залезть по этому реврайту). А там уже дальше копать)

Да при загрузке приложения как минимум 5-6 pre_action выполняется, которые триггерят все контроллеры из catalog/controller/startup, и да, я сразу сказал что это из разряда фантастики, но всякое бывает. Там всё что угодно может быть, вплоть до задвоенной записи вызова модуля в xml модификаторе. И да помощь нужна не мне) Скорее всего это всё таки js событие либо в сторейдже модификаторов дургой код, мб человек смотрит в обычный контроллер а не в модифицированный) Речь кстати не про триггеры сукеля, а про евенты которые прописаны в самом опке

Странно а мне метод ядра линкующий нужные контроллеры, говорит что pre_action, учитываются и я не вижу никаких условий навроде "идёт вывод модулей" а в сам pre_action можно подсунуть что угодно) А ещё третье поле таблицы "твойпрефикс_"events своим названием trigger SELECT `trigger` FROM `oc_event` , как бы намекает что само событие ты как бы триггеришь. А ещё видов триггеров вагон и маленькая тележка, от отрицания до ячейки памяти, раз уж ты решил писюнами меряться а не по теме помочь) P.S говоря метод ядра я имею в виду public function dispatch(Action $action, Action $error) { $this->error = $error; foreach ($this->pre_action as $pre_action) { $result = $this->execute($pre_action); if ($result instanceof Action) { $action = $result; break; } } while ($action instanceof Action) { $action = $this->execute($action); } } в классе route Да и фреймворк вроде без оглядки на что либо просто тянет все pre_action какие есть из таблицы if ($config->has('action_pre_action')) { foreach ($config->get('action_pre_action') as $value) { $route->addPreAction(new Action($value)); } } В то время как сам эвент возвращает $result без каких либо $this->output, что намекает на то что скрипт может спокойно взять его и работать дальше, exit() не вызван. public function trigger($event, array $args = array()) { foreach ($this->data as $value) { if (preg_match('/^' . str_replace(array('\*', '\?'), array('.*', '.'), preg_quote($value['trigger'], '/')) . '/', $event)) { $result = $value['action']->execute($this->registry, $args); if (!is_null($result) && !($result instanceof Exception)) { return $result; } } } }

Код вызова контроллера в студию, конец индекса вызываемого модуля навроде this->output->loadview('*.twig') тоже. Ещё есть около фантастический вариант, что этот модуль триггерит один из евентов, а тот вызывает его повторно, так что в них тоже можно посмотреть

Добрый день) ну если его кто то сделал, вполне вероятно он сделал и редактирование цветов в админке, а где и какие файлы редактировать понятие очень растяжимое. Цвет может устанавливаться как из настроек в бд так и вообще хардкодиться с помощью модификаторов css файлов или в Js, каких извращений я только не видел) Файлы на хосте лежат скорее всего как обычно, ещё лучше попросить у хостера или посмотреть в настройках хостинга свой акк доступа по ftp лезть туда через файлзиллу какую и колупать что то навроде catalog/view/template/*/stylesheet/css,js,bootstrap и т.д) А вообще если ничего не понятно, то лучше отдать задачу на оутсурс, а то можно и сломать чего)

Откуда конкретно твой модуль берёт эти товары смотри в catalog\model\*\модуль_нейм, в обычном опенкарте они находятся в бд (SELECT * FROM `oc_product_attribute`) Если они есть в морде каталога а в админке нет, скорее всего твой модуль тянет их откуда то ещё)

А показать дамп $data[‘weight’] ?) может оно и не встало вовсе. Если встало и всё равно не видно, проверяй код страницы в html. Если там стоит и всё равно не видно, верстай. Если ничего не помогло чисти кеш и сайта и браузера, да с очистки кеша можно было и начать)