Wordpress Plugin 개발 중 타사 종속성 충돌

Wordpress Plugin 개발 중 타사 종속성 충돌

작곡가를 사용한 플러그인을 개발 중입니다.즉, 플러그인 폴더 내에 Guzzle HTTP 종속성을 포함하는 벤더 폴더가 있습니다.

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

현재 다른 플러그인의 리소스에서 오류가 발생하고 있는 'my-plugin' 전에 강제로 'other-plugin'을 먼저 로드하기 위해 플러그인 로드 순서를 설치하려고 했습니다.이렇게 하면 오류가 자동 로드에서 발생하며 이를 파악할 수 있습니다.

아쉽게도..플러그인 로드 순서가 작동하지 않았습니다.

이 문제를 해결할 방법이 있나요?

워드프레스 지옥에 오신 걸 환영합니다우리는 2018년이 있고 WordPress는 여전히 종속성 관리를 하지 않고 Composer의 존재를 알아차리지 못했습니다.

WordPress 생태계는 단순히 플러그인/테마의 함수/클래스 이름이 고유해야 한다는 가정에 의존합니다.인기 있는 3부 Composer 라이브러리를 플러그인/테마와 함께 배포하면 문제가 발생합니다.다른 플러그인이 같은 작업을 하고 있으면 이름 충돌이 생기기 쉽습니다.이 상황에서 벗어날 좋은 방법은 없다.

로 하는 는, 「 」의 에 프리픽스를 .vendor프리픽스를 예: " " " )myplygin\vendor .그리고나서GuzzleHttp\Client becomes가 되다myplugin\vendors\GuzzleHttp\Client따라서 이름 충돌의 위험이 없습니다.이를 위해 스크립트를 작성하기 위해 (또는 일부 기존 솔루션을 사용할 수도 있음) 약간의 작업이 필요합니다.또한 의존관계가 중복될 수 있습니다(10개의 플러그인이 같은 라이브러리를 10회 사용할 수 있지만 네임스페이스는 다릅니다).그러나 최신 툴과 패턴을 오래된 소프트웨어에 통합하려면 비용이 많이 듭니다.

사용자가 직접 이 플러그인을 작성하고 최종 설치를 제어하는 경우, WordPress 및 해당 플러그인을 설치하는 데 Composer를 사용할 수 있습니다.서드파티제의 플러그인이 일부 컴포저 라이브러리를 번들하고 있는 경우 포킹을 통해 수정할 필요가 있을 수 있지만, 장기적으로는 많은 것을 단순화할 수 있으며 모든 플러그인에 대해 라이브러리가 중복되는 것을 피할 수 있습니다.

설계상 PHP와 Composer는 사용자가 코드를 개발 및 배포하는 것으로 가정합니다.단, WordPress에 플러그인을 게시하거나 Joomla에 모듈을 게시할 경우 다른 작성자가 설치할 내용을 제어할 수 없는 시스템에 코드를 배포합니다.이 상황으로 인해 다음과 같은 이름 충돌이 발생할 수 있습니다.Cannot redeclare GuzzleHttp\uri_template()....

멀티벤더 셋업을 위해 코드를 준비하려면 이름 충돌이나 버전 충돌을 피하기 위해 PHP 코드 앞에 프레픽스를 붙여야 합니다(다른 버전의 라이브러리가 먼저 로드됩니다).예를 들어 Guzzle은 널리 알려진 라이브러리이므로 이를 포함하는 플러그인을 게시할 경우 배포 전에 접두사를 지정해야 합니다.

언뜻 보면 네임스페이스만 앞에 붙이면 작업이 완료된다고 생각할 수 있습니다.그러나 가능한 모든 오류 유형을 피하기 위해 글로벌 함수 및 특성 등의 다른 이름 있는 요소도 접두사를 붙여야 합니다.

PHP 코드의 프리픽스를 붙이기 위해서, 작업을 실행하는 툴이나 서비스가 있습니다.

• humbug/humb-scoper.파일/디렉토리의 모든 PHP 네임스페이스 앞에 부가되어 PAR에 번들된 코드를 분리합니다.
• 인터페이스랩/네임스페이서네임스페이스를 사용하면 컴포저 패키지의 네임스페이스 이름을 변경할 수 있습니다.모든 네임스페이스에 네임스페이스 접두사를 추가하는 방식으로 작동합니다.네임스페이서도 패키지 이름 앞에 붙습니다.그런 다음 WordPress 플러그인에 안전하게 포함할 수 있는 "lib"라는 폴더를 생성합니다.
• 코엔야콥스/코엔야콥스WordPress 플러그인용 개발자 도구:모든 프로젝트 종속성을 사용자 자신의 네임스페이스로 래핑합니다.이렇게 하면 동일한 종속성을 로드하지만 버전이 다른 다른 다른 플러그인과의 충돌을 방지할 수 있습니다.
• PHP 프리픽서Composer 의존관계에 Prefix를 적용하는 복잡한 규칙 기반 시스템을 기반으로 하는 자동화된 온라인 서비스입니다.에서composer.json자세한 내용은 신경 쓰지 않고 적용할 프레픽스를 정의하기만 하면 됩니다.

면책사항:저는 PHP 프리픽서 개발 책임자입니다.

이는 권장되지 않지만 필요한 경우 사용합니다.

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");

저는 이 라이브러리를 사용하고 있습니다.이 라이브러리는 모차르트의 보다 유지관리된 버전입니다.https://github.com/BrianHenryIE/strauss

벤더 라이브러리의 네임스페이스 접두사를 설정하고 별도의 라이브러리에 추가하여 프로젝트에 자동으로 로드할 수 있습니다.

그것은 또한 많은 다른 유용한 기능들을 가지고 있다.

GuzzleHttp/functions에 기능이 있는 것 같습니다.31행의 php를 사용하여 다음과 같은 것을 사용할 수 있습니다.

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

또는 is_syslog_active 함수를 사용하여 플러그인이 이미 설치되어 있는지 확인할 수 있습니다.이 경우 파일 포함은 무시해도 됩니다.

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

언급URL : https://stackoverflow.com/questions/50144816/3rd-party-dependency-conflict-in-developing-wordpress-plugin