虽然 WordPress 内置的调试选项应该能满足大部分需求，但也有一些插件可以帮助你调试代码。
你可以在 WordPress 插件目录中搜索“debug”或“debugging”来找到这些插件。
其中最受欢迎的两个选项是 Debug Bar 和 Query Monitor。
Debug Bar 是一个由 WordPress 开发者社区构建和维护的插件。它在管理栏中添加了一个调试菜单，显示查询、缓存和其他有用的调试信息。
当启用 WP_DEBUG 常量时，它还会跟踪 PHP 警告和通知，使其更容易被发现；当启用 SAVEQUERIES 时，MySQL 查询会被跟踪并显示。
另一个选项是 Query Monitor，它也在管理栏中添加了一个调试菜单，并显示当前页面请求的相关信息。
Query Monitor 支持调试许多内容，包括数据库查询、PHP 错误、钩子和动作、区块编辑器区块、已排队的脚本和样式表、HTTP API 调用等。
这两个插件都是调试 WordPress 代码的绝佳选择，可以帮助你更轻松地追踪问题。
在 JavaScript 开发过程中，在代码的不同位置进行调试以了解运行情况会非常有帮助。
我们来看看几种检查 JavaScript 代码状态的方法。
调试 PHP 和 JavaScript 的主要区别之一在于，PHP 是一种服务端语言，因此你可以将消息记录到服务器上的文件中。
而 JavaScript 是一种客户端语言，因此你不能像 PHP 那样轻松地将消息记录到文件中。
幸运的是，我们可以使用浏览器的开发者工具（特别是控制台选项卡）来检查 JavaScript 代码的状态。
大多数现代浏览器都内置了开发者工具，允许你检查和调试网页元素。
根据你使用的浏览器和操作系统，通常可以通过按下特定键来打开开发者工具，例如 F12、Ctrl+Shift+I 或 Cmd+Option+I。
如果你不确定如何在浏览器中打开开发者工具，可以在 MDN Web Docs 网站上找到便捷的说明，路径为：指南 > 常见问题 > 工具与设置 > 什么是浏览器开发者工具？。
[注意：引导用户完成导航路径，找到该页面]
打开开发者工具后，切换到“控制台”选项卡，页面上的所有错误都会记录在这里。
同时，你也可以在这里从 JavaScript 代码中记录消息，以帮助调试。
console 对象允许你将消息记录到浏览器的控制台。它提供了多种方法，用于记录不同类型的消息。
以下是一些最常用的方法：
console.log() 方法是最常用的，因为它几乎可以记录任何内容到控制台。你可以向它传递各种数据类型，例如字符串、数字、数组或对象。
下面是一个将简单字符串变量记录到控制台的示例。
(function() {
let hello = 'Hello, World!';
console.log(hello)
})(); 如果你打开开发者工具并选择“控制台”选项卡，变量的内容就会被记录到控制台中。
控制台输出还包含一个指向源文件中代码位置的链接，这有助于追踪消息是从哪里记录的。
你还可以记录更复杂的数据类型，例如数组或对象。
(function() {
let fruits = [ 'apple', 'banana', 'orange' ];
console.log( fruits );
let person = {
firstName: "Jane",
lastName: "Smith",
age: 30,
eyeColor: "brown"
}
console.log( person );
})();在控制台中查看时，你会看到数组和对象按预期被记录。你还可以展开数组或对象以查看其属性，以及该数据类型可用的任何 JavaScript 方法。
还有许多其他方法可用于将消息记录到控制台，例如 console.error()、console.warn() 和 console.info()。
其中一个最被低估的方法是 console.table()，它可以将数组或对象以表格形式记录，使其更易于阅读。
(function() {
let people = [
{ name: 'Jane', age: 30 },
{ name: 'John', age: 40 },
{ name: 'Alice', age: 25 }
];
console.table( people );
})();当你有一个对象数组，并且希望以更易读的格式查看数据时，这个方法尤其有用。
要了解更多关于浏览器 console 对象及其方法的信息，请务必访问 MDN Web Docs 页面。该页面包含了所有 console 方法的完整列表以及有用的示例。
在调试 PHP 代码时，检查代码在特定时间点的状态会很有帮助。这可以帮助你理解代码中正在发生的事情，并识别可能导致问题的任何错误。
让我们看看一些使用内置 PHP 函数检查 PHP 代码状态的方法。
error_log() 记录消息正如在关于内置 WordPress 调试选项的课程中所讨论的，你可以使用 error_log() 函数将消息记录到 WordPress 的 debug.log 文件中。
这对于调试目的非常有用，因为它允许你查看代码中正在发生的事情，而无需在屏幕上显示。
error_log() 函数并非 WordPress 特有，它是一个 PHP 函数，你可以在任何 PHP 代码中使用它，将消息记录到服务器上配置的 PHP 错误日志文件中。
但是，一旦你在 wp-config.php 文件中启用了 WordPress 特定的调试选项，传递给 error_log() 的任何内容都将被记录到 WordPress 的 debug.log 文件中。
<?php
error_log( $some_variable );
?>这会将 $some_variable 的值记录到 debug.log 文件中，这样你就可以看到它在代码中该点的内容。
使用 error_log() 的好处是，它允许你将消息记录到文件，而无需在屏幕上显示。如果你在屏幕上显示它们，尤其是在生产环境中，你可能会面临向用户暴露敏感信息的风险。
有时，在日志文件中查看输出也比在屏幕上搜索一长串输出更快。
print_r()另一个用于检查 PHP 代码状态的有用函数是 print_r()。此函数以人类可读的格式输出变量、数组或对象的值，以便你可以查看其内容。
看看这个 PHP 代码示例。
<?php
$some_array = array(
'name' => 'John',
'age' => 30,
'city' => 'New York'
);
print_r( $some_array );
?>这段代码将在屏幕上输出以下内容：
Array
(
[name] => John
[age] => 30
[city] => New York
)开发者通常会将 print_r() 包裹在 <pre> 标签中，以使输出更易于阅读。
<pre>
<?php print_r( $some_array ); ?>
</pre>这将在屏幕上输出以下内容：
Array
(
[name] => John
[age] => 30
[city] => New York
)请注意，默认情况下 print_r() 会输出变量的值，但不会返回它。如果你想将 print_r() 的输出与 error_log() 一起使用，需要将第二个参数设置为 true。
<?php
error_log( print_r( $some_array, true ) );
?>这会将 print_r 调用的输出记录到 debug.log 文件中，这样你就可以看到 $some_array 在代码中该点的内容。
var_dump()var_dump() 函数是另一个用于检查 PHP 代码状态的有用函数。此函数以人类可读的格式输出变量、数组或对象的值，同时提供关于变量类型和长度的额外信息。
看看这个 PHP 代码示例。
<?php
$some_array = array(
'name' => 'John',
'age' => 30,
'city' => 'New York'
);
var_dump( $some_array );
?>这段代码将在屏幕上输出以下内容：
array(3) {
["name"]=>
string(4) "John"
["age"]=>
int(30)
["city"]=>
string(8) "New York"
}请注意，var_dump() 会输出变量的值，以及关于变量类型和长度的额外信息。这对于调试目的非常有用，因为它提供了比 print_r() 更详细的变量信息。
与 print_r() 不同，var_dump() 没有将输出返回给变量的选项，因此你不能直接将其与 error_log() 一起使用。
但是，你可以使用一种称为输出缓冲的技术来捕获 var_dump() 的输出，然后将其记录到 debug.log 文件中。
<?php
ob_start();
var_dump( $some_array );
$output = ob_get_clean();
error_log( $output );
?>开发者通常会将这种代码用于一个特殊的日志记录函数，以便能够同时使用 var_dump 和 error_log。
<?php
if ( ! function_exists( 'var_log' ) ) {
function var_log( $log ) {
ob_start();
var_dump( $log );
$output = ob_get_clean();
error_log( $output );
}
}
?>有关本课程中提到的函数的更多信息，请查看 PHP 文档中的以下页面：
PHP var_dump() 函数
PHP error_log() 函数
PHP print_r() 函数
随着你对 WordPress 开发越来越熟练，你会发现有时事情并不像预期那样工作，你需要找出原因。
在本课中，你将了解 WordPress 内置的调试选项。
首先，你将学习调试代码的含义。然后，你将了解默认 WordPress 安装中可用的一些内置调试选项，以及如何启用和使用它们。
调试是查找并修复代码中错误的过程。
由于 WordPress 的两种主要编程语言是 PHP 和 JavaScript，你需要能够调试这两种语言。
对于在浏览器中执行的 JavaScript 代码，使用 console.log() 向浏览器控制台写入消息以进行测试和调试是相当直接的。
另一方面，PHP 在服务器上执行，因此你需要一些方法来找出问题发生时的情况。
有一些第三方工具可用于高级调试，例如 Xdebug 或 Ray。
然而，就本课而言，你将学习 WordPress 特有的选项，并且不需要额外的软件。
在 WordPress 中，在任何 WordPress 请求生命周期内，都会运行 wp_debug_mode() 函数来设置调试环境。此函数位于 wp-includes/load.php 文件中。
如果你查看这段代码，你会发现如果 WP_DEBUG 常量设置为 true，那么它会将 PHP 错误报告级别设置为 E_ALL，这意味着开启所有错误报告。
此外，如果 WP_DEBUG_DISPLAY 设置为 true，那么它会将 PHP 的 display_errors 设置设为 1，这意味着在屏幕上显示这些错误。
最后，如果 WP_DEBUG_LOG 设置为 true，那么它会将 PHP 的 error_log 设置设为 wp-content/debug.log 文件。也可以配置自定义的 debug.log 文件位置，而不是默认位置。
如果启用了此日志文件，它会将 PHP 的 log_errors 设置设为 1，并将 error_log 设置设为日志文件的路径，这意味着所有错误都将记录到此文件中。
利用这些知识，你可以配置 wp-config.php 文件来启用 WordPress 调试。
要启用调试，请打开 wp-config.php 文件并向下滚动到设置 WP_DEBUG 常量的位置。
你可以将该部分更新为如下所示：
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );此配置将：
wp-content/debug.log 文件根据你的个人偏好，你可以启用屏幕上显示错误，但这可能导致错误被忽略或覆盖屏幕上的其他重要内容，这并不理想。
此外，如果你曾经在生产站点上调试问题，你不希望将错误显示在屏幕上，因为这可能导致敏感信息向用户显示。
为了实际查看效果，让我们看一个例子。
假设你开发了一个包含以下代码的插件：
<?php
/**
* Plugin Name: WP Learn Debugging
* Plugin Description: A plugin to learn about debugging in WordPress.
* Plugin URI: https://learn.wordpress.org
* Version: 1.0.0
*/
/**
* Set up the required form submissions table
*/
register_activation_hook( __FILE__, 'wp_learn_setup_table' );
function wp_learn_setup_table() {
global $wpdb;
$table_name = $wpdb->prefix . 'form_submissions';
$sql = "CREATE TABLE $table_name (
id mediumint(9) NOT NULL AUTO_INCREMENT,
name varchar (100) NOT NULL,
email varchar (100) NOT NULL,
PRIMARY KEY (id)
)";
require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );
dbDelta( $sql );
}
/**
* Register the REST API GET route
*/
add_action( 'init', 'wp_learn_register_routes' );
function wp_learn_register_routes() {
register_rest_route(
'wp-learn-form-submissions-api/v1',
'/form-submissions/',
array(
'methods' => 'GET',
'callback' => 'wp_learn_get_form_submissions',
'permission_callback' => '__return_true'
)
);
}
/**
* Fetch the form submissions for the REST API GET Route
*
* @return array|object|stdClass[]|null
*/
function wp_learn_get_form_submissions() {
global $wpdb;
$table_name = $wpdb->prefix . 'form_submission';
$results = $wpdb->get_results( "SELECT * FROM $table_name" );
return $results;
}这个插件在激活时会在数据库中创建一个表单提交表，然后注册一个 REST API GET 路由来从数据库中获取表单提交。
出于测试目的，你手动在 form_submissions 表中插入了几条记录。
但是，如果你访问 REST API GET 路由，你看不到任何表单提交，因此你需要开始查找代码中的错误。
只需启用调试，代码中的任何错误都会自动记录到 wp-content/debug.log 文件中。所以如果你查看一下，你会看到一些错误已被记录。
[02-Jun-2023 13:51:41 UTC] PHP Notice: Function register_rest_route was called <strong>incorrectly</strong>. REST API routes must be registered on the <code>rest_api_init action. Please see Debugging in WordPress for more information. (This message was added in version 5.1.0.) in /home/ubuntu/wp-local-env/sites/learnpress/wp-includes/functions.php on line 5865在这种情况下，报告了两个错误。首先是由 WordPress 触发的 PHP 通知，这是由于将 wp_learn_register_routes 函数挂载到了错误的操作上。其次是与用于获取表单提交的数据库查询相关的错误。
看起来它查询的是 form_submission 表，而不是 form_submissions 表。
一旦你修复了这些错误，并访问 REST API GET 路由，你就会看到表单提交被返回了。
除了将错误记录到 debug.log 文件之外，你还可以使用 PHP 的 error_log 函数将消息或变量记录到 debug.log 文件。
此函数接受一个字符串参数。
例如，如果你想将正在运行的 SQL 查询记录到 debug.log 文件中，可以使用以下代码：
error_log( $wpdb->last_query );如果你刷新请求并查看 debug.log 文件，就会看到查询被记录到该文件中。
[02-Jun-2023 13:55:35 UTC] SELECT * FROM wp_form_submissions除了记录最后一条查询，你还可以记录 WordPress 请求生命周期中运行的所有查询。
要实现这一点，你可以在 wp-config.php 文件中启用 SAVEQUERIES 常量。
define( 'SAVEQUERIES', true );启用此常量后，你可以使用以下代码记录所有查询：
error_log( print_r( $wpdb->queries, true ) );这段代码结合使用了 error_log() 函数和 PHP 的 print_r() 函数，将 $wpdb->queries 数组记录到 debug.log 文件中。
该数组包含了 WordPress 请求生命周期中运行的所有查询，并且仅在启用 SAVEQUERIES 常量时才可用。
有关 WordPress 调试的更多信息，请查看 WordPress 开发者文档中高级管理区域的“WordPress 调试”部分。