最近，在将我的网站从虚拟主机迁移到 VPS 服务器后，我遇到了一个棘手的 PHP 警告：
PHP Warning: Undefined array key "path" in /oddbbo.com/wp-includes/canonical.php on line 619这个警告反复出现在我的 Nginx 错误日志中，开始在网站前台也有显示，我重新导入两次数据库后，前台不显示，后台日志中还有。每当我在网站首页使用 WooCommerce 的产品筛选功能时就会触发，而在分类页面使用筛选功能则不会出现错误警告。
虽然网站前端没有显示任何问题，但服务器日志中大量的警告让我意识到必须彻底解决它。经过一系列的排查和尝试，我最终找到了一个可靠的解决方案。
问题根源：环境与代码的“不兼容”
我的网站是基于 WordPress 搭建的，网站首页被设置为产品归档页。当用户使用排序或分页功能时，URL 会变成这样：
https://oddbbo.com/?orderby=popularity
这个 URL 的特点是它没有路径，只有查询参数。
WordPress 的核心文件 canonical.php 负责处理 URL 的规范化。它期望 URL 结构中包含一个 path（路径）变量。然而，当它遇到像我网站首页这种没有路径的 URL 时，它试图访问一个不存在的 path 键，从而抛出 Undefined array key "path" 的警告。
这个问题在虚拟主机上没有出现，因为其服务器配置可能已经完美处理了这种边缘情况。但在我新配置的 VPS 环境中，这个问题就暴露了出来。
失败的尝试：为什么常规方法不起作用？
在找到最终解决方案之前，我尝试了多种基于 WordPress 最佳实践的方法，但它们都未能奏效：
- 修改
functions.php或创建 MU 插件：我尝试使用query_vars和wp_parse_url过滤器，在警告抛出前手动为 URL 添加path变量。尽管服务器日志确认了我的代码被执行了，但警告依然出现。这表明我的网站（可能因为主题或某些插件的特殊加载方式）在执行这些过滤器之前，就触发了canonical.php的报错。 - 修改 Nginx 配置：我排查了 Nginx 的配置文件，但发现它已经正确地将请求传递给了 WordPress，问题并非出在 Web 服务器层面。
所有常规的、非侵入性的方法都失败了。这让我意识到，这是一个必须通过修改核心代码才能解决的特殊问题。
最终解决方案：直接修改核心文件
既然标准的 WordPress 钩子无法在正确的时间点介入，我们唯一的选择就是直接在报错的地方修复代码。
警告：这个方法不被 WordPress 官方推荐，因为它会被未来的 WordPress 更新覆盖。但这是解决这个特定问题的最有效、最可靠的方法。
步骤 1: 备份文件
在进行任何修改前，请务必备份 /www/wwwroot/oddbbo.com/wp-includes/canonical.php 文件。
步骤 2: 定位并修改代码
用文本编辑器打开 canonical.php 文件。根据我的服务器日志，问题出现在第 619行左右。我找到了以下代码：
$redirect['path'] = preg_replace( '|/' . preg_quote( $wp_rewrite->index, '|' ) . '/?$|', '/', $redirect['path'] );
这是导致警告的罪魁祸首。因为它在没有 path 键的情况下，强行使用它。
步骤 3: 替换为修复代码
我用以下代码替换了报错的那一行：
// 如果没有 path（首页 + 查询参数常见），补成 '/'
if ( ! isset( $redirect['path'] ) ) {
$redirect['path'] = '/';
}
$redirect['path'] = preg_replace( '|/' . preg_quote( $wp_rewrite->index, '|' ) . '/?$|', '/',
$redirect['path'] );
这段代码的作用是在执行 preg_replace 之前，先检查 $redirect 数组中是否存在 path 键。如果不存在，就手动为其创建一个并赋值为 '/'，从而从根本上避免了 Undefined array key 的警告。
步骤 4: 保存并测试
保存文件后，我清除了服务器缓存并重新测试了网站。所有 PHP 警告都消失了。
使用 MU 插件的经验总结
- MU 插件适合修改 hook 返回值，但无法修改核心逻辑内部的数组访问
- 对于 canonical.php 这种在 hook 前就访问数组的逻辑，MU 插件只能作为“部分兜底”，无法完全消除 Warning
- 最终还是需要核心文件的
isset()或empty()检查
虽然 WordPress 插件和主题提供了极大的便利性，但在某些特殊配置下，它们可能会与核心代码产生意想不到的冲突。在所有常规方法都失败后，直接修改核心代码虽然是最后的选择，但也是最有效的杀手锏。
请记住，如果你使用这个方法，每次 WordPress 更新后，都需要重新应用这个修改。
