Bir eklenti nasıl yapılandırılır

Bu bir WordPress eklentisi oluşturma hakkında bir soru değil. Aksine, varsa, herhangi bir eklentinin dosya mimarisini nasıl bir araya getireceğinize dair kılavuzlar uygulanabilir.

Diğer bazı programlama dilleri veya kütüphaneleri, dizinleri ve dosyaları organize etmenin çok kontrollü yollarına sahiptir. Bazen bu can sıkıcıdır ve PHP'nin sunduğu özgürlüğü vurgular, ancak flip-side WordPress eklentileri yazarları tarafından belirlenen şekilde bir araya getirilir.

Doğru bir cevap yok , ancak umudum, diğer geliştiricilerin nasıl diseksiyon yapmaları, hata ayıklamaları, daha kolay gezinmeleri ve muhtemelen daha verimli olmaları için onları daha kolay hale getirmek için eklentileri nasıl geliştirdiğimi geliştirmek.

Son soru: Ne yapmak sen bir eklenti düzenlemenin en iyi yolu olduğunu düşünüyorum?

Aşağıda birkaç örnek yapı bulunmaktadır, ancak bunların hiçbiri ayrıntılı bir liste değildir. Kendi önerilerinizi eklemek için çekinmeyin.

Varsayılan Varsayılan Yapı

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

Model Görünüm Kontrol Cihazı (MVC) yöntemi

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

MVC'nin üç bölümü:

• Model veritabanı ile etkileşimde bulunduğunda, sorgulama ve verilerin kaydedilmesi ve mantığı içerir.
• Kontrolör görünümü kullanmak olacağını şablon etiketleri ve işlevleri içerecektir.
• Görünüşüdür kontrolörü tarafından yapılan modelin sağladığı verileri görüntülemek için sorumludur.

Tip yöntemine göre düzenlenmiş

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

WordPress Eklenti Kazanı

Github'da mevcut

Eklenti API'sine , Kodlama Standartlarına ve Dokümantasyon Standartlarına dayanarak .

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

Gevşek organize yöntem

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

Eklentilerin WP standartlarına göre tüm "denetleyiciler" olduğuna dikkat edin.

Eklentinin ne yapması gerektiğine bağlı, ancak her durumda ekran çıktısını PHP kodundan mümkün olduğu kadar ayırmaya çalışacağım.

Bunu kolayca yapmanın bir yolu: İlk önce şablonu yükleyen bir işlev tanımlayın:

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

Şimdi, eklenti verileri görüntülemek için bir widget kullanıyorsa:

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

}

Şablon:

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

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

<?php endwhile; ?>

Dosyalar:

/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'nizi, JS'nizi, resimlerinizi nereye koyarsınız veya kancalar için kabı nasıl tasarlarsınız daha az önemlidir. Bu kişisel tercih meselesi sanırım.

Eklentiye bağlı. Bu hemen hemen her eklenti için benim temel yapıdır:

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

Bulib klasöre gidecek bir şey olurdu .

Özellikle karmaşık bir eklenti ise, çok sayıda yönetici alanı işlevselliği varsa, admintüm bu PHP dosyalarını içerecek bir klasör eklerdim. Eklenti dahil tema dosyalarını değiştirmek gibi bir şey yaparsa , belki de bir templateveya themeklasör var.

Yani, bir dizin yapısı şöyle görünebilir:

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

IMHO, en kolay, en güçlü ve en sürdürülebilir rota MVC yapısını kullanmaktır ve WP MVC MVC eklentilerini yazmayı çok kolay hale getirecek şekilde tasarlanmıştır (biraz önyargılıyım ...). WP MVC ile, modelleri, görünümleri ve denetleyicileri hazırlarsınız ve diğer her şey sizin için perde arkasında yapılır.

Genel ve yönetici bölümleri için ayrı denetleyiciler ve görünümler oluşturulabilir ve tüm çerçeve WordPress'in yerel özelliklerinden yararlanır. Dosya yapısı ve işlevselliğin çoğu, en popüler MVC çerçevelerinde (Rails, CakePHP vb.) Olduğu gibi tamamen aynıdır.

Daha fazla bilgi ve bir öğretici burada bulunabilir:

• Eklenti sayfası
• Eğitimi

Tüm yöntemlerin bir karışımını kullanıyoruz. Öncelikle, eklentilerimizde Zend Framework 1.11 kullanıyoruz ve bu nedenle de autoload tamircisi nedeniyle sınıf dosyaları için benzer bir yapı kullanmak zorunda kaldık.

Çekirdek eklentimizin yapısı (tüm eklentilerimiz tarafından baz olarak kullanılır) şuna benzer:

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.phpdosyayı eklenti kök klasöründe çağırır .
2. Bu dosyada PHP içerir yolunu ayarlayacağız ve eklenti için etkinleştirme ve devre dışı bırakma kancalarını kaydedeceğiz.
3. Ayrıca, Webeo_CoreLoaderbazı eklenti sabitlerini ayarlayan, sınıf otomatik yükleyicisini başlatan ve klasörün Core.phpiçindeki sınıfın kurulum yöntemine çağrı yapan bir dosyamız da var lib/Webeo. Bu plugins_loadedişlem eylem kancasına öncelik vererek çalışır 9.
4. Core.phpSınıf eklentimizin önyükleme dosyasıdır. Bu ad, eklentilerin adını temel alır.

Gördüğünüz gibi, libtüm satıcı paketlerimiz için ( Webeo, Zend) klasörün içinde bir alt dizine sahibiz . Bir satıcının içindeki tüm alt paketler modülün kendisi tarafından yapılandırılmıştır. Yeni bir Mail Settingsyönetici formu için aşağıdaki yapıya sahip oluruz:

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

Alt eklentilerimiz bir istisna dışında aynı yapıya sahiptir. Autoload olayı sırasındaki adlandırma çakışmalarını çözdüğümüz için satıcı klasörünün içinde daha derine iniyoruz. Ayrıca, eklenti boostrap sınıfını kanca içinde E.g. Faq.phpöncelikli olarak adlandırırız .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

Büyük olasılıkla libklasörü yeniden adlandırır vendorsve tüm ortak klasörleri (css, görüntüler, js, diller) bir publicsonraki sürümde adlandırılmış bir klasöre taşır .

Burada birçok gibi zaten Gerçekten cevap bağlıdır eklenti yapmak gerekiyordu ne, ama burada benim taban yapısı şöyledir:

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

Aşağıdaki eklenti düzenine kısmi olduğum halde, genellikle eklenti gereksinimlerinin ne olduğuna bağlı olarak değişir.

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 

Henüz MVC tarzı mimariye ihtiyaç duyan bir WordPress eklentisi oluşturmam gerekiyor, ancak bunu yapacak olsam, onu görüntüler / denetleyiciler / modeller içeren ayrı bir MVC dizini ile düzenlerdim.

Mantığım, eklenti büyüdükçe, daha fazla yapı kullanıyorum.
Büyük eklentiler için MVC kullanma eğilimindeyim.
Bunu bir başlangıç ​​noktası olarak kullanıyorum ve gerekmeyen şeyleri atlıyorum.

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

Bütün eklentilerim bu yapıyı takip ediyor, ki bu diğer pek çok devin yaptıklarına çok benziyor.

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, genellikle gerekli tüm dosyaları çekirdek / klasörden yükleyen bir sınıftır. Genellikle init veya plugins_loaded kancalarında.

Tüm dosyalarımı da ön eklerdim, ancak yukarıda @kaiser'ın belirttiği gibi, gerçekten gereksiz ve yakın zamanda gelecekteki eklentilerden kaldırmaya karar verdim.

Kitaplık / klasör, eklentinin bağlı olabileceği tüm harici yardımcı kitaplıkları tutar.

Eklentiye bağlı olarak, eklenti kökünde bir uninstall.php dosyası olabilir. Bununla birlikte, çoğu zaman register_uninstall_hook () aracılığıyla işleniyor.

Açıkçası, bazı eklentiler herhangi bir yönetici dosyası veya şablonu vb. Gerektirmeyebilir, ancak yukarıdaki yapı benim için çalışıyor. Sonunda, sadece sizin için işe yarayan bir yapı bulmanız ve sonra buna bağlı kalmanız gerekir.

Ayrıca tüm eklentilerim için başlangıç ​​noktası olarak kullandığım yukarıdaki yapıyı temel alan bir başlangıç ​​eklentisine sahibim. O zaman tek yapmam gereken fonksiyon / sınıf önekleri için bir arama / değiştirme yapmak ve gitmem. Hala dosyalarımı ön eklerken yapmak zorunda olduğum ekstra bir adımdı (ve bu konuda oldukça sinir bozucu), ama şimdi sadece eklenti klasörünü ve ana eklenti dosyasını yeniden adlandırmam gerekiyor.

Ayrıca, bu harika WP widget kaynatıcısına bakınız . Yapılardan büyük ipuçları verir (ayrı modeller için bir sınıf veya klasör olmasa bile).

Bir eklentinin dosyalarını ve dizinlerini yapılandırmak için daha az yaygın bir yaklaşım, dosya türü yaklaşımıdır. Burada tamlık için bahsetmeye değer:

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

Her dizin yalnızca bu tür dosyaları içerir. Örneğin .png .gif .jpg, tek bir dizinde daha mantıklı dosyalanmış birçok dosya türünüz olduğunda bu yaklaşımın yetersiz kaldığına dikkat etmek gerekir images/.