it-swarm.com.de

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 macht dudenkst, ist der beste Weg, ein Plugin zu organisieren?

Nachfolgend einige Beispielstrukturen, jedoch keine vollständige Liste. 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 Template-Tags und Funktionen enthalten, die die Ansicht verwenden würde.
  • Die Ansicht ist dafür verantwortlich, die vom Modell bereitgestellten Daten so anzuzeigen, wie sie vom Controller erstellt wurden.

Sortiert nach Typ Methode

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

Verfügbar auf Github

Basierend auf der Plugin API , Coding Standards , und Documentation Standards .

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

lose 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
37
developdaly

Beachten Sie, dass Plugins nach WP Standards alle "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 Code PHP 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.

16
onetrickpony

IMHO, die einfachste, leistungsstärkste und am besten wartbare 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 sind genau die gleichen wie in den gängigsten MVC-Frameworks (Rails, CakePHP usw.).

Weitere Informationen und ein Tutorial finden Sie hier:

6
Tom

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ürde in den Ordner lib verschoben.

Wenn es sich um ein besonders komplexes Plugin mit vielen Funktionen im Administrationsbereich handelt, würde ich einen Ordner admin hinzufügen, der alle diese PHP Dateien enthält. Wenn das Plugin so etwas wie das Ersetzen der enthaltenen Themendateien macht, gibt es möglicherweise auch einen template- oder theme -Ordner.

Eine Verzeichnisstruktur könnte also so aussehen:

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

Wir verwenden eine Mischung aller Methoden. Als erstes verwenden wir das Zend Framework 1.11 in unseren Plugins und mussten daher wegen des Autoload-Mechanismus 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.php-Datei 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. Wir haben auch eine Webeo_CoreLoader-Klasse in dieser Datei, die einige Plugin-Konstanten festlegt, den Klassen-Autoloader initialisiert und die Setup-Methode der Core.php-Klasse im lib/Webeo-Ordner aufruft. Dies wird auf dem Aktions-Hook plugins_loaded mit der Priorität 9 ausgeführt.
  4. Die Klasse Core.php ist unsere Plugin-Bootstrap-Datei. Der Name basiert auf dem Namen des Plugins.

Wie Sie sehen, befindet sich im Ordner lib ein Unterverzeichnis für alle unsere Anbieterpakete (Webeo, Zend). Alle Unterpakete innerhalb eines Anbieters werden vom Modul selbst strukturiert. Für ein neues Mail Settings Admin-Formular hätten wir die 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 nennen die Plugins auch die Boostrap-Klasse E.g. Faq.php bei Priorität 10 innerhalb 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 Ordner lib wahrscheinlich in vendors umbenennen und alle öffentlichen Ordner (CSS, Bilder, JS, Sprachen) in der nächsten Version in einen Ordner mit dem Namen public verschieben.

5
rofflox

Meine Logik, je größer das Plugin, desto mehr Struktur verwende ich.
Für große Plugins verwende 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
4
janw

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.

4
mystline

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. Meistens auf dem 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.

3
shabushabu

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

1
Cedric

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 .png .gif .jpg haben, die möglicherweise logischer in einem einzigen Verzeichnis abgelegt sind, z. B. images/.

0
henrywright