Cách cấu trúc một plugin

Đây không phải là câu hỏi về cách xây dựng plugin WordPress. Thay vào đó, những gì, nếu có, hướng dẫn có thể được áp dụng cho cách kết hợp kiến ​​trúc tệp của bất kỳ plugin nào.

Một số ngôn ngữ lập trình hoặc thư viện khác có các cách tổ chức thư mục và tệp rất được kiểm soát. Đôi khi điều này gây khó chịu và làm nổi bật sự tự do mà PHP mang lại, nhưng trên các plugin WordPress mặt trái được đặt cùng nhau theo bất kỳ cách nào được xác định bởi tác giả của chúng.

Không có câu trả lời đúng , nhưng hy vọng của tôi là tinh chỉnh cách tôi và những người khác xây dựng các plugin để làm cho chúng thân thiện hơn với các nhà phát triển khác để xử lý, dễ gỡ lỗi hơn, dễ điều hướng hơn và có thể hiệu quả hơn.

Câu hỏi cuối cùng: những gì bạn nghĩ là cách tốt nhất để tổ chức một plugin?

Dưới đây là một vài cấu trúc mẫu, nhưng không có cách nào là một danh sách đầy đủ. Hãy thêm các khuyến nghị của riêng bạn.

Cấu trúc mặc định giả định

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

Phương pháp Model View Controller (MVC)

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

Ba phần của MVC:

• Các mô hình tương tác với cơ sở dữ liệu, truy vấn và lưu dữ liệu, và chứa logic.
• Bộ điều khiển sẽ chứa các thẻ mẫu và các chức năng mà chế độ xem sẽ sử dụng.
• Khung nhìn có trách nhiệm hiển thị dữ liệu được cung cấp bởi mô hình như được xây dựng bởi bộ điều khiển.

Tổ chức theo phương pháp loại

• /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

Plugin nồi hơi WordPress

Có sẵn trên Github

Dựa trên API Plugin , Tiêu chuẩn mã hóa và Tiêu chuẩn tài liệu .

• /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

Phương pháp tổ chức lỏng lẻo

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

Lưu ý rằng các plugin là tất cả "bộ điều khiển" theo tiêu chuẩn WP.

Nó phụ thuộc vào những gì plugin phải làm, nhưng trong mọi trường hợp tôi sẽ cố tách sản lượng màn hình ra khỏi mã PHP càng nhiều càng tốt.

Đây là một cách để làm điều đó một cách dễ dàng - trước tiên, hãy xác định một hàm tải mẫu:

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;
}

Bây giờ, nếu plugin sử dụng một widget để hiển thị dữ liệu:

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;
  }
  ...

}

Bản mẫu:

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

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

<?php endwhile; ?>

Các tập tin:

/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

Nơi nào bạn đặt CSS, JS, hình ảnh hoặc cách bạn thiết kế vùng chứa cho các hook là ít quan trọng. Tôi đoán đó là vấn đề sở thích cá nhân.

Nó phụ thuộc vào plugin. Đây là cấu trúc cơ bản của tôi cho gần như mọi plugin:

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

Đây sẽ là một cái gì đó sẽ đi trong libthư mục.

Nếu đó là plugin đặc biệt phức tạp, với nhiều chức năng của khu vực quản trị, tôi sẽ thêm một adminthư mục để chứa tất cả các tệp PHP đó. Nếu plugin làm một cái gì đó như thay thế các tệp chủ đề , có thể có một templatehoặc themethư mục.

Vì vậy, một cấu trúc thư mục có thể trông như thế này:

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

IMHO, con đường dễ nhất, mạnh nhất và dễ bảo trì nhất là sử dụng cấu trúc MVC và WP MVC được thiết kế để viết các plugin MVC rất dễ dàng (mặc dù tôi hơi thiên vị ...). Với WP MVC, bạn chỉ cần tạo các mô hình, khung nhìn và bộ điều khiển và mọi thứ khác được xử lý phía sau hậu trường cho bạn.

Các bộ điều khiển và chế độ xem riêng biệt có thể được tạo cho các phần công khai và quản trị viên và toàn bộ khung công tác tận dụng nhiều tính năng gốc của WordPress. Cấu trúc tệp và phần lớn chức năng hoàn toàn giống như trong các khung MVC phổ biến nhất (Rails, CakePHP, v.v.).

Thông tin thêm và hướng dẫn có thể được tìm thấy ở đây:

• Trang plugin
• Hướng dẫn

Chúng tôi đang sử dụng kết hợp tất cả các phương pháp. Trước hết, chúng tôi đang sử dụng Zend Framework 1.11 trong các plugin của mình và do đó chúng tôi phải sử dụng cấu trúc tương tự cho các tệp lớp vì cơ chế tự động tải.

Cấu trúc của plugin cốt lõi của chúng tôi (được sử dụng bởi tất cả các plugin của chúng tôi làm cơ sở) trông tương tự như sau:

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 gọi webeo-core.phptệp trong thư mục gốc của plugin.
2. Trong tệp này, chúng tôi sẽ thiết lập đường dẫn bao gồm PHP và đăng ký các móc kích hoạt và hủy kích hoạt cho plugin.
3. Chúng tôi cũng có một Webeo_CoreLoaderlớp bên trong tệp này, thiết lập một số hằng số plugin, khởi tạo trình tải tự động lớp và thực hiện cuộc gọi đến phương thức thiết lập của Core.phplớp trong lib/Webeothư mục. Điều này chạy trên plugins_loadedhook hành động với một ưu tiên 9.
4. Các Core.phplớp học là tập tin bootstrap Plugin của chúng tôi. Tên được dựa trên tên plugin.

Như bạn có thể thấy, chúng tôi có một thư mục con bên trong libthư mục cho tất cả các gói nhà cung cấp của chúng tôi ( Webeo, Zend). Tất cả các gói phụ bên trong một nhà cung cấp được cấu trúc bởi chính mô-đun. Đối với một Mail Settingshình thức quản trị mới , chúng tôi sẽ có cấu trúc như sau:

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

Các plugin phụ của chúng tôi có cùng cấu trúc với một ngoại lệ. Chúng tôi đi sâu hơn vào bên trong thư mục nhà cung cấp do giải quyết xung đột đặt tên trong sự kiện tự động tải. Chúng tôi cũng gọi lớp boostrap của plugin là E.g. Faq.phpưu tiên 10bên trong plugins_loadedhook.

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

Tôi có thể sẽ đổi tên libthư mục thành vendorsvà di chuyển tất cả các thư mục công cộng (css, hình ảnh, js, ngôn ngữ) sang một thư mục có tên publictrong bản phát hành tiếp theo.

Giống như nhiều người ở đây đã trả lời Nó thực sự phụ thuộc vào những gì plugin phải làm, nhưng đây là cấu trúc cơ sở của tôi:

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

Tôi là một phần trong bố cục plugin sau, tuy nhiên nó thường thay đổi tùy thuộc vào yêu cầu của plugin là gì.

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 

Tôi vẫn chưa tạo một plugin WordPress yêu cầu kiến ​​trúc kiểu MVC nhưng nếu tôi làm điều này, tôi sẽ đặt nó với một thư mục MVC riêng, chứa chính khung nhìn / bộ điều khiển / mô hình.

Logic của tôi, plugin càng lớn, cấu trúc tôi sử dụng càng nhiều.
Đối với các plugin lớn, tôi có xu hướng sử dụng MVC.
Tôi sử dụng điều này như một điểm khởi đầu và bỏ qua những gì không cần thiết.

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

Tất cả các plugin của tôi đều theo cấu trúc này, dường như rất giống với những gì hầu hết các nhà phát triển khác đang làm:

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 sau đó thường là một lớp tải tất cả các tệp cần thiết từ lõi / thư mục. Thường xuyên nhất trên hook init hoặc plugins_loaded.

Tôi cũng đã từng sử dụng tiền tố cho tất cả các tệp của mình, nhưng như @kaiser đã lưu ý ở trên, nó thực sự dư thừa và gần đây tôi đã quyết định xóa nó khỏi bất kỳ plugin nào trong tương lai.

Thư viện / thư mục chứa tất cả các thư viện trợ giúp bên ngoài mà plugin có thể phụ thuộc.

Tùy thuộc vào plugin, có thể có một tệp Uninstall.php trong thư mục gốc của plugin. Mặc dù vậy, hầu hết thời gian điều này được xử lý thông qua register_uninstall_hook ().

Rõ ràng, một số plugin có thể không yêu cầu bất kỳ tệp quản trị hoặc mẫu nào, v.v., nhưng cấu trúc ở trên hoạt động với tôi. Cuối cùng, bạn chỉ cần tìm một cấu trúc phù hợp với bạn và sau đó gắn bó với nó.

Tôi cũng có một plugin khởi động, dựa trên cấu trúc ở trên mà tôi sử dụng làm điểm khởi đầu cho tất cả các plugin của mình. Tất cả những gì tôi cần làm sau đó là thực hiện tìm kiếm / thay thế cho tiền tố hàm / lớp và tắt đi. Khi tôi vẫn còn tiền tố các tập tin của mình đó là một bước bổ sung tôi phải làm (và khá khó chịu ở đó), nhưng bây giờ tôi chỉ phải đổi tên thư mục plugin và tệp plugin chính.

Ngoài ra, xem bản tóm tắt widget WP tuyệt vời này . Nó đưa ra gợi ý tuyệt vời về cấu trúc (ngay cả khi không có lớp cũng như thư mục cho các mô hình riêng biệt).

Một cách tiếp cận ít phổ biến hơn để cấu trúc các tệp và thư mục của plugin là cách tiếp cận loại tệp. Điều đáng nói ở đây là hoàn chỉnh:

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

Mỗi thư mục chỉ chứa các tệp. Điều đáng chú ý là cách tiếp cận này bị thiếu khi bạn có nhiều loại tệp .png .gif .jpgcó thể được gửi một cách hợp lý hơn trong một thư images/mục chẳng hạn.