Собственно сам вопрос в заголовке. Есть плагин доставки. Выпускается обновление для него, которое требует модификации настроек. Код, который должен быть выполнен однократно (метаобновление). Размещение по аналогии с приложением и плагином приложения в lib/upfdates не работает. Ну собственно в таблице wa_app_settnigs ничего и нет про системные плагины. Может всё-таки механизм такой есть? как обновить?
Опишите подробнее суть изменения настроек.
В большинстве случаев удается добавить новые настройки с корректными значениями по умолчанию, а для старых в методе getSettings сделать корректную трансформацию (например из единичного значения в массив и т.п.)
Нет такого механизма. Плагины доставки (и оплаты) ничего не знают про то, где хранятся их настройки. Это связано с тем, что бывает много "копий" одного плагина, причём иногда принадлежащих разным приложениям. Даже если бы для системных плагинов работал механизм метаобновлений, обращаться оттуда к shop_plugin_settings в любом случае было бы неправильно.
Если метаобновление прям очень-очень нужно и без него никак, можно изобрести такой велосипед. Проверять наличие ключика (например, version) в момент получения настроек из адаптера. В зависимости от значения запускать или не запускать своё метаобновление и перезаписывать ключ.
Но лучше так не делать. Лучше спланировать изменения в коде с обратной совместимостью, чтобы плагин работал на старых настройках без всякого метаобновления.
Чисто теоретический интерес: а если речь не об обновлённых настройках способа доставки/оплаты/SMS, а о необходимости почистить код плагина от старых файлов, которые больше не нужны в новой версии? Или, если плагин вдруг использует свою таблицу в БД и нужна разовая корректировка её структуры/значений.
А как плагин доставки, интересно, создаст эту свою таблицу :) в системных плагинах ни db.php, ни install.php не поддерживаются. Опять-таки по причине нескольких копий плагина в системе.
Если плагин таблицу как-то создал, значит, у него есть изобретённый велосипед, как определить, что это первый запуск плагина такого типа в системе. А если такой велосипед всё равно есть, он как-нибудь и версионность тоже отследит.
Вопрос про старые файлы интересный. Хорошего решения, похоже, нет.
Из трёх десятков системных плагинов вебасиста пока ни одному не понадобилась ни своя таблица, ни метаобновление. Каждый плагин-то состоит всего из пары файлов. По этой причине базовый функционал тоже без наворотов.
Мой вопрос был простой - есть или нет такой механизм. Почему разработчики не захотели реализовать данный функционал меня уже не волнует. Это просто ещё один минус к отсутствию документации и реальной поддержки разработчиков (коя должна быть, раз нет документации - форум где страдальцы типа меня обмениваются своими велосипедами с квадратными колёсами не в счёт).
Ну и как закатывать солнце вручную или удалять гланды через а-ое отверстие я смогу сообразить. Моя первый рабочий промышленный код был написан ещё в 80-ых прошлого века.
Вопрос то решен с удалением не актуальных файлов???
Пример ели не сложно. =)