Прошло более девяти лет с тех пор, как покойный Алекс Миллс открыл заявку на WordPress Trac под названием Plugin Dependencies (Yet Another Plugin Dependencies Ticket) . Это не самый старый из подобных запросов функций, но он все еще открыт. Большинство предшественников были закрыты ярлыком «wontfix», который обычно является последним гвоздем как хороших, так и плохих идей.
Цель билета — создать систему, которая позволяет одному плагину требовать работы одного или нескольких других. Зависимости не являются чем-то новым в мире программирования. Композитору, стандартному менеджеру пакетов PHP, исполнилось две недели до 10-летнего возраста. Что касается JavaScript, то npm существует уже 12 лет, и WordPress активно использует его для основного кода.
Однако это инструменты разработчика. WordPress был создан для пользователей, и разрешение зависимостей плагинов должно происходить из пользовательского интерфейса.
Миллс написал в билете:
Прошло несколько лет с тех пор, как мы рассмотрели зависимости плагинов, и это по-прежнему кажется людям очень, очень нужным, особенно для общих функций, которые сами по себе не являются плагинами. Например, библиотека PHP, которая недостаточно популярна, чтобы быть в ядре, но достаточно популярна, чтобы ее можно было объединить в несколько плагинов.
Сегодня это утверждение, пожалуй, еще более актуально. За последнее десятилетие многие плагины создали свои собственные экосистемы дополнительных плагинов. Ответственность за установку зависимостей часто ложится на плечи конечных пользователей. Разработчики придумали собственные решения, чтобы облегчить это бремя, и сценарий активации плагина TGM стал стандартом де-факто .
Опора на зависимости является почти данностью в любом проекте плагинов, по крайней мере, она играет роль в настройке инструментов средней сборки. Вероятно, можно с уверенностью сказать, что больше разработчиков плагинов WordPress сегодня комфортно кодируют в среде, требующей стороннего кода, чем в годы становления WordPress.
Для платформы, которая усердно работала над своей модернизацией, разрешение зависимостей плагинов похоже на путешествие на ракете на Дикий Запад.
Эта идея не беспрецедентна в мире WordPress. Хотя это менее сложный случай, WordPress автоматически загружает и устанавливает родительскую тему при установке дочерней темы из каталога.
Многие аргументы в пользу системы зависимостей плагинов подпадают под сценарий дополнений. Наиболее очевидный вариант использования — WooCommerce и десятки написанных для него расширений.
Однако другой сценарий, который может углубить понимание того, как разработчики строят поверх WordPress, — это включение фреймворков и библиотек. Прямо сейчас авторы плагинов должны включать сторонний код в свои проекты и следить за тем, чтобы он не загружался, если он уже включен в совершенно отдельный плагин.
Повторное использование кода — один из краеугольных камней программирования. В настоящее время не существует стандарта для объединения библиотек кода или сценариев. И каталог плагинов WordPress запрещает новые фреймворки и подобные библиотеки.
Для прозрачности у меня есть как минимум дюжина проектов, подходящих под эту категорию, пакеты, которые могут использовать другие. Итак, у меня, по крайней мере, есть шкура в игре, и я уверен, что многие другие находятся в той же лодке.
В репозитории WordPress GitHub есть два запроса на включение системы зависимостей плагинов. Существует также файл Google Docs, в котором подробно описаны оба предложения .
Каждый просит разработчиков определить зависимости через заголовок плагина. Ниже приведен пример, для которого потребуются WooCommerce и Gutenberg:
<?php /** * Plugin Name: Sample * Requires Plugins: woocommerce, gutenberg */
Оба подхода схожи. С точки зрения пользователя они:
- Покажите администратору уведомление о наличии зависимостей для установки.
- Запретить удаление или деактивацию плагинов без удаления или деактивации необходимых для них плагинов.
- Вывести сообщение в карточке плагина на экране управления плагинами.
Первая реализация принадлежит Ари Статопулосу. Он создает «очередь активации», которая будет активировать плагин только после того, как пользователи активируют необходимые плагины. Это также позволяет пользователям отменять запросы на активацию.
Решение Энди Фрагена создает новую вкладку «Зависимости» на экране управления плагинами. Этот подход автоматически деактивирует любой плагин с неудовлетворенными зависимостями и информирует пользователя через уведомление администратора.
Он также отдельно выпустил проект « Вкладка зависимостей плагинов » на GitHub.
Есть еще некоторые практические проблемы с обоими. А именно, что происходит, когда возникает конфликт между поддерживаемыми версиями? Текущие предложения оставляют на усмотрение плагинов ничего не ломать на стороне пользователя.
Это может быть наименее внушающей доверие частью всего этого. Тем не менее, это, вероятно, самый практичный маршрут. Кроме того, WordPress не решает конфликты версий в своей текущей системе Wild West.
Решение зависимости также может быть возможностью для дополнительной модернизации кода. Хотелось бы, чтобы больше разработчиков использовали такие функции, как интерфейсы (контракты). Кодирование с учетом иждивенцев означает продумывание архитектурных проблем по-другому, чем когда любой конкретный проект был автономным плагином.
