So strukturieren Sie ein Plugin

Dies ist keine Frage zum Erstellen eines WordPress-Plugins. Vielmehr könnten, wenn überhaupt, Anleitungen angewendet werden, wie die Dateiarchitektur eines Plugins zusammengestellt werden kann.

Einige andere Programmiersprachen oder Bibliotheken verfügen über sehr kontrollierte Methoden zum Organisieren von Verzeichnissen und Dateien. Manchmal ist das ärgerlich und unterstreicht die Freiheit, die PHP bietet, aber auf der anderen Seite werden WordPress-Plugins auf jede vom Autor festgelegte Weise zusammengestellt.

Es gibt keine richtige Antwort , aber ich hoffe zu verfeinern, wie ich und andere Plugins erstellen, um sie für andere Entwickler benutzerfreundlicher zu gestalten, leichter zu debuggen, einfacher zu navigieren und möglicherweise effizienter zu gestalten.

Die letzte Frage: Was ist Ihrer Meinung nach der beste Weg, ein Plugin zu organisieren?

Im Folgenden sind einige Beispielstrukturen aufgeführt, die jedoch in keiner Weise erschöpfend sind. Fühlen Sie sich frei, Ihre eigenen Empfehlungen hinzuzufügen.

Angenommene Standardstruktur

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

Model View Controller (MVC) -Methode

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

Die drei Teile von MVC:

• Das Modell interagiert mit der Datenbank, fragt ab und speichert Daten und enthält Logik.
• Der Controller würde Vorlagen-Tags und -Funktionen enthalten, die die Ansicht verwenden würde.
• Die Ansicht ist dafür verantwortlich, die vom Modell bereitgestellten Daten anzuzeigen, wie sie vom Controller erstellt wurden.

Nach Typmethode organisiert

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

Erhältlich bei Github

Basiert auf der Plugin-API , den Codierungsstandards und den Dokumentationsstandards .

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

Locker organisierte Methode

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

Beachten Sie, dass Plugins nach WP-Standards allesamt "Controller" sind.

Es hängt davon ab, was das Plugin tun soll, aber in jedem Fall würde ich versuchen, die Bildschirmausgabe so weit wie möglich vom PHP-Code zu trennen.

Dies ist eine einfache Möglichkeit: Definieren Sie zunächst eine Funktion, mit der die Vorlage geladen wird:

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

Wenn das Plugin nun ein Widget zur Anzeige von Daten verwendet:

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

}

Die Vorlage:

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

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

<?php endwhile; ?>

Dateien:

/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

Wo setzen Sie Ihre CSS, JS, Bilder, oder wie Sie den Container für die Haken entwerfen, ist weniger wichtig. Ich denke, es ist eine Frage der persönlichen Präferenz.

Das hängt vom Plugin ab. Dies ist meine Grundstruktur für fast jedes 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

Dies wäre etwas, das in den libOrdner gehen würde .

Wenn es sich um ein besonders komplexes Plugin mit vielen Funktionen im Administrationsbereich handelt, würde ich einen adminOrdner hinzufügen , der alle diese PHP-Dateien enthält. Wenn das Plugin die enthaltenen Themendateien ersetzt , gibt es möglicherweise auch einen templateoder themeOrdner.

Eine Verzeichnisstruktur könnte also so aussehen:

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

IMHO, die einfachste, leistungsfähigste und am besten zu wartende Methode ist die Verwendung einer MVC-Struktur, und WP MVC wurde entwickelt, um das Schreiben von MVC-Plugins sehr einfach zu machen (ich bin allerdings etwas voreingenommen ...). Mit WP MVC erstellen Sie einfach die Modelle, Ansichten und Controller, und alles andere wird hinter den Kulissen für Sie erledigt.

Separate Controller und Ansichten können für die Bereiche "public" und "admin" erstellt werden, und das gesamte Framework nutzt viele der nativen Funktionen von WordPress. Die Dateistruktur und ein Großteil der Funktionen ist genau so wie in den gängigsten MVC-Frameworks (Rails, CakePHP usw.).

Weitere Informationen und ein Tutorial finden Sie hier:

• Plugin-Seite
• Lernprogramm

Wir verwenden eine Mischung aller Methoden. Als erstes verwenden wir das Zend Framework 1.11 in unseren Plugins und mussten daher wegen der Autoload-Mechanik eine ähnliche Struktur für die Klassendateien verwenden.

Die Struktur unseres Core-Plugins (das von allen unseren Plugins als Basis verwendet wird) sieht ungefähr so ​​aus:

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 ruft die webeo-core.phpDatei im Plugin-Stammverzeichnis auf.
2. In dieser Datei setzen wir den PHP-Include-Pfad und registrieren die Aktivierungs- und Deaktivierungs-Hooks für das Plugin.
3. In Webeo_CoreLoaderdieser Datei befindet sich auch eine Klasse, die einige Plugin-Konstanten festlegt, den Klassen-Autoloader initialisiert und die Setup-Methode der Core.phpKlasse im lib/WebeoOrdner aufruft. Dieser läuft am plugins_loadedAktionshaken mit der Priorität von 9.
4. Die Core.phpKlasse ist unsere Plugin-Bootstrap-Datei. Der Name basiert auf dem Namen des Plugins.

Wie Sie sehen, befindet sich in dem libOrdner ein Unterverzeichnis für alle Herstellerpakete ( Webeo, Zend). Alle Unterpakete innerhalb eines Anbieters werden vom Modul selbst strukturiert. Für ein neues Mail SettingsAdministrationsformular hätten wir folgende Struktur:

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

Unsere Sub-Plugins haben mit einer Ausnahme die gleiche Struktur. Wir gehen eine Ebene tiefer in den Herstellerordner, da Namenskonflikte während des Autoload-Ereignisses behoben werden. Wir bezeichnen die Plugins auch als Boostrap-Klasse E.g. Faq.phpmit Priorität 10innerhalb des Hooks plugins_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

Ich werde den libOrdner wahrscheinlich umbenennen vendorsund alle öffentlichen Ordner (CSS, Bilder, JS, Sprachen) in einen Ordner verschieben, der publicin der nächsten Version benannt wird.

Wie viele hier schon geantwortet haben Es kommt wirklich darauf an, was das Plugin machen soll, aber hier ist meine Grundstruktur:

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

Ich bin teilweise an dem folgenden Plugin-Layout interessiert, es ändert sich jedoch normalerweise abhängig von den Plugin-Anforderungen.

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 

Ich habe noch kein WordPress-Plugin erstellt, das eine MVC-Architektur erfordert, aber wenn ich dies tun würde, würde ich es mit einem separaten MVC-Verzeichnis auslegen, das selbst Ansichten / Controller / Modelle enthält.

Meine Logik, je größer das Plugin, desto mehr Struktur verwende ich.
Für große Plugins benutze ich meistens MVC.
Ich benutze dies als Ausgangspunkt und überspringe, was nicht benötigt wird.

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

Alle meine Plugins folgen dieser Struktur, die den meisten anderen Entwicklern sehr ähnlich zu sein scheint:

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 ist dann normalerweise eine Klasse, die alle benötigten Dateien aus dem core / Ordner lädt. Am häufigsten am init- oder plugins_loaded-Hook.

Früher habe ich auch alle meine Dateien mit einem Präfix versehen, aber wie @kaiser oben angemerkt hat, ist es wirklich überflüssig und ich habe vor kurzem beschlossen, es von zukünftigen Plugins zu entfernen.

Die Bibliothek / der Ordner enthält alle externen Hilfsbibliotheken, von denen das Plugin abhängig sein kann.

Je nach Plugin befindet sich möglicherweise auch eine uninstall.php-Datei im Plugin-Stammverzeichnis. Meistens wird dies jedoch über register_uninstall_hook () erledigt.

Offensichtlich erfordern einige Plugins möglicherweise keine Admin-Dateien, Vorlagen usw., aber die obige Struktur funktioniert für mich. Am Ende musst du nur eine Struktur finden, die für dich funktioniert und dabei bleiben.

Ich habe auch ein Starter-Plugin, basierend auf der obigen Struktur, die ich als Ausgangspunkt für alle meine Plugins verwende. Alles, was ich dann tun muss, ist ein Suchen / Ersetzen nach Funktions- / Klassenpräfixen und los geht's. Als ich noch meine Dateien vorangestellt habe, war das ein zusätzlicher Schritt, den ich machen musste (und der ziemlich nervig ist), aber jetzt muss ich nur noch den Plugin-Ordner und die Haupt-Plugin-Datei umbenennen.

Sehen Sie sich auch dieses großartige WP-Widget an . Es gibt großartige Hinweise zu Strukturen (auch wenn es keine Klasse oder keinen Ordner für separate Modelle gibt).

Ein weniger verbreiteter Ansatz zur Strukturierung der Dateien und Verzeichnisse eines Plugins ist der Dateityp. Der Vollständigkeit halber sei hier erwähnt:

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

Jedes Verzeichnis enthält nur Dateien dieses Typs. Es ist erwähnenswert, dass dieser Ansatz unzureichend ist, wenn Sie viele Dateitypen haben .png .gif .jpg, die möglicherweise logischer in einem einzelnen Verzeichnis abgelegt sind images/.