最佳做法

以下是一些最佳做法来帮助组织您的代码,使其与WordPress核心和其他WordPress插件一起工作良好。

避免命名冲突

当您的插件与变量,函数或类作为另一个插件使用相同的名称时,会发生命名冲突。

幸运的是,您可以通过使用以下方法避免命名冲突。

程序

默认情况下,所有变量,函数和类都在全局命名空间中定义,这意味着插件可以覆盖由另一个插件设置的变量,函数和类,反之亦然。 在函数或类中定义的变量不受此影响。

前缀一切

所有变量,函数和类应以唯一标识符为前缀。 前缀可防止其他插件覆盖变量,并意外调用您的函数和类。 它也会阻止你做同样的事情。

检查现有的实现

PHP提供了许多函数来验证变量,函数,类和常量的存在。 如果实体存在,所有这些将返回true。

  • Variables: isset() (includes arrays, objects, etc.)
  • Functions: function_exists()
  • Classes: class_exists()
  • Constants: defined()

示例

<?php
//Create a function called "wporg_init" if it doesn't already exist
if ( !function_exists( 'wporg_init' ) ) {
    function wporg_init() {
        register_setting( 'wporg_settings', 'wporg_option_foo' );
    }
}
 
//Create a function called "wporg_get_foo" if it doesn't already exist
if ( !function_exists( 'wporg_get_foo' ) ) {
    function wporg_get_foo() {
        return get_option( 'wporg_option_foo' );
    }
}

OOP

解决命名冲突问题的一个更简单的方法是使用一个类来代替你的插件

您仍然需要注意检查您想要的类的名称是否已经被使用,其余的将由PHP来处理。

示例

<?php
if ( !class_exists( 'WPOrg_Plugin' ) ) {
    class WPOrg_Plugin
    {
        public static function init() {
            register_setting( 'wporg_settings', 'wporg_option_foo' );
        }
 
        public static function get_foo() {
            return get_option( 'wporg_option_foo' );
        }
    }
 
    WPOrg_Plugin::init();
    WPOrg_Plugin::get_foo();
}

文件组织

您的插件目录的根级别应该包含你的plugin-name.php文件,并且可以选择你的uninstall.php文件。 所有其他文件应尽可能地组织成子文件夹。

文件夹结构

一个清晰的文件夹结构可以帮助您和其他在您的插件上工作的人保持类似的文件

以下是一个示例文件夹结构供参考:

/plugin-name
     plugin-name.php
     uninstall.php
     /languages
     /includes
     /admin
          /js
          /css
          /images
     /public
          /js
          /css
          /images

插件架构

您为插件选择的架构或代码组织可能取决于您的插件的大小。

对于与WordPress核心,主题或其他插件进行有限交互的小型单用途插件,在复杂类工程中几乎没有什么好处; 除非你知道这个插件会在以后扩大很多。

对于具有大量代码的大型插件,请注意课程。 独立的样式和脚本文件,甚至与构建相关的文件。 这将有助于代码组织和长期维护的插件。

有条件加载

将管理员代码与公共代码分开是有帮助的。 使用条件 is_admin()

<?php
if ( is_admin() ) {
    // we are in admin mode
    require_once( dirname( __FILE__ ) . '/admin/plugin-name-admin.php' );
}

建筑模式

虽然有许多可能的架构模式,但它们可以广泛地分为三个变体:

  • 单个插件文件,包含功能
  • 单个插件文件,包含类,实例化对象和可选功能
  • 主要插件文件,然后一个或多个类文件

架构模式解释

上述代码组织的更复杂的具体实现已经写成教程和幻灯片:

  • 斜杠 - 单身人士,装载机,动作,屏幕,处理程序
  • MVC启发式WordPress插件开发方法
  • 在WordPress插件中实现MVC模式

锅炉起点

而不是从头开始为每个你写的新插件,你可能想从一个样板开始。 使用样板的一个优点是在您自己的插件之间保持一致。 如果您使用他们已经熟悉的样板,其他人员也可以轻松地为其他人员提供代码。

这些也作为不同但可比较的架构的进一步示例。

  • WordPress插件Boilerplate:WordPress插件开发的基础,旨在为构建您的插件提供清晰一致的指南。
  • WordPress插件引导:使用Grunt,Compass,Git和SVN开发WordPress插件的基本引导。
  • WP骨架插件:骷髅插件,专注于单元测试和使用作曲家进行开发。

一般在GitHub上搜索WordPress插件当然,您可以采取这些和其他方面的不同方面来创建自己的自定义样板。

下一节:如果您的插件允许用户在管理员或公共方面提交数据,则应检查用户功能。