Конфликт сторонней зависимости при разработке плагина Wordpress - PullRequest
Новая
       9

Конфликт сторонней зависимости при разработке плагина Wordpress

0 голосов
/ 03 мая 2018

Я разрабатываю плагин, который использует composer .. это означает, что в папке плагина есть папка vendor, которая включает в себя зависимость HTTP от Guzzle

На WordPress сайте мы установили этот плагин, есть существующий плагин, который имеет Guzzle HTTP

Теперь, когда мы активируем этот плагин, я получаю сообщение об ошибке, похожее на это: 

Fatal error: Cannot redeclare GuzzleHttp\uri_template() (previously declared in /nas/content/staging/project/wp-content/plugins/my-plugin/vendor/guzzlehttp/guzzle/src/functions.php:17) in /nas/content/staging/project/wp-content/plugins/other-plugin/includes/lib/aws-sdk/GuzzleHttp/functions.php on line 31

Я попытался установить Порядок загрузки плагинов, чтобы сначала загрузить «other-plugin» перед «my-plugin» в настоящее время ошибка происходит на ресурсах другого плагина. таким образом, ошибка приведет к нашей автозагрузке, и мы можем это отловить.

к сожалению .. Порядок загрузки плагинов не работает ..

есть идеи, как это решить?

Ответы [ 3 ]

0 голосов
/ 04 мая 2018

Это не рекомендуется, но используйте его, если необходимо 

function this_plugin_last() {
    $wp_path_to_this_file = preg_replace('/(.*)plugins\/(.*)$/', WP_PLUGIN_DIR."/$2", __FILE__);
    $this_plugin = plugin_basename(trim($wp_path_to_this_file));
    $active_plugins = get_option('active_plugins');
    $this_plugin_key = array_search($this_plugin, $active_plugins);
        array_splice($active_plugins, $this_plugin_key, 1);
        array_push($active_plugins, $this_plugin);
        update_option('active_plugins', $active_plugins);
}
add_action("activated_plugin", "this_plugin_last");
0 голосов
/ 05 мая 2018

Добро пожаловать в ад WordPress. У нас есть 2018 год, и WordPress до сих пор не имеет никакого управления зависимостями и все еще не заметил существования Composer.

Экосистема WordPress просто полагается на то, что имена функций / классов плагинов / тем должны быть уникальными. Очевидно, что распространение популярных библиотек Composer из 3-х частей с вашим плагином / темой вызывает проблемы - легко получить конфликт имен, когда другой плагин делает то же самое. Нет хорошего выхода из этой ситуации.

Если вы хотите пуленепробиваемое решение для автономных плагинов, вы должны использовать префикс пространства имен каждого пакета в каталоге vendor с префиксом плагина, например, myplygin\vendor. Тогда GuzzleHttp\Client становится myplugin\vendors\GuzzleHttp\Client, поэтому нет риска конфликта имен. Это потребует некоторой работы для написания сценария для этого (или вы можете использовать некоторые существующие решения, такие как humbug/php-scoper), и вы можете получить много дублированных зависимостей (10 плагинов могут приносить одну и ту же библиотеку 10 раз, но с разными пространствами имен), но это стоимость интеграции современных инструментов и шаблонов в устаревшее программное обеспечение.

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

0 голосов
/ 03 мая 2018

Я предполагаю, что есть функция в GuzzleHttp / functions.php в строке 31, чтобы вы могли использовать что-то вроде этого: 

  if (function_exists('Do_Something')){
       echo "Function Exists"; 
    }else{
       echo "Function Not Found, This name Can be used!";
    }

или вы можете использовать функцию is_plugin_active, чтобы проверить, установлен ли плагин. В этом случае вы можете игнорировать, включая файлы

https://codex.wordpress.org/Function_Reference/is_plugin_active

...