wordpress插件开发流程梳理(二)插件最佳实践

wordpress插件开发流程梳理(二)插件最佳实践

开发插件的最佳实践

避免命名冲突

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

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

程序性

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

前缀一切

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

检查现有实现

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

  • 变量: isset() (包括数组,对象等)
  • 函数: function_exists()
  • 类: class_exists()
  • 常量:defined()

OOP面向对象

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

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

示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<?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();
}

目录结构:

1
2
3
4
5
6
7
8
9
10
11
12
13
/plugin-name
plugin-name.php //插件主文件,必须和文件夹名保持一致
uninstall.php //卸载插件时自动运行的脚本
/languages //国际化语言包
/includes //其他功能脚本
/admin
/js
/css
/images
/public
/js
/css
/images

条件加载

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

示例:

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

文件结构参考

参考模板

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

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

注:本篇,完全是由官方文档翻译而来,描述了一个好的插件的最佳实践。该用什么样的目录结构,什么时候该做一些权限的判定,甚至Github上提供了一些可参考的模板,以防我们的代码写出来像坨屎一样。我也希望自己写出来的插件,且不说功能如何,最起码不被喷This is shit .所以你看到,我们现在花一些功夫来从头梳理,流程。真正开发流程中遇到的问题,我会在后边的时候提到。

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×