最佳实践

这里有一些最佳实践来帮助组织您的代码，以便它与 WordPress 核心和其他 WordPress 插件一起工作。

避免命名冲突

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

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

过程编码法

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

前缀一切

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

检查现有的实现

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

变量： isset() （包括数组、对象等）
函数： function_exists()
类： class_exists()
常量：已定义()

例子

// 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' );
    }
}

面向对象编程方法

解决命名冲突问题的更简单方法是为插件代码使用一个类。

您仍然需要注意检查您想要的类的名称是否已经被使用，但其余的将由 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文件（可选）。所有其他文件应尽可能组织到子文件夹中。

文件夹结构

清晰的文件夹结构可以帮助您和其他在您的插件上工作的人将相似的文件放在一起。

这是一个示例文件夹结构以供参考：

/插件名称插件名称.php 卸载.php /语言 /包括 /行政 /js /CSS /图片 /民众 /js /CSS /图片

插件架构

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

对于与 WordPress 核心、主题或其他插件交互有限的小型、单一用途的插件，设计复杂的类几乎没有什么好处；除非你知道这个插件以后会大大扩展。

对于包含大量代码的大型插件，从类开始。单独的样式和脚本文件，甚至与构建相关的文件。这将有助于插件的代码组织和长期维护。

条件加载

将您的管理代码与公共代码分开会很有帮助。使用条件是_管理员（）。您仍然必须执行能力检查，因为这并不表示用户已通过身份验证或具有管理员级别的访问权限。请参阅检查用户能力。

例如：

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

架构模式

虽然有许多可能的架构模式，但它们可以大致分为三种变体：

单个插件文件，包含函数
单个插件文件，包含类、实例化对象和可选函数
主插件文件，然后是一个或多个类文件

架构模式解释

以上代码组织中比较复杂的具体实现已经写成教程和幻灯片：

Slash——单例、加载程序、操作、屏幕、处理程序
在 WordPress 插件中实现 MVC 模式

样板起点

您可能希望从样板文件开始，而不是从头开始为您编写的每个新插件。使用样板的一个优点是在您自己的插件之间保持一致性。如果您使用他们已经熟悉的样板，样板还可以让其他人更容易地为您的代码做出贡献。

这些也可以作为不同但可比较的体系结构的进一步示例。

WordPress 插件样板：WordPress 插件开发的基础，旨在为构建您的插件提供清晰一致的指南。
WordPress 插件引导程序：使用 Grunt、Compass、GIT 和 SVN 开发 WordPress 插件的基本引导程序。
WP Skeleton Plugin：Skeleton 插件，专注于单元测试和使用 composer 进行开发。
WP CLI Scaffold : WP CLI 的 Scaffold 命令创建骨架插件，带有 CI 配置文件等选项

当然，您可以利用这些和其他方面的不同方面来创建您自己的自定义样板。