Como estruturar um plugin

34

Esta não é uma questão sobre como construir um plugin para WordPress. Em vez disso, quais guias, se houver, poderiam ser aplicados a como reunir a arquitetura de arquivos de qualquer plugin.

Algumas outras linguagens de programação ou bibliotecas têm maneiras muito controladas de organizar diretórios e arquivos. Às vezes isso é irritante e destaca a liberdade que o PHP oferece, mas os plugins do WordPress são colocados juntos de qualquer maneira, conforme determinado pelo autor.

Não há uma resposta certa , mas minha esperança é refinar como eu, e outros, construímos plugins para torná-los mais amigáveis para outros desenvolvedores, facilitar a depuração, facilitar a navegação e possivelmente mais eficiente.

A pergunta final: o que você acha que é a melhor maneira de organizar um plug-in?

Abaixo estão algumas estruturas de exemplo, mas de forma alguma é uma lista exaustiva. Sinta-se à vontade para adicionar suas próprias recomendações.

Estrutura padrão assumida

  • %código%
    • %código%
      • %código%
        • /wp-content

Método do Model View Controller (MVC)

  • %código%
    • %código%
      • %código%
        • %código%
          • /plugins
        • %código%
          • /my-plugin
        • %código%
          • my-plugin.php
        • /wp-content

As três partes do MVC:

  • O modelo interage com o banco de dados, consultando e salvando dados e contém lógica.
  • O controller conteria tags e funções de modelo que a view usaria.
  • A visão é responsável por exibir os dados fornecidos pelo modelo conforme construído pelo controlador.

Organizado por tipo de método

  • %código%
    • %código%
      • %código%
        • %código%
          • /plugins
        • %código%
          • /my-plugin
          • /controller
        • %código%
          • Controller.php
        • %código%
          • /model
        • %código%
          • Model.php
        • %código%
          • /view
        • view.php

Método organizado livremente

  • %código%
    • %código%
      • %código%
        • my-plugin.php
        • /wp-content
        • /plugins
        • /my-plugin
        • /admin
        • admin.php
        • /assets
        • css/
por developdaly 08.04.2012 / 18:13

10 respostas

16

Observe que os plug-ins são todos "controladores" pelos padrões do WP.

Depende do que o plugin deve fazer, mas em todos os casos eu tentaria separar a saída de tela do código PHP o máximo possível.

Aqui está uma maneira de fazer isso com facilidade: primeiro, defina uma função que carregue o modelo:

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

Agora, se o plug-in usar um widget para exibir dados:

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

}

O modelo:

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

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

<?php endwhile; ?>

Arquivos:

/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

Onde você coloca suas imagens CSS, JS, ou como você desenha o container para os ganchos é menos importante. É uma questão de preferência pessoal, eu acho.

    
por onetrickpony 09.04.2012 / 15:21
6

Depende do plugin. Esta é minha estrutura básica para quase todos os plugins:

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

Este seria algo que iria para a pasta lib .

Se for um plug-in particularmente complexo, com muita funcionalidade da área administrativa, adicionarei uma pasta admin para conter todos esses arquivos PHP. Se o plug-in fizer algo como substituir arquivos de tema incluídos, talvez haja um template ou theme pasta também.

Assim, uma estrutura de diretórios pode ser assim:

my-plugin/
    inc/
    lib/
    admin/
    templates/
    css/
    js/
    images/
    lang/
    my-plugin.php
    readme.txt
    
por chrisguitarguy 09.04.2012 / 07:13
6

IMHO, a rota mais fácil, mais poderosa e mais sustentável é usar uma estrutura MVC, e o WP MVC é projetado para facilitar a escrita de plugins MVC (eu sou um pouco tendencioso, embora ...). Com o WP MVC, você simplesmente faz os modelos, visualizações e controladores, e tudo o mais é tratado nos bastidores para você.

Controladores e visualizações separadas podem ser feitos para as seções pública e administrativa, e toda a estrutura aproveita muitos dos recursos nativos do WordPress. A estrutura do arquivo e a maior parte da funcionalidade são exatamente as mesmas das estruturas MVC mais populares (Rails, CakePHP, etc).

Mais informações e um tutorial podem ser encontrados aqui:

por Tom 14.04.2012 / 16:29
5

Estamos usando uma mistura de todos os métodos. Primeiro de tudo, estamos usando o Zend Framework 1.11 em nossos plugins e, portanto, tivemos que usar uma estrutura semelhante para os arquivos de classe por causa da mecânica de autoload.

A estrutura do nosso plugin principal (que é usado por todos os nossos plugins como base) se parece com isso:

webeo-core/
    css/
    images/
    js/
    languages/
    lib/
        Webeo/
            Core.php
        Zend/
            /** ZF files **/
        Loader.php
    views/
    readme.txt
    uninstall.php
    webeo-core.php
  1. O WordPress chama o arquivo webeo-core.php na pasta raiz do plugin.
  2. Neste arquivo, vamos definir o caminho de inclusão do PHP e registrar os ganchos de ativação e desativação do plug-in.
  3. Também temos uma classe Webeo_CoreLoader nesse arquivo, que define algumas constantes de plug-in, inicializa o carregador automático de classes e faz uma chamada para o método de configuração da classe Core.php dentro da pasta lib/Webeo . Isso é executado no gancho de ação plugins_loaded com uma prioridade de 9 .
  4. A classe Core.php é o nosso arquivo de bootstrap do plugin. O nome é baseado no nome dos plugins.

Como você pode ver, temos um subdiretório dentro da pasta lib para todos os nossos pacotes de fornecedores ( Webeo , Zend ). Todos os sub pacotes dentro de um fornecedor são estruturados pelo próprio módulo. Para um novo formulário Mail Settings admin, teríamos a seguinte estrutura:

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

Nossos sub-plugins têm a mesma estrutura com uma exceção. Nós vamos a um nível mais profundo dentro da pasta do fornecedor, pois resolvemos conflitos de nomenclatura durante o evento autoload. Também chamamos a classe boostrap de plugins E.g. Faq.php na prioridade 10 dentro do gancho 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

Provavelmente renomeie a pasta lib para vendors e mova todas as pastas públicas (css, imagens, js, idiomas) para uma pasta chamada public na próxima versão.

    
por rofflox 13.04.2012 / 10:51
5

Como muitos dos que já responderam, realmente depende do que o plug-in deve fazer, mas aqui está minha estrutura básica:

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
    
por Bainternet 13.04.2012 / 18:43
4

Eu sou parcial ao layout de plug-in a seguir, mas ele geralmente muda dependendo de quais são os requisitos do 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 

Eu ainda tenho que criar um plugin para WordPress que exija uma arquitetura de estilo MVC, mas se eu fosse fazer isso eu colocaria em um diretório MVC separado, que por si só contém views / controllers / models.

    
por mystline 13.04.2012 / 08:02
4

Minha lógica, quanto maior o plugin, mais estrutura eu uso.
Para plugins grandes eu costumo usar MVC.
Eu uso isso como ponto de partida e pulo o que não é necessário.

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
    
por janw 18.04.2012 / 14:20
3

Todos os meus plugins seguem essa estrutura, o que parece ser muito parecido com o que a maioria dos outros desenvolvedores estão fazendo:

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 é geralmente uma classe que carrega todos os arquivos necessários do core / folder. Na maioria das vezes, no gancho init ou plugins_loaded.

Eu costumava prefixar todos os meus arquivos também, mas como o @kaiser observou acima, é realmente redundante e recentemente decidi removê-lo de qualquer plug-in futuro.

A biblioteca / pasta contém todas as bibliotecas auxiliares externas das quais o plug-in pode depender.

Dependendo do plugin, pode haver também um arquivo uninstall.php na raiz do plugin. Na maior parte do tempo, isso está sendo feito via register_uninstall_hook ().

Obviamente, alguns plugins podem não requerer nenhum arquivo ou modelo administrativo, etc, mas a estrutura acima funciona para mim. No final, você só precisa encontrar uma estrutura que funcione para você e, em seguida, fique com ela.

Eu também tenho um plugin inicial, baseado na estrutura acima que eu uso como ponto de partida para todos os meus plugins. Tudo o que eu preciso fazer é fazer uma busca / substituição por prefixos de função / classe e lá vou eu. Quando eu ainda estava prefixando meus arquivos, isso foi um passo extra que eu tive que fazer (e bem chato), mas agora eu só tenho que renomear a pasta do plugin e o arquivo principal do plugin.

    
por shabushabu 13.04.2012 / 12:28
1

Além disso, veja este grande clichê do widget do WP . Ele dá ótimas dicas de estruturas (mesmo que não haja uma classe nem pasta para modelos separados).

    
por Cedric 17.06.2013 / 10:42
0

Uma abordagem menos comum para estruturar os arquivos e diretórios de um plugin é a abordagem de tipo de arquivo. Vale a pena mencionar aqui por completo:

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

Cada diretório contém arquivos desse tipo apenas. Vale a pena notar que esta abordagem é insuficiente quando você tem muitos tipos de arquivos .png .gif .jpg que podem ser mais logicamente arquivados em um único diretório, images/ por exemplo.

    
por henrywright 08.11.2015 / 00:40