Search the Community

Уже третий раз натыкаюсь на довольно неочевидный баг. В validate идет XHR (и, соответственно, редиректится при обнаружении параметров для реврайта), который должен игнорироваться. Лечится добавлением detectAjax system/library/seopro.php ищем public function validate() { после добавляем $this->detectAjax(); получается так public function validate() { $this->detectAjax(); // Снова проверяем // break redirect for php-cli-script if (php_sapi_name() === 'cli') return; ... UPD: после этого не забудьте обновить модификаторы! UPD2: проверять в режиме инкогнито браузера!

Скачать / Купить дополнение TS Fix Analytics List Поддержка больше не осуществляется! Модификатор Fix Analytics List v1.0 by Tramplin Studio исправляет баг связанный с некорректным отображением списка модулей в разделе расширений "Аналитика" (или "Статистика") в версиях OpenCart/ocStore 2.2 и 2.3. В обновлении версии OC 2.2, в разделе аналитических расширений, для каждого отдельного магазина появились свои настройки. Это было очень полезным нововведением, но была допущена ошибка при формировании таблицы, которая была устранена лишь в версии OC 3.0. Как проявляется ошибка? Если у вас установлен только один аналитический модуль, скорее всего это простой базовый модуль "Google Analytics", то вы ничего не заметите. Однако если у вас установлен еще один модуль (например наш модуль "TS Yandex Metrika") или несколько, то доступны будут лишь магазины последнего в списке модуля. Магазины других модулей не отобразятся, их настройки будут не доступны. После установки модификатора Fix Analytics List вы сможете видеть все магазины, всех модулей. Полезные советы: Если вы серьезно относитесь к конверсии вашего интернет-магазина и вам важно знать все о действиях посетителей, тогда наш модуль "TS Yandex Metrika" может быть вам очень полезен! С этим модулем вы сможете передавать сервису Яндекс.Метрика не только такие простые данные как переходы по ссылкам и клики, но и подробную информацию о посетителях сайта, данные электронной коммерции, а также настраивать цели для отслеживания конверсий, не прибегая к вмешательству в код сайта и не обладая глубокими познаниями в веб-разработке. ----------------------------------------------------------------------------------------------- Смотреть DEMO админки (логин: demo, пароль: demo) ----------------------------------------------------------------------------------------------- Инструкция по установке: Перейдите в Панель администратора -> Модули -> Установка расширений; Загрузите архив с модулем для вашей версии OpenCart или ocStore; Обновите кеш модификаторов. Файлы не перезаписываются! Используется OCMod! ----------------------------------------------------------------------------------------------- Данный модификатор является завершенным продуктом. Дальнейшее обновление модификатора маловероятно. Добавил TramplinStudio Добавлено 28.07.2019 Категория Прочее Системные требования Метод активации Без активации Ioncube Loader Нет ocStore 2.3 OpenCart.Pro, ocShop Обращение к серверу разработчика Нет  

Третьего дня столкнулся с непонятным: при удалении обычного дополнения через установщик и загрузке его обновленной версии на боевой сайт - ряд других дополнений превращались в "кирпич", а движок начинал ругаться на отсутствие части файлов, связанных с ними. Вариант с "кривым" дополнением был отброшен изначально, т.к. а) собственно и являюсь автором дополнения б) создано согласно стандартам движка и не в первый раз; структурно не отличается от других в) перед загрузкой прошло полную обкатку на тестовом окружении В процессе препарации выяснилось, что виновник - штатный деинсталлятор дополнений в Opencart 3x При установке любого дополнения в тройке - информация о содержащихся в нем файлах и папках записывается в смежные таблицы oc_extension_install и oc_extension_path И при удалении через штатный деинсталлятор - относящиеся к дополнению файлы и папки удаляются именно на основе этих данных При создании дополнений многие авторы используют отдельные папки, общие для файлов своих дополнений (например для своих библиотек в system/library, скриптов в catalog/view/javascript и тд) или используют универсальные файлы, содержащиеся в каждом их дополнении Беда в том, что в процессе удаления совершенно не учитывается возможность использования этих файлов и папок другими дополнениями. Фактически: 1. Если ряд дополнений использует свою собственную общую папку, которой нет в движке по умолчанию - такая папка создается при установке первого дополнения и привязывается к нему в таблице oc_extension_path в момент создания. При этом, при установке последующих дополнений, использующих данную папку - привязки не происходит, так как папка уже есть Но при удалении именно того дополнения, к которому произошла привязка папки - ПАПКА БУДЕТ УДАЛЕНА СО ВСЕМ СОДЕРЖИМЫМ БЕЗ КАКОЙ-ЛИБО ПРОВЕРКИ т.е. со всеми другими файлами, которые могут не иметь отношения к удаляемому дополнению, и используют эту общую папку для хранения своих файлов. 2. Если в ряде дополнений используются какие-либо общие файлы (например универсальные вспомогательные классы, библиотеки и тд) - удаление такого дополнения через деинсталлятор приведет к удалению этих общих файлов Ладно, если пользователь переустанавливает или ставит новую версию дополнения, содержащую эти же файлы - тогда они просто будут добавлены заново. В случае же, если дополнение просто удаляется за ненадобностью или в его новой версии уже нет таких файлов - их отсутствие просто приведет к неработоспособности всех использующих их модулей. На текущий момент данная проблема актуальна для всех движков третьей ветки (3000-3031) и сборок на их основе (включая ocStore 3020) И судя по исходникам на гите - еще и для беты 3100 (хотя в ней и добавили проверку перед удалением папки, но проверки на уникальность самих файлов по-прежнему нет) лекарство здесь