WordPress升级至6.2后Make.com新模块REST API返回404求助

问题本质 #

报错rest_no_route（请求的URL和方法找不到匹配路由），说明Make.com新模块依赖的REST API路由在WP 6.2里要么不存在，要么访问受阻。旧Legacy模块能部分工作，证明基础REST API通路没问题，问题出在新模块的路由适配或权限上。

逐一排查步骤 #

• 先确认REST API基础是否正常：直接访问你的WP站点/wp-json/，能返回JSON格式的路由列表才算正常。如果不行，先去「设置→固定链接」，切换到非朴素模式（比如“文章名”）然后保存，这是REST API运行的基础前提。
• 更新Make.com插件到最新版：WP 6.2对REST API做了一些细节调整，旧版Make插件可能没适配。去WP后台插件页检查更新，或者直接重新下载安装官方最新版的Make.com插件。
• 排查Content Studio的影响：哪怕只留了两个插件，Content Studio也可能修改了REST API的路由规则或权限。临时禁用它，测试新模块能不能正常工作。如果恢复了，就去Content Studio官方找适配WP 6.2的版本，或者调整它的API相关设置。
• 检查重写规则和权限：
  • 如果你用Apache，确认mod_rewrite模块已经启用；用Nginx的话，检查配置文件里的URL重写规则是否符合WP官方要求。
  • 确认Make.com用的授权账号（不管是应用密码还是OAuth用户）有edit_posts及以上权限，而且没有被之前禁用的插件留下的权限限制影响。
• 开调试日志抓细节：在wp-config.php里加几行代码开启调试：

  define('WP_DEBUG', true);
  define('WP_DEBUG_LOG', true);
  define('WP_DEBUG_DISPLAY', false);
  

  触发Make新模块的错误后，去wp-content/debug.log里找具体的路由匹配失败原因，日志会告诉你到底是哪个路由找不到，或者有没有权限问题。
• 对比新旧模块的API请求：用浏览器F12的网络面板，分别抓旧Legacy模块和新模块的API请求，对比它们的请求URL、HTTP方法、请求头。大概率新模块请求的路由在WP 6.2里被改了，你可以对照/wp-json/的路由列表确认。

临时 workaround #

如果以上都没解决，先凑活用Legacy模块，同时给Make.com官方提工单，把WP版本、报错信息、调试日志都附上，让他们尽快出适配6.2的更新。

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