Cara menyusun plugin

Ini bukan pertanyaan tentang bagaimana membangun plugin WordPress. Alih-alih, apa, jika ada, panduan dapat diterapkan pada cara menyusun arsitektur file plugin apa pun.

Beberapa bahasa atau pustaka pemrograman lain memiliki cara yang sangat terkontrol dalam mengatur direktori dan file. Terkadang hal ini menjengkelkan dan menyoroti kebebasan yang ditawarkan PHP, tetapi di sisi lain plugin WordPress disatukan dengan cara apa pun yang ditentukan oleh penulisnya.

Tidak ada jawaban yang benar , tetapi harapan saya adalah untuk memperbaiki bagaimana saya, dan orang lain, membangun plugin untuk membuatnya lebih ramah bagi pengembang lain untuk diseksi, lebih mudah untuk debug, lebih mudah dinavigasi, dan mungkin lebih efisien.

Pertanyaan terakhir: menurut Anda apa cara terbaik untuk mengatur plugin?

Berikut adalah beberapa struktur sampel, tetapi daftar lengkapnya sama sekali tidak lengkap. Jangan ragu untuk menambahkan rekomendasi Anda sendiri.

Diasumsikan Struktur Default

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

Metode Model View Controller (MVC)

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

Tiga bagian MVC:

• The Model berinteraksi dengan database, query dan menyimpan data, dan berisi logika.
• The kontroler akan berisi tag template dan fungsi bahwa pandangan akan memanfaatkan.
• The pandangan bertanggung jawab untuk menampilkan data yang diberikan oleh model yang dibangun oleh controller.

Diatur berdasarkan metode jenis

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

Tersedia di Github

Berdasarkan pada API Plugin , Standar Pengkodean , dan Standar Dokumentasi .

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

Metode yang terorganisir secara longgar

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

Perhatikan bahwa semua plugin adalah "pengontrol" menurut standar WP.

Itu tergantung pada apa yang seharusnya dilakukan oleh plugin, tetapi dalam semua kasus saya akan mencoba untuk memisahkan output layar dari kode PHP sebanyak mungkin.

Inilah salah satu cara untuk melakukannya dengan mudah - pertama, tentukan fungsi yang memuat template:

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

Sekarang, jika plugin menggunakan widget untuk menampilkan data:

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

}

Templat:

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

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

<?php endwhile; ?>

File:

/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

Di mana Anda meletakkan CSS, JS, gambar, atau bagaimana Anda mendesain wadah untuk kait itu kurang penting. Ini masalah preferensi pribadi saya kira.

Itu tergantung pada plugin. Ini adalah struktur dasar saya untuk hampir setiap 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

Ini akan menjadi sesuatu yang masuk dalam libfolder.

Jika itu plugin yang sangat kompleks, dengan banyak fungsi admin area, saya akan menambahkan adminfolder untuk memuat semua file PHP itu. Jika plugin melakukan sesuatu seperti mengganti file tema yang disertakan , mungkin ada folder templateatau themejuga.

Jadi, struktur direktori mungkin terlihat seperti ini:

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

IMHO, rute termudah, paling kuat, dan paling bisa dikelola adalah dengan menggunakan struktur MVC, dan WP MVC dirancang untuk membuat penulisan plugin MVC sangat mudah (saya agak bias, meskipun ...). Dengan WP MVC, Anda cukup membuat model, tampilan, dan pengontrol, dan semua yang lain ditangani di belakang layar untuk Anda.

Kontroler dan tampilan yang terpisah dapat dibuat untuk bagian publik dan admin, dan keseluruhan kerangka kerja mengambil manfaat dari banyak fitur asli WordPress. Struktur file dan banyak fungsionalitasnya persis sama dengan yang ada di kerangka kerja MVC paling populer (Rails, CakePHP, dll).

Info lebih lanjut dan tutorial dapat ditemukan di sini:

• Halaman plugin
• Tutorial

Kami menggunakan campuran semua metode. Pertama-tama, kami menggunakan Zend Framework 1.11 di plugin kami dan oleh karena itu kami harus menggunakan struktur yang sama untuk file kelas karena mekanisme pengisian otomatis.

Struktur plugin inti kami (yang digunakan oleh semua plugin kami sebagai basis) terlihat mirip dengan ini:

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 memanggil webeo-core.phpfile di folder root plugin.
2. Dalam file ini kita akan mengatur path menyertakan PHP dan mendaftarkan kait aktivasi dan deaktivasi untuk plugin.
3. Kami juga memiliki Webeo_CoreLoaderkelas di dalam file ini, yang menetapkan beberapa konstanta plugin, menginisialisasi autoloader kelas dan melakukan panggilan ke metode pengaturan Core.phpkelas di dalam lib/Webeofolder. Ini berjalan pada plugins_loadedkait tindakan dengan prioritas 9.
4. The Core.phpkelas file bootstrap plugin kami. Nama ini didasarkan pada nama plugin.

Seperti yang Anda lihat, kami memiliki subdirektori di dalam libfolder untuk semua paket vendor kami ( Webeo, Zend). Semua sub paket di dalam vendor adalah struktur oleh modul itu sendiri. Untuk Mail Settingsformulir admin baru , kami memiliki struktur berikut:

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

Sub-plugin kami memiliki struktur yang sama dengan satu pengecualian. Kami melangkah lebih jauh ke dalam folder vendor karena untuk menyelesaikan konflik penamaan selama acara autoload. Kami juga menyebut plugrap boostrap sebagai E.g. Faq.phpprioritas 10di dalam 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

Saya mungkin akan mengganti nama libfolder menjadi vendorsdan memindahkan semua folder publik (css, gambar, js, bahasa) ke folder bernama publicdalam rilis berikutnya.

Seperti yang sudah dijawab oleh banyak orang di sini. Itu benar-benar tergantung pada apa yang seharusnya dilakukan oleh plugin, tetapi di sini adalah struktur dasar saya:

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

Saya sebagian dengan tata letak plugin berikut, tetapi biasanya berubah tergantung pada apa persyaratan plugin.

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 

Saya belum membuat plugin WordPress yang membutuhkan arsitektur gaya MVC tetapi jika saya ingin melakukan ini saya akan meletakkannya dengan direktori MVC terpisah, yang itu sendiri berisi pandangan / pengontrol / model.

Logika saya, semakin besar plugin, semakin banyak struktur yang saya gunakan.
Untuk plugin besar saya cenderung menggunakan MVC.
Saya menggunakan ini sebagai titik awal dan melewati apa yang tidak diperlukan.

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

Semua plugin saya mengikuti struktur ini, yang tampaknya sangat mirip dengan apa yang dilakukan kebanyakan pengembang lain:

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 biasanya merupakan kelas yang memuat semua file yang diperlukan dari inti / folder. Paling sering di kait init atau plugins_loaded.

Saya dulu awalan semua file saya juga, tetapi seperti @kaiser disebutkan di atas, itu benar-benar berlebihan dan saya baru-baru ini memutuskan untuk menghapusnya dari setiap plugin di masa depan.

Perpustakaan / folder menyimpan semua perpustakaan penolong eksternal yang bergantung pada plugin.

Bergantung pada plugin, mungkin ada file uninstall.php di root plugin juga. Namun, sebagian besar waktu ini ditangani melalui register_uninstall_hook ().

Jelas, beberapa plugin mungkin tidak memerlukan file admin atau template, dll, tetapi struktur di atas berfungsi untuk saya. Pada akhirnya Anda hanya perlu menemukan struktur yang berfungsi untuk Anda dan kemudian tetap menggunakannya.

Saya juga memiliki plugin pemula, berdasarkan pada struktur di atas yang saya gunakan sebagai titik awal untuk semua plugin saya. Yang perlu saya lakukan adalah melakukan pencarian / ganti untuk awalan fungsi / kelas dan pergilah. Ketika saya masih awalan file saya itu adalah langkah tambahan yang harus saya lakukan (dan cukup mengganggu pada saat itu), tapi sekarang saya hanya perlu mengganti nama folder plugin dan file plugin utama.

Juga, lihat boilerplate widget WP yang bagus ini . Ini memberi petunjuk besar pada struktur (bahkan jika tidak ada kelas atau folder untuk model terpisah).

Pendekatan yang kurang umum untuk penataan file dan direktori plugin adalah pendekatan tipe file. Layak disebutkan di sini untuk kelengkapan:

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

Setiap direktori hanya berisi file jenis itu. Perlu dicatat bahwa pendekatan ini gagal ketika Anda memiliki banyak jenis file .png .gif .jpgyang mungkin lebih logis diajukan di bawah satu direktori, images/misalnya.