Question

我正在使用WordPress REST API，并且在我设置的主插件文件中：

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

我有一些奇怪的行为。例如在函数/端点中，我有类似的东西：

function test($request){
    $request['id'] <- this works fine here

    but if I add another function like this I get a silent error

    $validID = check_id($request['id']);
}

因此，当我执行此操作时，从端点返回的内容为空，并且出现此错误：

has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

现在，如果我将error_reporting设置为：

error_reporting(E_ERROR | E_WARNING | E_PARSE);

我的端点工作正常。不知道这里发生了什么。我没有任何php错误日志，这使解决问题变得异常困难。所以我不应该使用E_ALL吗？

我还通过省略半冒号来测试了终点。除了现在对error_reporting（E_ALL）和error_reporting（E_ERROR | E_WARNING | E_PARSE）都得到空响应外，我得到的结果相同。我很想获得某种日志/返回值来告诉我什么地方出了错。

Answer 1

不幸的是，许多WordPress代码是在未启用WP_DEBUG的情况下编写的，这意味着没有E_ALL级别。结果，它往往充满了开发人员看不到且不愿去纠正的通知和过时问题。

因此提高错误报告率通常会触发与您自己的代码完全不相关的问题。

由于当前的问题是缺少明显的错误消息/日志，因此您应该尝试使用WP_DEBUG_DISPLAY和WP_DEBUG_LOG配置，以查看是否有帮助。

通常，最好使用常量来集中控制WP的错误处理。当扩展程序开始对此感到混乱时，那就……一团糟。：）

您可以尝试的另一件事是专用的错误处理程序。我制作并使用了一个wps插件，该插件包装了WP上下文的whoops处理程序。对于API错误，它会尝试覆盖输出并为发生的情况返回有意义的跟踪。

error_reporting（E_ALL）失败，没有日志或错误消息

1 个答案: