独立的 WordPress 后台？

Source: Dev.to

一切始于元数据

Milk Admin 本身依赖两个独立的数据库——一个用于内部配置，另一个用于管理外部数据。这种架构使它自然适合与外部系统（例如 WordPress 数据库）集成。

连接后，我就可以直接在面板中管理 WordPress 站点的表。从此出现了一个迫切需求：原生处理元数据关系。我查看了与我类似的最知名、最成熟的系统是如何处理的，发现通常并没有原生的系统。因此我编写了 hasMeta 方法，用来处理原生元数据关系。

$rule->table('#__users')
    ->id()
        ->hasMeta('nickname', UserMetaModel::class, 'user_id')
        ->hasMeta('city', UserMetaModel::class, 'user_id')
    ->string('name', 100)->required();

我还继承了 WordPress 的一些小约定：动态表前缀（#__）以及用于更高级自定义的 functions.php 文件。

当我向客户展示元数据功能时，他的反应非常热情。他要求演示一个与元数据无关的场景——验证我的后台面板是否能够处理 WordPress 的身份验证。

WordPress 身份验证钩子

我开发了一个插件，挂载到 WordPress 的 authenticate 过滤器，优先级为 30，以在标准检查之后进行拦截：

add_filter('authenticate', [$this, 'authenticate'], 30, 3);

该方法接收三个参数：$user（前置检查的结果）、$username 和 $password。如果条件需要，插件会通过 wp_remote_post 向我的后台面板端点发起 POST 请求：

$args = [
    'headers' => ['Content-Type' => 'application/json'],
    'timeout' => (int)$options['request_timeout'],
    'body'    => wp_json_encode([
        'username' => $username,
        'password' => $password,
    ]),
];

$response = wp_remote_post($endpoint, $args);

Milk Admin 中的公共 API 端点

在 Milk Admin 端，我创建了一个专用模块，公开一个用于凭证验证的端点：

#[ApiEndpoint('public-auth/check-credentials', 'POST')]

可以通过一次简单的调用访问它：

POST /public_html/api.php?page=public-auth/check-credentials
Content-Type: application/json

{
  "username": "user@example.com",
  "password": "password"
}

在本演示中，表仅包含 username 和 password，但并不限制在响应中加入角色、权限或个人资料等额外数据。

该插件设计为不干扰管理员，也不会在用户名或密码为空时阻断原生流程；在这些情况下，WordPress 将照常处理。

从一次元数据实验开始，最终演变成了可交互性的具体示例。我的后台面板并不取代 WordPress——它与 WordPress 并行工作：让创建扩展 WordPress 数据的管理面板变得轻松，同时也可以通过 API 良好集成。