跳转到主要内容

最佳实践

以下是一些帮助组织代码的最佳实践，使其能够与 WordPress 核心和其他 WordPress 插件一起良好运行。

避免命名冲突

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

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

程序编码方法

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

给所有东西加上前缀

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

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

应加前缀的代码包括：

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

检查现有实施

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

例子：

// 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文件。所有其他文件应尽可能组织到子文件夹中。

文件夹结构

清晰的文件夹结构可以帮助您和其他开发插件的人将相似的文件保存在一起。

以下是供参考的示例文件夹结构：

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

架构模式

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

架构模式解释

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

样板起点

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

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

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

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

无评论
回到顶部