it-swarm-eu.dev

Jak strukturovat plugin

To není otázka, jak vytvořit plugin WordPress. Co, pokud vůbec, by se dalo použít na to, jak sestavit architekturu souboru libovolného pluginu.

Některé další programovací jazyky nebo knihovny mají velmi řízené způsoby organizování adresářů a souborů. Někdy je to otravné a zdůrazňuje svobodu, kterou nabízí PHP, ale na flip-side WordPress pluginy jsou sestaveny v jakémkoli módě, jak je určeno jejich autorem.

Neexistuje správná odpověď, ale doufám, že se zpřesníme, jak budu i jiní budovat pluginy, aby byly pro ostatní vývojáře přátelštější, aby se lépe zbavily, usnadnily ladění, snadnější navigaci a možná i více účinný.

Poslední otázka: co you myslím, že je nejlepší způsob, jak organizovat plugin?

Níže je několik vzorových struktur, ale v žádném případě není vyčerpávající seznam. Přidejte své vlastní doporučení.

Předpokládaná výchozí struktura

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

Metoda MVC (Model View Controller)

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

Tři části MVC:

  • model komunikuje s databází, dotazuje a ukládá data a obsahuje logiku.
  • controller by obsahoval tagy šablony a funkce, které by zobrazení použilo.
  • view je zodpovědný za zobrazení dat poskytnutých modelem, jak je zkonstruoval regulátor.

Uspořádáno metodou typu

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

Dostupné na Github

Na základě Plugin API , Kódovacích norem , a Dokumentačních standardů .

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

Volně organizovaná metoda

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

Všimněte si, že pluginy jsou všechny "řadiče" podle WP standardů.

Záleží na tom, co má plugin udělat, ale ve všech případech bych se snažil oddělit výstup obrazovky z kódu PHP co nejvíce.

Jedním ze způsobů, jak to udělat snadno - nejprve definujte funkci, která načte šablonu:

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

Pokud plugin používá k zobrazení dat widget:

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

}

Šablona:

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

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

<?php endwhile; ?>

Soubory:

/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

Kde umístíte své CSS, JS, obrázky, nebo jak navrhujete kontejner pro háčky je méně důležité. Myslím, že je to záležitost osobních preferencí.

16
onetrickpony

IMHO, nejjednodušší, nejvýkonnější a nejudržovatelnější trasa je použití struktury MVC, a WP MVC je navržen tak, aby zápis MVC pluginů byl velmi snadný (i když jsem trochu zaujatý) ... . S WP MVC jednoduše vytvoříte modely, pohledy a řadiče a vše ostatní je pro vás zpracováváno v zákulisí.

Pro veřejné a administrační sekce mohou být vytvořeny oddělené řadiče a pohledy a celý rámec využívá mnoho nativních funkcí aplikace WordPress. Struktura souboru a velká část funkčnosti je přesně stejná jako v nejoblíbenějších MVC frameworkech (Rails, CakePHP, atd.).

Více informací a návod naleznete zde:

6
Tom

Záleží na pluginu. Toto je moje základní struktura pro téměř každý 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

Toto by bylo něco, co by šlo do složky lib.

Pokud je to zvláště složitý plugin, s mnoha funkcemi pro správu oblastí, přidal bych složku admin, která bude obsahovat všechny soubory PHP. Pokud plugin udělá něco jako nahrazení zahrnutých motivových souborů , tam je možná také template nebo theme složka.

Struktura adresářů tak může vypadat takto:

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

Stejně jako mnozí zde již odpověděli opravdu závisí na tom, co má plugin dělat, ale tady je moje základní struktura:

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
5
Bainternet

Používáme směs všech metod. Nejdříve používáme Zend Framework 1.11 v našich pluginech, a proto jsme museli použít podobnou strukturu pro soubory třídy, protože se jedná o mechaniku autoload.

Struktura našeho základního pluginu (který je používán všemi našimi zásuvnými moduly jako základ) vypadá podobně jako toto:

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 volá soubor webeo-core.php v kořenové složce pluginu.
  2. V tomto souboru nastavíme PHP cestu a zaregistrujeme aktivační a deaktivační háčky pro plugin.
  3. V tomto souboru máme také třídu Webeo_CoreLoader, která nastavuje některé konstanty pluginů, inicializuje třídu autoloaderů a zavolá metodu nastavení Core.php třídy do složky lib/Webeo. To běží na h_ akce plugins_loaded s prioritou 9.
  4. Třída Core.php je náš soubor bootstrap. Název je založen na názvu zásuvných modulů.

Jak vidíte, máme ve složce lib podadresář pro všechny naše balíčky dodavatelů (Webeo, Zend). Všechny dílčí balíčky uvnitř dodavatele jsou strukturovány samotným modulem. Pro nový formulář Mail Settings admin bychom měli následující strukturu:

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

Naše sub-pluginy mají stejnou strukturu s jednou výjimkou. Jdeme o úroveň hlouběji uvnitř složky dodavatele kvůli vyřešení konfliktů pojmenování během události autoload. Také zavoláme pluginy boostrap třídy E.g. Faq.php na prioritu 10 uvnitř háku 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

Pravděpodobně přejmenuji složku lib na vendors a přesuneme všechny veřejné složky (css, obrázky, js, jazyky) do složky s názvem public v dalším vydání.

5
rofflox

Moje logika, čím větší je plugin, tím více struktury používám.
Pro velké pluginy používám MVC.
Používám to jako výchozí bod a přeskoč, co není potřeba.

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

Já jsem částečný k následujícímu rozložení pluginů, nicméně to obvykle se mění v závislosti na tom, co jsou požadavky na 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 

Musím ještě vytvořit WordPress plugin, který vyžaduje architekturu stylu MVC, ale kdybych to udělal, rozložil bych ho do samostatného adresáře MVC, který sám obsahuje pohledy/řadiče/modely.

4
mystline

Všechny mé pluginy následují tuto strukturu, což se zdá být velmi podobné tomu, co dělají ostatní devs:

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 je pak obvykle třída, která načte všechny požadované soubory z jádra/složky. Nejčastěji na háku init nebo plugins_loaded.

Použil jsem také prefix všech svých souborů, ale jak je uvedeno výše, je to opravdu nadbytečné a nedávno jsem se rozhodl, že ho odstraním z budoucích pluginů.

Knihovna/složka obsahuje všechny externí pomocné knihovny, na kterých může plugin záviset.

V závislosti na zásuvném modulu může být v kořenovém adresáři pluginu také soubor uninstall.php. Většinu času je však zpracovávána přes register_uninstall_hook ().

Je zřejmé, že některé pluginy nemusí vyžadovat žádné admin soubory nebo šablony, atd., Ale výše uvedená struktura funguje pro mě. Nakonec musíte najít strukturu, která pro vás funguje a pak se s ní držet.

Mám také startovací plugin založený na struktuře, kterou používám jako výchozí bod pro všechny své pluginy. Jediné, co potřebuji udělat, je hledání/nahrazení prefixů funkce/třídy a vypnutí. Když jsem byl ještě prefixing mé soubory, které bylo další krok jsem musel udělat (a docela nepříjemné na to), ale teď jsem jen přejmenovat složku plugin a hlavní plugin soubor.

3
shabushabu

Také viz toto velké WP widget kotle . To dává velké rady o strukturách (i když neexistuje třída ani složka pro samostatné modely).

1
Cedric

Méně častý přístup ke strukturování souborů a adresářů pluginu je přístup typu souboru. Za úplnost stojí za zmínku:

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

Každý adresář obsahuje pouze soubory tohoto typu. Stojí za povšimnutí, že tento přístup je nedostatečný, pokud máte mnoho typů souborů .png .gif .jpg, které by mohly být logicky uloženy v jednom adresáři, například images/.

0
henrywright