플러그인을 구성하는 방법

WordPress 플러그인을 빌드하는 방법에 대한 질문은 아닙니다. 오히려 어떤 플러그인의 파일 아키텍처를 구성하는 방법에 가이드가 적용될 수 있습니까?

다른 프로그래밍 언어 나 라이브러리는 디렉토리와 파일을 구성하는 매우 통제 된 방법을 가지고 있습니다. 때때로 이것은 성 가시고 PHP가 제공하는 자유를 강조하지만, 플립 워드 프레스 플러그인은 저자가 결정한대로 어떤 방식 으로든 결합됩니다.

정답 은 없지만, 저와 다른 사람들이 다른 개발자가 더 친숙하고 쉽게 디버깅하고, 탐색하고, 탐색하고,보다 효율적으로 사용할 수 있도록 플러그인을 빌드하는 방법을 개선하고자합니다.

마지막 질문 : 무엇을 당신이 플러그인을 구성하는 가장 좋은 방법이라고 생각?

다음은 몇 가지 샘플 구조이지만 전체 목록은 아닙니다. 자신의 추천을 자유롭게 추가하십시오.

가정 된 기본 구조

• /wp-content
  • /plugins
    • /my-plugin
      • my-plugin.php

MVC (Model View Controller) 방법

• /wp-content
  • /plugins
    • /my-plugin
      • /controller
        • Controller.php
      • /model
        • Model.php
      • /view
        • view.php
      • my-plugin.php

MVC의 세 부분 :

• 이 모델 은 데이터베이스와 상호 작용하여 데이터를 쿼리하고 저장하며 논리를 포함합니다.
• 컨트롤러는 뷰가 활용할 것이라고 템플릿 태그와 함수를 포함한다.
• 보기 제어기에 의해 구성 될 때의 모델에 의해 제공되는 데이터를 표시하는 책임이있다.

유형 방법으로 구성

• /wp-content
  • /plugins
    • /my-plugin
      • /admin
        • admin.php
      • /assets
        • css/
        • images/
      • /classes
        • my-class.php
      • /lang
        • my-es_ES.mo
      • /templates
        • my-template.php
      • /widgets
        • my-widget.php
      • my-plugin.php

워드 프레스 플러그인 보일러 플레이트

Github에서 사용 가능

플러그인 API , 코딩 표준 및 문서 표준을 기반으로합니다 .

• /wp-content
  • /plugins
    • /my-plugin
      • /admin
        • /css
        • /js
        • /partials
        • my-plugin-admin.php
      • /includes
        • my_plugin_activator.php
        • my_plugin_deactivator.php
        • my_plugin_i18n.php
        • my_plugin_loader.php
        • my_plugin.php
      • /languages
        • my_plugin.pot
      • /public
        • /css
        • /js
        • /partials
        • my-plugin-public.php
      • LICENSE.txt
      • README.txt
      • index.php
      • my-plugin.php
      • uninstall.php

느슨하게 구성된 방법

• /wp-content
  • /plugins
    • /my-plugin
      • css/
      • images/
      • js/
      • my-admin.php
      • my-class.php
      • my-template.php
      • my-widget.php
      • my-plugin.php

플러그인은 모두 WP 표준에 따른 "컨트롤러"입니다.

플러그인의 기능에 따라 다르지만 모든 경우에 가능한 한 화면을 PHP 코드와 분리하려고 시도합니다.

이를 쉽게 수행하는 한 가지 방법이 있습니다. 먼저 템플릿을로드하는 함수를 정의하십시오.

function my_plugin_load_template(array $_vars){

  // you cannot let locate_template to load your template
  // because WP devs made sure you can't pass
  // variables to your template :(
  $_template = locate_template('my_plugin', false, false);

  // use the default one if the theme doesn't have it
  if(!_$template)
    $_template = 'views/template.php';

  // load it
  extract($_vars);        
  require $template;
}

이제 플러그인이 위젯을 사용하여 데이터를 표시하는 경우 :

class Your_Widget extends WP_Widget{

  ...      
  public function widget($args, $instance){

    $title = apply_filters('widget_title', $instance['title'], $instance, $this->id_base);

    // this widget shows the last 5 "movies"
    $posts = new WP_Query(array('posts_per_page' => 5, 'post_type' => 'movie')); 

    if($title)
      print $before_title . $title . $after_title;

    // here we rely on the template to display the data on the screen
    my_plugin_load_template(array(

      // variables you wish to expose in the template
     'posts'    => $posts,          
    ));

    print $before_widget;
  }
  ...

}

템플릿 :

<?php while($posts->have_posts()): $posts->the_post(); ?>

<p><?php the_title(); ?></p> 

<?php endwhile; ?>

파일 :

/plugins/my_plugin/plugin.php           <-- just hooks 
/plugins/my_plugin/widget.php           <-- widget class, if you have a widget
/themes/twentyten/my_plugin.php         <-- template
/plugins/my_plugin/views/template.php   <-- fallback template

CSS, JS, 이미지를 어디에 두거나 후크를위한 컨테이너를 어떻게 디자인 하는가는 덜 중요합니다. 내가 생각하는 것은 개인적인 취향의 문제입니다.

플러그인에 따라 다릅니다. 이것은 거의 모든 플러그인의 기본 구조입니다.

my-plugin/
    inc/
        Any additional plugin-specific PHP files go here
    lib/
        Library classes, css, js, and other files that I use with many
        plugins go here
    css/
    js/
    images/
    lang/
        Translation files
    my-plugin.php
    readme.txt

이것은lib 폴더에 들어갈 것입니다 .

관리 영역 기능이 많은 플러그인이 특히 복잡한 경우 admin해당 PHP 파일을 모두 포함 하는 폴더를 추가 합니다. 플러그인이 포함 된 테마 파일 바꾸기와 같은 작업을 수행 하는 경우 template또는 theme폴더도있을 수 있습니다.

따라서 디렉토리 구조는 다음과 같습니다.

my-plugin/
    inc/
    lib/
    admin/
    templates/
    css/
    js/
    images/
    lang/
    my-plugin.php
    readme.txt

가장 쉽고 강력하며 유지 관리가 쉬운 경로 인 IMHO는 MVC 구조를 사용하는 것이며 WP MVC는 MVC 플러그인을 매우 쉽게 작성할 수 있도록 설계되었습니다. WP MVC를 사용하면 간단히 모델, 뷰 및 컨트롤러를 만들 수 있으며 그 밖의 모든 항목은 자동으로 처리됩니다.

공용 및 관리자 섹션에 대해 별도의 컨트롤러 및보기를 만들 수 있으며 전체 프레임 워크는 많은 WordPress의 기본 기능을 활용합니다. 파일 구조와 기능의 대부분은 가장 널리 사용되는 MVC 프레임 워크 (Rails, CakePHP 등)와 동일합니다.

더 많은 정보와 튜토리얼은 여기에서 찾을 수 있습니다 :

• 플러그인 페이지
• 지도 시간

우리는 모든 방법을 혼합하여 사용하고 있습니다. 우선 플러그인에서 Zend Framework 1.11을 사용하고 있으므로 자동로드 방식으로 인해 클래스 파일에 유사한 구조를 사용해야했습니다.

핵심 플러그인의 구조 (모든 플러그인에서 기본으로 사용)는 다음과 유사합니다.

webeo-core/
    css/
    images/
    js/
    languages/
    lib/
        Webeo/
            Core.php
        Zend/
            /** ZF files **/
        Loader.php
    views/
    readme.txt
    uninstall.php
    webeo-core.php

1. WordPress webeo-core.php는 플러그인 루트 폴더에서 파일을 호출 합니다.
2. 이 파일에서는 PHP include 경로를 설정하고 플러그인의 활성화 및 비활성화 훅을 등록합니다.
3. 또한 Webeo_CoreLoader이 파일 안에 클래스가 있는데, 여기에는 플러그인 상수를 설정하고, 클래스 오토로더를 초기화하고 Core.php, lib/Webeo폴더 안에있는 클래스 의 설정 메소드를 호출 합니다. plugins_loaded우선 순위가이고 동작 후크 에서 실행됩니다 9.
4. 이 Core.php클래스는 플러그인 부트 스트랩 파일입니다. 이름은 플러그인 이름을 기반으로합니다.

보시다시피 lib모든 공급 업체 패키지 ( Webeo, Zend) 의 하위 디렉토리가 폴더 안에 있습니다. 공급 업체 내의 모든 하위 패키지는 모듈 자체에 의해 구조화됩니다. 새 Mail Settings관리 양식의 경우 다음 구조를 갖습니다.

webeo-core/
    ...
    lib/
        Webeo/
            Form/
                Admin/
                    MailSettings.php
                Admin.php
            Core.php
            Form.php

우리의 하위 플러그인은 하나의 예외를 제외하고는 동일한 구조를 가지고 있습니다. 자동로드 이벤트 중 이름 충돌을 해결하기 위해 공급 업체 폴더 내부로 더 깊이 이동합니다. 또한 후크 내부의 E.g. Faq.php우선 순위에 따라 플러그인 boostrap 클래스 를 호출합니다 .10plugins_loaded

webeo-faq/ (uses/extends webeo-core)
    css/
    images/
    js/
    languages/
    lib/
        Webeo/
            Faq/
                Faq.php
                /** all plugin relevant class files **/
    views/
    readme.txt
    uninstall.php
    webeo-faq.php

lib폴더의 이름을 바꾸고 vendors모든 공용 폴더 (css, 이미지, js, 언어)를 public다음 릴리스에서 이름이 지정된 폴더로 옮길 것입니다 .

이미 많은 사람들이 이미 대답했듯이 그것은 플러그인이 무엇을 해야하는지에 달려 있지만 여기 내 기본 구조는 다음과 같습니다.

my-plugin/
    admin/
        holds all back-end administrative files
        js/
            holds all back-end JavaScript files
        css/                    
            holds all back-end CSS files
        images/
            holds all back-end images
        admin_file_1.php        back-end functionality file
        admin_file_2.php        another back-end functionality file 
    js/
        holds all front end JavaScript files
    css/
        holds all fronted CSS files
    inc/
        holds all helper classes
    lang/                   
        holds all translation files
    images/
        holds all fronted images
    my-plugin.php               main plugin file with plugin meta, mostly includes,action and filter hooks
    readme.txt                  
    changelog.txt
    license.txt

나는 다음 플러그인 레이아웃의 일부이지만 일반적으로 플러그인 요구 사항에 따라 변경됩니다.

wp-content/
    plugins/
        my-plugin/
            inc/
                Specific files for only this plugin
                admin/ 
                    Files for dealing with administrative tasks
            lib/
                Library/helper classes go here
            css/
                CSS files for the plugin
            js/
                JS files
            images/
                Images for my plugin
            lang/
                Translation files
        plugin.php 
            This is the main file that calls/includes other files 
        README 
            I normally put the license details in here in addition to helpful information 

아직 MVC 스타일 아키텍처가 필요한 WordPress 플러그인을 만들지 않았지만이 작업을 수행하려면 자체 뷰 / 컨트롤러 / 모델을 포함하는 별도의 MVC 디렉토리를 사용하여 배치해야합니다.

내 논리, 플러그인이 클수록 더 많은 구조를 사용합니다.
큰 플러그인의 경우 MVC를 사용하는 경향이 있습니다.
나는 이것을 출발점으로 사용하고 필요없는 것을 건너 뜁니다.

controller/
    frontend.php
    wp-admin.php
    widget1.php
    widget2.php
model/
    standard-wp-tables.php // if needed split it up
    custom-tabel1.php
    custom-tabel2.php
view/
    helper.php
    frontend/
        files...php
    wp-admin/
        files...php
    widget1/
        file...php
    widget2/
        file...php
css/
js/
image/
library/  //php only, mostly for Zend Framework, again if needed
constants.php //tend to use it often
plugin.php //init file
install-unistall.php  //only on big plugins

모든 플러그인은이 구조를 따르며, 이는 대부분의 다른 개발자가하는 것과 매우 유사합니다

plugin-folder/
    admin/
        css/
            images/
        js/
    core/
    css/
        images/
    js/
    languages/
    library/
    templates/
    plugin-folder.php
    readme.txt
    changelog.txt
    license.txt

plugin-folder.php는 보통 core / 폴더에서 필요한 모든 파일을로드하는 클래스입니다. 대부분 init 또는 plugins_loaded 훅에서.

필자는 모든 파일의 접두사를 사용했지만 @kaiser가 위에서 언급했듯이 실제로는 중복되어 최근 플러그인에서 제거하기로 결정했습니다.

library / 폴더에는 플러그인이 의존 할 수있는 모든 외부 헬퍼 라이브러리가 있습니다.

플러그인에 따라 플러그인 루트에 uninstall.php 파일도있을 수 있습니다. 그러나 대부분의 경우 register_uninstall_hook ()을 통해 처리됩니다.

분명히 일부 플러그인에는 관리자 파일이나 템플릿 등이 필요하지 않을 수 있지만 위의 구조는 저에게 효과적입니다. 결국 당신은 당신에게 맞는 구조를 찾아서 고수해야합니다.

또한 위의 구조에 따라 모든 플러그인의 시작점으로 사용하는 스타터 플러그인이 있습니다. 그런 다음 함수 / 클래스 접두사를 검색 / 바꾸기 만하면됩니다. 추가 단계 인 파일에 접두사를 추가 할 때 (그리고 그에 대해 성가신) 플러그인 폴더와 기본 플러그인 파일의 이름을 바꾸면됩니다.

또한 이 위대한 WP 위젯 상용구를 참조하십시오 . 별도의 모델을위한 클래스 나 폴더가없는 경우에도 구조에 대한 힌트를 제공합니다.

플러그인의 파일과 디렉토리를 구성하는 덜 일반적인 접근법은 파일 유형 접근법입니다. 완전성을 위해 여기에서 언급 할 가치가 있습니다.

plugin-name/
    js/
        sparkle.js
        shake.js
    css/
        style.css
    scss/
        header.scss
        footer.scss
    php/
        class.php
        functions.php
    plugin-name.php
    uninstall.php
    readme.txt

각 디렉토리에는 해당 유형의 파일 만 포함됩니다. 예를 들어 .png .gif .jpg단일 디렉토리에 논리적으로 더 많은 파일 형식 이있을 경우이 방법이 부족하다는 점은 주목할 가치 가 있습니다 images/.