Проверка что плагин включен в приложении.

Николай Иванов

Недавно понадобилось выяснить причину тормозов на сайте.
Повыключал все плагины в plugins.php магазина но это не панацея, так как директория с плагинами все равно считывается и классы плагинов доступны. А в шаблонах весьма распространено включение хэлперов плагинов без проверовок. А так, у некоторых плагинов есть свои(!) методы для вкл/выкл. А некоторые оборачивают хэлпер в проверку по class_exists и т.д. Короче кто во что горазд.

Собственно вот в чем вопрос - есть ли универсальный способ проверки вкл/выкл плагина в конфиге конкретного приложения?
Если нет, то предлагаю включить в хэлпер wa() что-то вроде

    public function pluginEnabled($plugin = null) {
        if (!is_null($plugin)){
            $plugins = wa()->getConfig()->getPlugins();
            if (in_array($plugin, $plugins)){
                return true;
            }
        }
        return false;
    }

это сделал на скорую руку для магазина, ну и проверка соответственно

{if $wa->shop->pluginEnabled("quickorder")}
    {shopQuickorderPlugin::quickorderForm($product)}
{/if}

Привить разработчикам любовь к использованию таких конструкций в инструкциях и готовых темах и будет всеобщее счастье и ликование.

24 июля 2017
  • Eugen Nichikov 24 июля 2017 18:26

    Вот обсуждали нечто подобное.

    Но из этого родилась, имхо, более гибкая конструкция.

    Все статические хелперы от лукавого.

    Вместо вот этого

    {if $wa->shop->pluginEnabled("quickorder")}
        {shopQuickorderPlugin::quickorderForm($product)}
    {/if}

    Можно вызвать

    {$wa->event("shop", "quickorder.form")}

    И вообще не заботиться ни о каких проверках!

    Сюда же при желании можно передать параметры, которые могут быть изменены в плагине

    {$wa->event("shop", "quickorder.form", $product)}

    Если плагин не подписан на событие custom.quickorder.form, то его вызов ничего не поменяет.

    Более того. Конструкция будет спокойно ничего не возвращать, даже если магазин не установлен.

    Несколько плагинов спокойно могут использовать один кастомный хук как, например, в head.html приложения "Сайт":

    {$wa->event("shop", "frontend_head")}

    чтобы избавить владельцев магазина от необходимости каждый раз прописывать одинаковые по функциональности конструкции в один и тот же шаблон.


    Разработчики тем дизайна войдя в преступный сговор с разработчиками плагинов смогут устанавливать кастомные события сразу в темах не боясь ничего сломать и не городя трёхэтажных конструкций в шаблонах.

    Но для начала нужно решить вопрос вот с этой темой

    https://developers.webasyst.ru/forum/20632/kogda-p...

  • Eugen Nichikov 24 июля 2017 18:34

    P.S. Перечитал топик ещё раз :) От основной боли это решение тоже избавляет.

    Отключённый через инсталлер плагин не будет подписан на событие.

  • Николай Иванов 24 июля 2017 19:38

    Да. Основное - это чтобы руками прописанные вызовы в шаблонах отключались при отключении в инсталере.
    Тему почитаю еще раз. Ведь читал же, но прошло мимо сознания и не закрепилось.

  • Николай Иванов 24 июля 2017 20:24

    Решение хорошее. Только вот нет пока такого механизма. И что-то не увидел энтузиазма со стороны webasyts.
    Господа webasyst-овцы! Проблема назрела, давайте её хоть как-то решим централизованно/цивилизованно.

  • Eugen Nichikov 24 июля 2017 20:46

    Ну годик PR отметим, а там, может, что-то новое придумаем :)



Чтобы добавить комментарий, зарегистрируйтесь или войдите