Come strutturare un plugin

Questa non è una domanda su come creare un plugin per WordPress. Piuttosto, quali eventuali guide potrebbero essere applicate a come mettere insieme l'architettura dei file di qualsiasi plugin.

Alcuni altri linguaggi o librerie di programmazione hanno modi molto controllati di organizzare directory e file. A volte questo è fastidioso e mette in evidenza la libertà che offre PHP, ma i plugin WordPress a rovescio sono messi insieme in qualsiasi modo, come determinato dal loro autore.

Non c'è una risposta giusta , ma la mia speranza è quella di affinare il modo in cui io e gli altri creiamo plugin per renderli più facili da disabilitare per gli altri sviluppatori, più facili da eseguire il debug, più facili da navigare e forse più efficienti.

La domanda finale: cosa si pensa è il modo migliore per organizzare un plugin?

Di seguito sono riportate alcune strutture di esempio, ma non è in alcun modo un elenco esaustivo. Sentiti libero di aggiungere i tuoi consigli.

Presunta struttura predefinita

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

Metodo Model View Controller (MVC)

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

Le tre parti di MVC:

• Il modello interagisce con il database, interrogando e salvando i dati e contiene la logica.
• Il controller conterrebbe tag modello e funzioni che la vista utilizzerà.
• La vista è responsabile della visualizzazione dei dati forniti dal modello come costruiti dal controller.

Organizzato per metodo di tipo

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

Disponibile su Github

Basato sull'API Plugin , sugli standard di codifica e sugli standard di documentazione .

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

Metodo vagamente organizzato

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

Si noti che i plug-in sono tutti "controller" per gli standard WP.

Dipende da cosa dovrebbe fare il plugin, ma in ogni caso proverei a separare il più possibile l'output dello schermo dal codice PHP.

Ecco un modo per farlo facilmente: innanzitutto, definire una funzione che carica il modello:

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

Ora, se il plugin utilizza un widget per visualizzare i dati:

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

}

Il template:

<?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

La posizione in cui vengono posizionati CSS, JS, immagini o come si progetta il contenitore per i ganci è meno importante. Immagino sia una questione di preferenze personali.

Dipende dal plugin. Questa è la mia struttura di base per quasi tutti 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

Questo sarebbe qualcosa che andrebbe nella libcartella.

Se si tratta di un plug-in particolarmente complesso, con molte funzionalità dell'area di amministrazione, aggiungerei una admincartella per contenere tutti quei file PHP. Se il plugin fa qualcosa di simile sostituire inclusi file del tema , là forse un templateo themecartella pure.

Quindi, una struttura di directory potrebbe apparire così:

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

IMHO, il percorso più semplice, più potente e più gestibile è utilizzare una struttura MVC e WP MVC è progettato per rendere molto semplice la scrittura di plugin MVC (sono un po 'di parte, però ...). Con WP MVC, crei semplicemente modelli, viste e controller e tutto il resto viene gestito dietro le quinte per te.

È possibile creare controller e viste separati per le sezioni pubbliche e amministrative e l'intero framework sfrutta molte delle funzionalità native di WordPress. La struttura dei file e gran parte delle funzionalità sono esattamente le stesse dei framework MVC più popolari (Rails, CakePHP, ecc.).

Maggiori informazioni e un tutorial sono disponibili qui:

• Pagina del plugin
• lezione

Stiamo usando un mix di tutti i metodi. Prima di tutto, stiamo usando Zend Framework 1.11 nei nostri plugin e quindi abbiamo dovuto usare una struttura simile per i file di classe a causa del meccanismo di caricamento automatico.

La struttura del nostro plug-in principale (che viene utilizzato da tutti i nostri plug-in come base) è simile al seguente:

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 chiama il webeo-core.phpfile nella cartella principale del plugin.
2. In questo file imposteremo il percorso di inclusione di PHP e registreremo gli hook di attivazione e disattivazione per il plugin.
3. Abbiamo anche una Webeo_CoreLoaderclasse all'interno di questo file, che imposta alcune costanti del plugin, inizializza il caricatore automatico di classe ed effettua una chiamata al metodo di installazione della Core.phpclasse all'interno della lib/Webeocartella. Questo viene eseguito sul plugins_loadedgancio di azione con una priorità di 9.
4. La Core.phpclasse è il nostro file bootstrap del plugin. Il nome si basa sul nome del plugin.

Come puoi vedere, abbiamo una sottodirectory all'interno della libcartella per tutti i nostri pacchetti fornitore ( Webeo, Zend). Tutti i pacchetti secondari all'interno di un fornitore sono strutturati dal modulo stesso. Per un nuovo Mail Settingsmodulo di amministrazione, avremmo la seguente struttura:

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

I nostri plugin secondari hanno la stessa struttura con un'eccezione. Andiamo a un livello più profondo all'interno della cartella del fornitore a causa della risoluzione dei conflitti di denominazione durante l'evento di caricamento automatico. Chiamiamo anche la classe boostrap dei plugin in E.g. Faq.phpvia prioritaria 10all'interno plugins_loadeddell'hook.

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

Probabilmente rinominerò la libcartella vendorse sposterò tutte le cartelle pubbliche (css, immagini, js, lingue) in una cartella denominata publicnella prossima versione.

Come molti qui hanno già risposto Dipende da cosa dovrebbe fare il plugin, ma ecco la mia struttura di base:

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

Sono parziale al seguente layout di plug-in, tuttavia di solito cambia in base ai requisiti del plug-in.

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 

Devo ancora creare un plug-in WordPress che richieda un'architettura in stile MVC ma se dovessi farlo, lo imposterei con una directory MVC separata, che a sua volta contiene visualizzazioni / controller / modelli.

La mia logica, più grande è il plugin, più struttura utilizzo.
Per i plug-in di grandi dimensioni tendo a utilizzare MVC.
Lo uso come punto di partenza e salto ciò che non è necessario.

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

Tutti i miei plugin seguono questa struttura, che sembra essere molto simile a quello che fanno gli altri sviluppatori:

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 è quindi di solito una classe che carica tutti i file richiesti dal core / cartella. Molto spesso sull'hook init o plugins_loaded.

Avevo anche il prefisso di tutti i miei file, ma come notato sopra da @kaiser, è davvero ridondante e di recente ho deciso di rimuoverlo da eventuali plugin futuri.

La libreria / cartella contiene tutte le librerie di helper esterne dalle quali il plug-in potrebbe dipendere.

A seconda del plugin, potrebbe esserci un file uninstall.php anche nella radice del plugin. Il più delle volte questo viene gestito tramite register_uninstall_hook (), però.

Ovviamente, alcuni plugin potrebbero non richiedere alcun file o modello di amministrazione, ecc., Ma la struttura sopra funziona per me. Alla fine devi solo trovare una struttura che funzioni per te e poi attenersi ad essa.

Ho anche un plug-in di avviamento, basato sulla struttura sopra che uso come punto di partenza per tutti i miei plug-in. Tutto quello che devo fare è quindi cercare / sostituire i prefissi funzione / classe e vado via. Quando stavo ancora aggiungendo il prefisso ai miei file che era un ulteriore passo che dovevo fare (e abbastanza fastidioso), ma ora devo solo rinominare la cartella del plugin e il file del plugin principale.

Inoltre, guarda questa fantastica piastra di comando per widget WP . Fornisce ottimi suggerimenti sulle strutture (anche se non esiste una classe né una cartella per modelli separati).

Un approccio meno comune alla strutturazione dei file e delle directory di un plugin è l'approccio del tipo di file. Vale la pena menzionare qui per completezza:

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

Ogni directory contiene solo file di quel tipo. Vale la pena notare che questo approccio fallisce quando si hanno molti tipi di file .png .gif .jpgche potrebbero essere archiviati in modo più logico in una singola directory, images/ad esempio.