WordPress 플러그인 개발에서 Composer 네임스페이스 충돌

WordPress 플러그인 개발에서 Composer 네임스페이스 충돌

나는 완전히 예측 가능하지만 엄청나게 짜증나고 문제를 해결하기 어려운 상황에 직면해 있다.

저는 WordPress 플러그인을 개발하기 위한 PHP 프레임워크 작업을 해왔습니다.종속성 관리를 위해 Composer를 사용하고 있습니다.물론 WordPress의 동일한 설치 환경에 2개의 프레임워크 인스턴스가 있는 경우 벤더 폴더 2개와 프레임워크에 필요한 패키지 복사본 2개가 있습니다.그러면 오류가 발생합니다.

프레임워크는 별도의 플러그인으로 기능하며, 이 플러그인은 프레임워크에 내장된 모든 앱/플러그인에 의해 상속됩니다.

벤더 폴더를 코어 프레임워크 폴더로 이동하시겠습니까?

문제:composer.json 파일 2개와 composer 파일 2개가 있으면 어떻게 될지 모르겠어요.동일한 벤더 폴더에 쓰고 동일한 자동 로더를 사용하여 par 파일을 작성합니다.아마 그것은 좋지 않을 것이다.또, 제가 취급하고 있는 것 이외의 스크립트나 플러그인이 사용할 수 있는 컴포넌트 패키지와 충돌하는 문제는 해결되지 않습니다.

그래서 난 갇혔어.이것은 해결할 수 있는 문제입니까, 아니면 PHP만의 문제입니까?

Composer는 같은 프로젝트에서 여러 번 사용하는 것이 아닙니다.한편, WordPress 환경에서의 일반적인 의존관계와 마찬가지로 의존관계 기능을 상실하여 취급할 필요가 있습니다.

즉, Composer 방식으로 의존관계를 실행하지 않고 WordPress가 의존관계를 실행하지 않는 경우 어떻게 대처해야 하는지는 개인적인 문제가 됩니다.

composer.json 파일 2개와 composer 파일 2개가 있으면 어떻게 될지 모르겠어요.동일한 벤더 폴더에 쓰고 동일한 자동 로더를 사용하는 par 파일

여러 개의 컴포저 설치를 사용하는 경우 벤더 폴더가 동일한 이유를 알 수 없습니다.그것을 어떻게 구조화하는지, 그리고 그것이 공공용인지 아니면 개인용인지 자세히 설명해 주시겠습니까?

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에서 사용되고 있습니다.플러그인 프레임워크가 어떻게 설정되어 있는지 잘 모르겠습니다.

언급URL : https://stackoverflow.com/questions/18060148/composer-namespace-collisions-in-wordpress-plugin-development