这不是关于如何构建WordPress插件的问题。相反，如果有的话，什么指南可以应用于如何组合任何插件的文件体系结构。

其他一些编程语言或库具有组织目录和文件的受控方式。有时这很烦人，并且突显了PHP提供的自由，但是在另一方面，WordPress插件却以其作者确定的任何方式组合在一起。

没有正确的答案，但是我的希望是完善我和其他人构建插件的方式，使它们对其他开发人员更友好地进行剖析，更易于调试，更易于导航以及可能更高效。

最后一个问题：怎么办您认为是组织插件的最佳方法吗？

下面是一些示例结构，但绝不是详尽的列表。随时添加自己的建议。

假定的默认结构



/wp-content



/> /plugins



/my-plugin


my-plugin.php







模型视图控制器（MVC）方法



/wp-content


>
/plugins



/my-plugin



/controller


Controller.php



/model


Model.php



/view


view.php


my-plugin.php







MVC的三个部分：


模型与数据库交互，查询和保存数据，并包含逻辑。
控制器将包含模板标签。视图将使用的视图和功能。
视图负责显示由控制器构造的模型提供的数据。

组织通过类型化方法




/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插件样板

基于Github提供

基于插件API，编码标准和文档标准。



/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







组织松散的方法



/wp-content



/> /plugins



/my-plugin


css/
images/
js/
my-admin.php
/> my-class.php
my-template.php
my-widget.php
my-plugin.php










评论

这不是一个真正的问题，但是我不会结束投票，而是标记为将其成为社区Wiki。顺便说一句：我认为固定文件名没有任何意义。
谢谢，我还是希望这是社区Wiki。我认为以这种方式添加文件前缀也没有多大意义，但我已经看到了很多。
另一个观点：css /，images /和js /文件夹在语义上更正确的名称是styles /，images /和scripts /。

#1 楼

请注意，按照WP标准，插件都是“控制器”。

这是轻松实现此目的的一种方法-首先，定义一个加载模板的函数：

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


现在，如果插件使用小部件显示数据：

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

}


模板：

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

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

<?php endwhile; ?>


文件：

/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


将CSS，JS，图像放在何处，或者如何设计用于钩子的容器并不重要。我猜这是个人喜好。

#2 楼

这取决于插件。这是我几乎所有插件的基本结构：

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


这将放在lib文件夹中。

如果特别的话复杂的插件，具有很多管理区域功能，我将添加一个admin文件夹以包含所有这些PHP文件。如果插件的功能类似于替换包含的主题文件，则可能还有一个template或theme文件夹。

因此，目录结构可能如下所示：

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


评论

您还会在/ admin文件夹中包含管理员的css和js文件吗？因此在/ admin中有另一个/ css和/ js？

–urok93
2012年8月12日7:52

#3 楼

恕我直言，最简单，最强大，最易维护的方法是使用MVC结构，而WP MVC旨在使编写MVC插件非常容易（不过，我有些偏见...）。借助WP MVC，您只需创建模型，视图和控制器，其他所有操作都在后台进行。

可以为公共和管理部分创建单独的控制器和视图，并且整个框架都利用了WordPress的许多本机功能。文件结构和大部分功能与最流行的MVC框架（Rails，CakePHP等）完全相同。

更多信息和教程可以在这里找到：


插件页面
教程


#4 楼

我们混合使用了所有方法。首先，我们在插件中使用Zend Framework 1.11，因此由于自动加载机制，我们不得不对类文件使用类似的结构。

我们核心插件的结构（ 

webeo-core/
    css/
    images/
    js/
    languages/
    lib/
        Webeo/
            Core.php
        Zend/
            /** ZF files **/
        Loader.php
    views/
    readme.txt
    uninstall.php
    webeo-core.php



WordPress调用了插件根文件夹中的webeo-core.php文件。
在此文件中，我们将设置PHP包含路径并注册插件的激活和停用钩子。
我们在该文件中还有一个Webeo_CoreLoader类，该类设置一些插件常量，初始化类autoloader和调用Core.php文件夹中的lib/Webeo类的设置方法。它在plugins_loaded动作钩子上运行，优先级为9。
Core.php类是我们的插件引导文件。该名称基于插件名称。

如您所见，我们所有供应商软件包（lib，Webeo）的Zend文件夹中都有一个子目录。供应商内部的所有子包均由模块本身构成。对于新的Mail Settings管理表单，我们将具有以下结构：

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


我们的子插件具有相同的结构，但有一个例外。由于在自动加载事件期间解决了命名冲突，因此我们在供应商文件夹内更深入。我们还将在E.g. Faq.php钩子内优先级为10的插件称为boostrap类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


我可能会将lib文件夹重命名为vendors并移动所有公用文件夹（图像，js，语言）添加到下一版本中名为public的文件夹。

#5 楼

就像这里已经回答的许多问题一样，这实际上取决于插件的功能，但这是我的基本结构：

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


#6 楼

我只喜欢以下插件布局，但是它通常会根据插件要求而改变。

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


我还没有创建需要MVC样式的WordPress插件。体系结构，但是如果要执行此操作，我将使用单独的MVC目录对其进行布局，该目录本身包含视图/控制器/模型。

#7 楼

我的逻辑是，插件越大，我使用的结构就越多。
对于大型插件，我倾向于使用MVC。
我以此为起点，跳过不需要的内容。

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


#8 楼

我所有的插件都遵循这种结构，这似乎与大多数其他开发人员的工作非常相似：

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通常是一个加载类核心/文件夹中的所有必需文件。

我也经常给所有文件加上前缀，但正如上面@kaiser所指出的那样，它确实是多余的，我最近决定将其从将来的任何插件中删除。 。

library /文件夹包含该插件可能依赖的所有外部帮助程序库。

取决于插件，插件根目录中可能会有一个uninstall.php文件。也一样不过，大多数情况下，这是通过register_uninstall_hook（）处理的。

显然，某些插件可能不需要任何管理文件或模板等，但是上面的结构对我有用。最后，您只需要找到一个适合您的结构，然后坚持使用即可。

基于上面的结构，我也有一个入门插件，我将其用作所有我的起点插件。然后，我要做的就是搜索/替换函数/类前缀，然后关闭。当我仍在给文件加上前缀时，这是我需要做的一个额外步骤（这很烦人），但是现在我只需要重命名插件文件夹和主插件文件即可。

#9 楼

另外，请参见此出色的WP小部件样板。它为结构提供了很好的提示（即使没有类也没有单独模型的文件夹）。

#10 楼

构建插件文件和目录的一种较不常用的方法是文件类型方法。出于完整性考虑，这里值得一提：

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


每个目录仅包含该类型的文件。值得注意的是，当您有许多文件类型.png .gif .jpg可能更合乎逻辑地存储在单个目录（例如images/）下时，此方法就不够用了。