以下是一些最佳实践，可帮助您组织代码，使其与WordPress核心和其他WordPress插件配合使用。

避免命名冲突

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

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

 

程序编码方法

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

 

为一切添加前缀

所有全局可访问的代码都应以唯一标识符为前缀。前缀可防止其他插件覆盖您的变量并意外调用您的函数和类。它还将阻止您这样做。

为了防止与其他插件冲突，您的前缀长度应至少为 5 个字母。您应该避免使用常见的英语单词，而是为您的插件选择独特的内容。

应添加前缀的代码包括：

  • 函数（除非已命名）
  • 类、接口和特征（除非已命名）
  • 命名空间
  • 全局变量
  • 选项和瞬态

 

检查现有实现

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

  • 变量：isset() (包括数组、对象等）
  • 函数： function_exists()
  • 类：class_exists()
  • 常量： defined()

例

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

 

文件组织

插件目录的根级别应包含您的文件，也可以选择包含卸载.php文件。所有其他文件应尽可能组织到子文件夹中。plugin-name.php

 

文件夹结构

清晰的文件夹结构可帮助您和处理插件的其他人将类似的文件放在一起。

下面是一个示例文件夹结构供参考：

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

 

插件架构

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

对于与 WordPress 核心、主题或其他插件交互有限的小型单一用途插件，工程复杂类几乎没有什么好处;除非您知道该插件稍后会大大扩展。

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

 

条件加载

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

例如：

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

 

避免直接文件访问

作为安全预防措施，如果未定义全局，最好禁止访问。这仅适用于包含类或函数定义之外的代码的文件，例如主插件文件。ABSPATH

您可以通过在文件顶部包含以下代码来实现这一点：

if ( ! defined( 'ABSPATH' ) ) {
	exit; // Exit if accessed directly
}

 

架构模式

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

 

架构模式解释

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

 

样板起点

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

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

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

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