README

目标是规范WP插件结构，以避免脏代码，进而避免错误和安全漏洞。

功能

更好的结构意味着更好的代码

本包专注于插件代码的结构方式。默认情况下，由WP Plugin Maker CLI生成（并处理）的插件看起来像这样

my-plugin
|-- my-plugin.php
|-- require-admin.php
|-- require-cli.php
|-- require-front.php
|-- require-rest.php
|-- src
|   |-- Admin
|   |   |-- (classes)
|   |-- All
|   |   |-- (classes)
|   |-- CLI
|   |   |-- (classes)
|   |-- Front
|   |   |-- (classes)
|   |-- Rest
|   |   |-- (classes)
|   |-- Plugin.php
|   vendor
|   |-- (packages)

它将你通过插件提供的功能分为五部分：管理员、CLI、前端、REST和全部。每个文件夹都代表了自身，而"全部"涉及将出现在每个部分中的代码。

我应该把什么放在这些文件夹里？基本上，你的WP过滤器和动作声明。

等等，我的插件里不仅有过滤器和动作...虽然定义了五个具有特定行为的文件夹/命名空间，但你也可以添加任何其他文件夹来放置你的其他类（模型等）。

自动过滤器和动作

好的，文件结构很棒，但是这里的“require”文件是什么？正如你可能注意到的，这些文件是从之前提到的部分命名的——除了“全部”。

当使用“action_”或“filter_”前缀定义类方法时，意味着你分别创建了一个动作或一个过滤器。

它是如何工作的？我应该只编写代码吗？虽然这个库看起来很神奇，但它并不是。您将需要使用WP Plugin Maker CLI来自动化您的过滤器/动作注册，通过监视您的插件文件夹。因此，当发生变化时，您的“require”文件将刷新。

您的控制器将通过反射进行解析，并将每个相关的动作缓存起来。

这是一个示例控制器（src/Admin/Test_Controller.php）

<?php 
namespace My_Plugin\Admin;

class Test_Controller {

    public static function action_init() {
        // Put your logic here
    }
    
}

这是生成的“require-admin”文件

<?php return array (
  'My_Plugin\\Admin\\Test_Controller' => 
  array (
    'actions' => 
    array (
      0 => 
      array (
        'name' => 'init',
        'callback' => 'My_Plugin\\Admin\\Test_Controller::action_init',
        'priority' => 10,
        'args_count' => 0,
      ),
    ),
  ),
);

因此，当在WP后台时，该文件将被包含，并注册所有定义的动作。

在标准WP插件中，您将不得不为每个定义的动作/过滤器编写

<?php
add_action('init', 'My_Plugin\\Admin\\Test_Controller::action_init', 10, 0);

这不是面向对象思考的方式。

等等。我想改变优先级！！！通过在方法上使用docblocks，您可以改变优先级

<?php
/**
 * @priority(0)
 */
public static function action_init() {}

所有元数据的文档将很快提供。

那么“args_count”参数是什么？当方法被解析时，如果它需要参数，“args_count”将是方法需要的参数数量。节省时间。

如何安装

如果您使用WP Plugin Maker CLI，只需创建一个新的插件。如果不（但不推荐），请转到您的插件根目录，然后像任何其他Composer包一样

composer require laegel/wp-plugin-maker

如果您真的想将此包添加到您的插件中但需要一些帮助，请给我发消息。

注意

这个库使用命名空间。为什么使用命名空间？因为正如您不会清理一个不整洁的房间一样，如果您不组织好代码，就不会写出干净的代码（抱歉使用比喻）。PHP命名空间是WordPress插件开发者应该真的思考的解决方案。不再有“function_exists”，不再有“namespace_function_which_does_something”名称；
使用 WP Plugin Maker CLI 生成的插件是 "Composer 兼容"。如果您想添加库，只需这样做。插件以 PSR-4 兼容的方式结构化，因此，您编写的类将自动通过 Composer 自动加载器加载，您实例化的库也将自动加载；
您可以将源文件与资产或模板文件分开，以提高代码的可读性。

有任何建议？问题？需要设置帮助？请联系我！

我的电子邮件地址显示在我的个人信息中。

有任何问题吗？

提交一个工单，我会尽快尝试回答。

laegel / wp-plugin-maker

维护者

详细信息