WordPress Debugging Guide (2023) – Part 1

Roshan Chapagain
February 11, 2023
7 minutes min read
Debugging is an essential part of the development process, and WordPress is no exception. Whether you're working on a custom plugin, theme, or website, you're bound to run into issues that need to be resolved. The first part of this blog series will explore the codex recommendation and WordPress functions for debugging. The second part will explore using third-party plugins and browser dev tools.

Debugging is an essential part of the development process, and WordPress is no exception. Whether you’re working on a custom plugin, theme, or website, you’re bound to run into issues that need to be resolved. The first part of this blog series will explore the codex recommendation and WordPress functions for debugging. The second part will explore using third-party plugins and browser dev tools; the series will cover everything you need to know to debug your WordPress projects effectively. Whether you’re a seasoned WordPress developer or just getting started, this guide will help you resolve issues and improve the performance of your WordPress website.

What does the Codex say?

WP_DEBUG

WP_DEBUG is a popular PHP constant that can be used to trigger the “debug” mode throughout WordPress.

define( 'WP_DEBUG_LOG', true );

-or-

define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' );

Enabling WP_debug will cause all PHP errors, notices, and warnings to be displayed. This will modify the default behavior of PHP, which only displays errors and/or shows a white screen of death when errors are reached.

Php errors are shown after you enable WP_DEBUG.
Php errors are shown after you enable debugging using WP_DEBUG

WP_DEBUG_LOG

WP_DEBUG_LOG is a companion to WP_DEBUG that makes all errors saved to a debug.log file. All the generated notices on-screen and off (e.g., during an AJAX request or wp-cron run) can be found here.

Activating WP_DEBUG_LOG also gives access to PHP’s build-in error_log() function, which can be extremely useful, for instance, when debugging Ajax events. We will check this out in detail later.

Generally, when WP_DEBUG_LOG is set to true, the log is saved to debug.log in the content directory (wp-content/debug.log) within the site’s filesystem. Alternatively, we can set it to a valid file path to have the file saved elsewhere.

define( 'WP_DEBUG_LOG', true );

-or-

define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' );

WP_DEBUG_DISPLAY

WP_DEBUG_DISPLAY works in conjunction with the WP_DEBUG constant. WP_DEBUG_DISPLAY controls whether the debug messages are shown in the front-end or stored in a log. The default ‘true’ value shows errors and warnings on the go, “false”  will remove all errors from the front-end and store them in a log, and can be reviewed later.

define( 'WP_DEBUG_DISPLAY', false );

SAVE_QUERIES

The SAVE_QUERIES definition saves the database queries to an array, and the array can be displayed to help analyze these queries. The constant defined as true causes each query to be saved, how long that query took to execute, and what function called it.

define( 'SAVEQUERIES', true );

The array is stored in the global $wpdb->queries.

We can use this code snippet to access it.

if (current_user_can('administrator')){

global $wpdb;

echo "<pre>";

print_r($wpdb->queries);

echo "</pre>";

}

SCRIPT_DEBUG

By default, WordPress loads minified versions of CSS and JS files in order to have a small impact on load times. This is great. But during development, it can be a pain if we are trying to work within one of the minified files to fix a bug or make improvements. SCRIPT_DEBUG can help us with this; setting it to true loads the un-minified versions of .js and .css files.

define( 'SCRIPT_DEBUG', true );

Function

error_log()

Note: Make sure debugging is turned on to use error_log()

If you want to log the errors without printing them in the front-end, add the following line:

define( 'WP_DEBUG_DISPLAY', false );

Sometimes when things are not working as expected. Logging and observing the data can definitely help. This is where the PHP function error_log() can help.

The error_log() function allows developers to log messages or errors to a file or the server error log. This can help identify and fix issues with a WordPress website. To use error_log(), include the function in your code and pass in the message or error you want to log as a string argument.

For example:

if ( !function_exists('some_function') ) {

error_log("Function some_function does not exist.");

}

In this example, the error message “Function some_function does not exist.” will be logged to the server error log if the function some_function is not found.

You can also pretty print your output by making use of the print_r method:

$array = array('item1', 'item2', 'item3');

error_log(print_r($array, true));

print_r()

This function prints the contents of a variable, such as an array or object, onto the screen. It’s a simple way to quickly see what’s inside a variable without digging through the logs.

$array = array('item1', 'item2', 'item3');

print_r($array, true);

var_dump()

This function displays structured information about variables, including their type and value. It’s useful for exploring the contents of arrays and objects, and it provides more detail than print_r().

Pro Tip:

If you cannot see the result, what you are trying to print or dump happens outside the page flow. You can stop the flow using die() function.

For example:

var_dump($types); // print_r($types);

die("products_first_ends");

That’s it for this one. Stay tuned for the second part, where we will discuss third-party plugins for debugging in detail.

Roshan Chapagain Cofounder, The Value Crew

Roshan Chapagain is the co-founder and CEO of The Value Crew. Having worked as a freelance software engineer for 2+ years. He understands what it takes to make a software project a success. Apart from software development, Roshan has interests in marketing, reading, philosophy, personal development.

Subscribe and get our latest Blog Posts right in your inbox
BACK TO BLOG

Flutter CI/CD with Codemagic

Roshan Chapagain
February 28, 2021
6 minutes min read
Do you spend too much time deploying your Flutter app to the apple and android store instead of adding awesome features? Do you sometimes forget to deploy the app or just want a streamlined workflow you can set it up with Codemagic? Read on.

Codemagic allows you to easily integrate CI/CD for Flutter, essentially free. Their free plan provides a 500 minute build time each month. So, if you use them properly and efficiently the free plan will be enough.

What do you need?

  • A project hosted on Github, GitLab or Bitbucket
  • Google play console if you are planning to release your application in the Playstore

Let’s Go

1. Sign Up

You can easily signup with your Github, Bitbucket or Gitlab account.

I am signing up with my Bitbucket account.

Signup to Codemagic

After you have signed up. You see all the projects hosted by the provider associated with the account.

What if you do not see the project you are trying to use?

You can simply put the repository URL.  

You will have to provide the username and the password if you are accessing a Private repository.

And voilà.

Creating a workflow

Select Flutter App

Select Flutter App
Select Flutter App

Let us assume we are building a production workflow

The right menu is self-explanatory. What you might consider is naming your workflow for future use.

Naming your CI/CD Workflow
Naming Your Workflow

2. Build Triggers

Build triggers are as the name suggest, triggers that start the build.

You can set the build to start whenever:

  • You push to a specific branch
  • On pull request update
    • For this, you can specify whether each branch pattern matches the source or the target branch of the pull request
  • On tag creation

Here I am setting the build to start when I push to the production branch.

Setting up branch

Instead of entering the exact name of the branch, you can also use wildcard symbols to select more than one branch with one pattern.

Select “Show Pattern Examples” for how to.

Additional Patterns

3. Environment Variables

Environment Variables can be useful when you might have to pass a secret api key to your application or something similar.

Using Environment Variables

We are not going to be using any environment variables for the sake of this tutorial.

4. Dependency Caching

Codemagic allows storing dependency storing so you can speed up your builds.

PathDescription
$FLUTTER_ROOT/.pub-cacheDart cache
$HOME/.gradle/cachesGradle Cache
$HOME/Library/Caches/CocoaPodsCocoaPods Cache
Common Dependency Paths
Dependency Caching

For the Next Steps..

For the next three steps, Codemagic allows you to add a ‘Post script’ and ‘Pre Script’. ‘Post Script’ allows you to add scripts that are set to run before the particular phase and after the completion of the previous phase. Whereas, ‘Post script’ allows you to add scripts that are set to run after the particular phase has completed and before the next phase.

You can use these to do different things like:

  • Creating a directory and storing environment variables
  • Starting emulator beforehand and more
Post and Pre Scripts

5. Test

Codemagic runs your tests for you. It even does static code analysis with flutter analyze. You have to “Enable Flutter analyzer” for this.

Integration Testing

You can select one of the several options for running integration testing during the build.

  • Ios Simulator
  • Android Emulator
  • AWS Device Farm
Testing

6. Build

There are multiple settings that you can set before starting your build.

Build Section

You can change Flutter, Xcode and CocaPods version. You can also easily select what you are building your application for. And if you are building for android, the build format.

Build Mode

The build arguments allow you to do things like build versioning and choosing an alternate main file to run your project.

7. Publish

Publish

Codemagic allows easy publishing of all the generated artifacts to external services. Covering publishing thoroughly is a whole blog in itself. So we will only look onto the android sides of things for now.

For android publishing, the first thing you have to do is Android code signing. Find how to do that here.

Android Code Signing

Then, select Android Code Signing. Upload your keystore file, set keystore password, key alias and key password.

Add keystore

For publishing into Google Play. You have to upload a credentials.json. Find how to get it here. Set the appropriate track.  You can also set the Update Priority and Rollout Fraction within Codemagic.

Google Play Publishing

Congrats. You are done with setting CI/CD for flutter using Codemagic. You can manually start a build. By going to your Codemagic home page and clicking on Start new build, and choosing the appropriate branch and recently created workflow.

Starting Build