Roots/Sage与WPML：wp-admin无法访问mu-plugins文件的问题排查

1. 异常URL结构的原因 #

正常WordPress后台菜单都通过admin.php?page=xxx的标准路由访问，这是WP核心机制——所有后台页面统一通过admin.php作为入口，通过page参数匹配并加载对应的插件/主题页面文件。

出现直接指向mu-plugin物理文件的URL（如wpml-string-translation/menu/string-translation.php），核心原因是：

• WPML字符串翻译插件在Roots/Bedrock的非标准WP目录结构下，菜单注册逻辑出现适配问题，未调用WP标准的add_submenu_page等函数生成正确路由URL，而是错误输出了插件文件的物理路径。
• Bedrock将WP核心放在wp目录、内容目录改为web/app的结构，干扰了WPML内部的URL生成逻辑，导致其无法正确识别WP后台基础URL，进而生成错误的直接文件路径。

2. 解决404与500错误的步骤 #

步骤1：确保mu-plugins正确加载 #

Bedrock默认只加载web/app/mu-plugins根目录下的PHP文件，子目录中的插件需要手动加载。若wpml-string-translation放在子目录中，创建web/app/mu-plugins/loader.php文件，内容如下：

<?php
// 加载wpml-string-translation子目录中的插件文件
foreach (glob(__DIR__ . '/wpml-string-translation/*.php') as $file) {
    require_once $file;
}

步骤2：修正WPML的菜单URL #

通过WP的admin_url过滤器，将异常的物理文件URL转换为标准的admin.php路由：

// 添加到主题的functions.php或自定义mu-plugin文件中
add_filter('admin_url', 'fix_wpml_st_menu_url', 10, 2);
function fix_wpml_st_menu_url($url, $path) {
    if (strpos($path, 'wpml-string-translation/menu/string-translation.php') !== false) {
        return admin_url('admin.php?page=wpml-string-translation/menu/string-translation.php');
    }
    return $url;
}

步骤3：避免直接访问物理文件 #

500错误的本质是直接访问插件文件时，WP全局环境未初始化，WPML_String_Translation类的实例无法被正确创建。必须通过标准的admin.php路由访问，才能保证WP完整加载所有依赖环境，避免这类致命错误。

步骤4：重置WPML菜单缓存 #

• 进入WP后台的「WPML -> 语言 -> 翻译管理」页面，重置菜单缓存；
• 或临时禁用再重新启用WPML字符串翻译插件，触发WP重新生成后台菜单路由。

内容的提问来源于stack exchange，提问作者Mnevis