WordPress 후크를 사용하여 코드 정리, 활성화 및 제거
게시 됨: 2015-01-23플러그인 작성자는 제품의 주요 기능에 너무 많은 시간과 에너지를 쏟기 때문에 덜 중요한 항목은 생략할 수 있습니다.
활성화 및 비활성화를 예로 들어 보겠습니다. 활성화 후크는 널리 퍼져 있지만 많은 플러그인은 일부 옵션을 추가하고, 재작성 규칙을 플러시하고, 데이터베이스 테이블을 생성하거나, 설치 시 버전 차이를 확인해야 합니다. 비활성화 및 제거 후크는 훨씬 덜 일반적입니다.
여기서 요점은? 많은 플러그인 작성자는 스스로 정리할 시간이 없습니다. 플러그인을 제거한 후 생성한 사용자 정의 테이블이 WordPress 설치에 정말 필요합니까? 플러그인을 폐기하기 전에 플러그인에만 있는 몇 가지 옵션을 지우지 않겠습니까?
이 기사에서는 활성화, 비활성화 및 제거 후크를 사용하여 플러그인을 초기화하고 사용자가 제품 사용을 마친 후 더 쉽게 정리하는 방법을 보여줍니다.
- 활성화 후크
- 설치 순서
- 재작성 규칙 플러시
- 데이터베이스 테이블 생성
- 종속성 검사
- 비활성화 후크
- 제거 후크
- 추가 보안
- 청소할 시간입니다
참고: 이 기사를 훑어볼 계획이라면 마지막에 있는 "추가 보안" 섹션을 살펴보는 것이 좋습니다. 이 섹션은 몇 가지 귀중한 보안 검사로 코드를 보완합니다. 또한 WordPress 플러그인 후크에 대한 도움이 필요한 경우 WordPress 후크 사용 및 WordPress에서 기능을 활성화하는 방법에 대한 간략한 정보가 있습니다.
활성화 후크
활성화 후크는 매우 간단하지만 설치하는 것은 약간 특수한 경우이므로 이벤트 순서에 주의를 기울여야 합니다. 이 모든 것을 다루기 전에 간단한 예가 있습니다.
이 모든 것의 핵심은 register_activation_hook() 함수입니다. 첫 번째 매개변수는 기본 플러그인 파일의 경로입니다. 두 번째 매개변수는 실행할 함수를 정의합니다. 내부적으로 register_activation_hook() 함수는 "activate_[plugin_name]" 작업에 대한 래퍼이지만 사용하기가 조금 더 쉽기 때문에 플러그인에서 후크를 보는 것이 일반적입니다.
설치 순서
설치 순서를 이해하는 것은 익숙한 방법을 사용하는 것을 방지하기 때문에 중요합니다. register_activation_hook() 는 사용자가 활성화 링크를 클릭하고 결과적으로 활성화 알림을 보는 사이에 호출됩니다. 후크가 실행되기 직전에 리디렉션되는 중간 페이지에서 실행됩니다.
이것이 큰 문제인 이유를 알아보기 위해 예를 살펴보겠습니다.
재작성 규칙 플러시
많은 플러그인이 사용자 정의 게시물 유형을 생성합니다. 새로운 사용자 정의 게시물 유형에서 게시물을 방문할 때 사용자가 404 오류를 받지 않도록 활성화 시 재작성 규칙을 플러시하는 것은 현명한 조치입니다.
아래 코드는 논리적으로 보이지만 실패합니다.
그것은 완벽하게 괜찮아 보인다 . 사용자 정의 게시물 유형이 생성되고 활성화되면 재작성 규칙을 플러시합니다. 문제는 재작성 규칙을 플러시할 때 사용자 정의 게시물 유형이 아직 생성되지 않았다는 것입니다.
프로세스 흐름은 다음과 같습니다.
- 사용자가 플러그인을 설치합니다.
- 사용자가 활성화 링크를 클릭합니다.
- 중간 페이지는 활성화 후크만 실행하고 다른 것은 실행하지 않습니다. 이것은 재작성 규칙을 플러시합니다.
- 플러그인이 활성화되고 코드가 평소와 같이 실행됩니다. 사용자 정의 게시물 유형이 등록됩니다.
WordPress Codex에서 공식적으로 승인한 Stack Overflow에 게시된 솔루션은 우리의 작은 문제를 해결합니다. 솔루션에는 플러그인이 방금 설치되었음을 나타내는 옵션을 추가하는 것이 포함됩니다.
이 옵션이 있으면 활성화 작업을 수행한 다음 삭제합니다.
이 같은:
개인적으로 저는 이 솔루션을 별로 좋아하지 않습니다. 문제는 8행의 검사가 모든 단일 페이지 로드에서 실행된다는 것입니다. 서버에 큰 부하를 주지 않고 사용자의 웹사이트 속도를 늦추지 않으므로 걱정할 필요가 없습니다. 성능에 미미한 영향을 미치는 매우 빠른 검사입니다. 그러나 시간의 99.9%는 불필요합니다.
flush_rewrite_rules() 함수에 대한 문서의 Codex에 더 나은 솔루션이 언급되어 있습니다. 이 솔루션에서는 기능의 모듈성을 사용하여 활성화 시 사용자 지정 게시물 유형을 별도로 등록합니다.
항상 실행해야 하는 검사에 의존하는 대신 활성화 기능을 사용하여 게시물 유형을 등록합니다. 플러그인이 활성화되면 게시물 유형은 항상 init 후크에서 등록됩니다.
이것은 코덱스가 도처에 있다는 슬픈 예입니다. 일반적으로 WordPress에는 좋은 문서가 있지만 무언가가 낭비되거나 비논리적으로 보인다면 스스로 조사하는 것을 두려워하지 마십시오.
데이터베이스 테이블 생성
일부 플러그인이 수행하는 또 다른 작업은 데이터베이스 테이블을 생성하는 것입니다. 종종 이것은 불필요하지만 합법적인 사용 사례가 있습니다.
테이블 생성에 대한 Codex 기사의 이 예는 다중 활성화 호출을 사용하는 방법을 보여줍니다.
첫 번째 함수인 jal_install() 은 새 데이터베이스 테이블을 생성합니다. 두 번째 함수인 jal_install_data 는 초기 데이터를 테이블에 추가합니다. 이 코드를 모두 포함하는 하나의 함수를 추가하기 위해 register_activation_hook() 을 사용하는 대신 register_activation_hook 을 여러 번 사용할 수 있습니다.
이것은 모듈화를 위한 좋은 방법입니다. 한편으로는 초기 테스트 데이터를 추가할 필요 가 없습니다. 활성화 후크를 제거하는 것만 큼 간단하므로 기능을 그대로 유지할 수 있습니다. 반면에 이러한 기능은 분리되어 있으므로 어디에서나 자유롭게 재사용할 수 있습니다.
종속성 검사
활성화 기능의 또 다른 일반적인 작업은 종속성을 확인하는 것입니다. 플러그인은 특정 버전의 WordPress, 다른 플러그인 또는 특정 버전의 PHP에 의존할 수 있습니다.
아래 코드는 최소 WP 및 PHP 버전을 확인하고 필요한 경우 플러그인을 활성화하지 않고 사용자를 리디렉션합니다.
비활성화 후크
비활성화 후크는 사용자가 플러그인을 비활성화했지만 제거(삭제)되기 전에 실행됩니다. 비활성화 후크는 활성화 후크와 같은 방식으로 사용됩니다.
비활성화는 사용자가 플러그인만 비활성화했음을 의미하므로 제거하는 동안만큼 많은 작업을 수행하고 싶지 않습니다. 재작성 규칙을 플러시하고 싶을 수도 있지만 이 단계에서 모든 옵션과 데이터베이스 테이블(있는 경우)을 제거하고 싶지는 않을 것입니다.
이것은 매우 간단하지만 다시 한 번 문제가 있는 플러시 재작성 규칙에 특별한 주의를 기울일 것입니다.
코덱스는 아래와 같이 권장하지만 작동하지 않습니다 .
이것이 작동하지 않는 이유는 이전과 동일합니다. 비활성화를 실행하면 init 후크가 수행됩니다. 즉, 플러그인을 비활성화할 때 사용자 정의 게시물 유형도 등록합니다. 재작성 규칙은 플러시되지만 사용자 정의 게시물 유형을 고려합니다.
이 문제를 해결하기 위해 Trac 티켓이 있지만 그때까지는 이 작업을 수행하는 좋은 방법을 알려드릴 수 없습니다. 작동하는 유일한 방법은 다시 쓰기 규칙을 완전히 삭제하는 것입니다.
이것이 과거에는 효과가 있었지만 권장하지 않습니다. 몇 가지 추가 재작성 규칙이 있는 문제보다 더 큰 불확실성이 발생합니다. 비활성화 후 영구 링크 설정을 방문하도록 요청하는 메모를 사용자에게 표시하고 싶습니다. 그러면 재작성 규칙이 플러시됩니다. 더 나은 솔루션이 구현될 때까지 이 문제에 봉착했습니다... 죄송합니다!
제거 후크
플러그인을 제거할 때 코드를 실행하는 두 가지 방법이 있습니다. register_uninstall_hook() 을 통해 제거 후크를 사용하거나 플러그인 내에서 전용 uninstall.php 파일을 사용할 수 있습니다. 둘 다 보여주겠지만 선호하는 방법은 제거 파일을 사용하는 것입니다.
제거 후크의 주요 문제는 "제거하는 동안 기본 플러그인 파일이 실행되지 않도록 하며, 이는 플러그인이 전역 공간에서 코드를 실행하는 경우 문제가 될 수 있습니다. 또한 제거 코드가 중앙 집중식이라는 점에서 더 좋습니다.” – 스콧 라일리
아래 코드는 기본 후크를 사용한 제거 프로세스를 보여줍니다.
논의된 바와 같이 이것은 최상의 솔루션이 아닙니다. 제거를 처리하는 훨씬 더 나은 방법은 uninstall.php 파일을 사용하는 것입니다. 생성하기만 하면 사용 가능한 경우 사용됩니다.
보시다시피 이것은 실제로 더 간단한 솔루션입니다. 무엇보다 독립형입니다.
추가 보안
보안 관련 문제로 지금까지 표시된 예제를 지나치게 복잡하게 만들고 싶지는 않았지만 그렇게 하도록 허용된 사람만 이러한 작업을 실행할 수 있도록 몇 가지 조치를 취해야 합니다.
활성화 및 비활성화에 다음 스니펫을 사용합니다.
이 코드 블록은 사용자에게 이 작업을 수행할 수 있는 권한이 있고 작업이 적절한 페이지에서 시작되었는지 확인합니다. 이것은 대부분의 악의적인 시도로부터 보호해야 합니다.
제거 프로세스는 특별하므로 약간 다른 코드를 사용해야 합니다.
청소할 시간입니다
플러그인이 WordPress에 항목을 추가하는 경우 사용자가 플러그인을 삭제하기로 결정할 때 이를 제거하는 것은 개발자의 의무입니다.
위에서 설명한 활성화, 비활성화 및 제거 방법을 사용하면 이를 안전하고 안전하게 수행하는 시스템을 구축할 수 있습니다. 또한 OOP 환경에서 이러한 프로세스를 간략하게 설명하는 이 Stackexchange 스레드를 읽는 것이 좋습니다.
아직 WPMU DEV 회원이 아니라면 지금 무료 평가판에 가입하세요. 회원이 되면 모든 WordPress 관련 질문 및 문제에 대한 전문가의 연중무휴 지원과 함께 모든 훌륭한 플러그인과 초고속 호스팅 서비스에 액세스할 수 있습니다.
태그: