Пространство имен композитора в разработке плагина WordPress

Я столкнулся с совершенно предсказуемой, но невероятно раздражающей и трудной для решения проблемы.

Я работаю над фреймворком PHP для разработки плагинов WordPress. Он использует Composer для управления зависимостями. Конечно, проблема в том, что у вас есть два экземпляра моей фреймворк в одной и той же установке WordPress, у вас есть две папки поставщика и две копии любых пакетов, требуемых инфраструктурой. Это приводит к ошибке.

Структура функционирует как отдельный плагин, который затем наследуется любыми приложениями/плагинами, которые на нем основаны.

Переместить папку поставщика в папку основного фрейма?

Проблемы: я не знаю, что произойдет, если у меня есть два файла composer.json и два файла composer.phar, которые записываются в одну папку поставщика и используют один и тот же автозагрузчик. Предположительно, это было бы нехорошо. Кроме того, он не решает проблему коллизий с композиционными пакетами, которые могут быть использованы любым другим script или плагином вне того, что я пытаюсь обработать.

Итак, я застрял. Является ли это проблемой, которая может быть решена, или она просто присуща PHP?

ОТВЕТЫ

Ответ 1

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

Другими словами - если вы не выполняете зависимости, то метод Composer и WordPress вообще не выполняет зависимости, это становится вашей личной проблемой, как с этим бороться.

Я не знаю, что произойдет, если у меня есть два файла composer.json и два файла composer.phar, которые записываются в одну и ту же папку поставщика и используют один и тот же автозагрузчик

Я не понимаю, почему папка поставщика будет такой же, если вы используете несколько компоновщиков установки... Не могли бы вы рассказать о том, как вы ее структурируете и предназначены ли они для публичного или частного использования?

Ответ 2

Я не очень хорошо знаком с Composer или используемой вами плагиновой структурой, но в целом - избегая конфликтов имен функций/классов в плагинах WordPress выполняется следующим образом:

  • Предполагая, что ваш плагин (например, MyCoolPlugin) написан объектно-ориентированным, например. как класс с именем MyCoolPlugin, вы можете включить вспомогательный класс/библиотеку в качестве подкласса MyCoolPlugin.

  • class_exists(), это способ поиска PHP, если класс был определен. Предположим, что ваш класс-помощник:

class MyHelperClass{ }

Вы можете использовать следующую проверку перед объявлением класса в каждом из своих плагинов:

if(!class_exists('MyHelperClass')){
   class MyHelperClass{
   }
}

Конечно, здесь есть компромисс, потому что только первый экземпляр класса будет использоваться через наш WordPress. Например. если у вас есть два плагина с двумя разными версиями вспомогательного класса - только один из них будет активным и доступным в любой момент.

  • Глобальная переменная - например, define('MY_HELPER_IS_LOADED', true); в вспомогательных файлах (в случае их включения через include() или require()). Затем в начале каждого включенного хелпер файла проверьте с помощью if(defined('MY_HELPER_IS_LOADED')) return;, что приведет к включению текущего запрошенного файла include/require для НЕ.

Опять тактика, описанная выше, используется в PHP в целом, я не уверен, как точно настроена ваша инфраструктура плагинов.