When I need to debug a WordPress quickly, I usually reach for this quick command:
wp plugin install query-monitor --activate
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw
wp config set SAVEQUERIES true --rawCode language: Bash (bash)Let’s take a quick look at what this does. First of all, it will install and activate query-monitor, which is an incredibly valuable tool when it comes to debugging. After that WP_DEBUG is enabled, and output will be written to the debug log but not displayed. You might want to display the errors on the front end, in which case you can simply change the command to true. Personally, I prefer using the log. As a last step we enable the saving of queries so we get a good look at what is going on.
If you just want to enable WP_DEBUG, you can run the following in a single line:
wp config set WP_DEBUG true --raw && wp config set WP_DEBUG_LOG true --raw && wp config set WP_DEBUG_DISPLAY false --rawCode language: Bash (bash)Both snippets can also be adjusted to your preference, for example to log debug information to a specific path so it’s less likely that someone reads what is going on, you do this by passing a path instead of the raw true argument.
Fatal errors
Some WP-CLI commands may fail if a plugin or theme triggers a fatal error during WordPress bootstrap. In those cases, –skip-themes and –skip-plugins can be very helpful.
Exposed log files
If you are comfortable using the command line, I would recommend not exposing the debug log via the server (nginx, apache, caddy, OpenLiteSpeed, etc), and either using something to parse the logs or simply read it out directly. This should be part of the security setup.
