CreateIT
CreateIT
BLOG

Debug WordPress using WP Data Logger

WordPress

Debug WordPress using WP Data Logger

SHARE

Challenge:
log important transactions during API calls
Solution:
use add_action hook to save event occurrence in a separate db table

Advanced WordPress systems often use integrations with third-party APIs or sophisticated backend transactions. The system works fine most of the time, but it might happen that every X transactions there is an error. These kinds of “random errors” are difficult to debug. They may be caused by non-ordinary function parameters values or the specific setup of environment variables.

Everything works on your localhost, but on production the function is causing problems? Use the WP Data Logger plugin.

Simple logger

Logger U7 is a simple tool for debugging things in WordPress – https://github.com/hokoo/logger-u7 . It creates its own database table, so it doesn’t mess with core WordPress tables. Determine places in your code that are crucial (like saving data from API response) and log proper values using:

do_action( 'logger', $data, 'status1_code' );

A proper DB record will be created, for later review. The last parameter is the status, you can treat it as a “tag” and use it to separate different kinds of events in your application.

Logs preview

All records will be visible in the wp-admin / Tools / Logger backend section. For me personally, a more convenient way is to connect MYSQL to production and look at the data directly in the wp_data_logger table. You can use different SQL filtering to see only the data of your interest. For example:

# look for specific data response
SELECT * FROM wp_data_logger WHERE content LIKE '%part_of_response_here%' ORDER BY ID desc
# look for logs with specific tag/status, newest at the top
SELECT * FROM wp_data_logger WHERE status LIKE '%status1_code%' ORDER BY ID desc

Real life example

We’re displaying a counter that is fetched from API. The counter value is saved locally in postmeta. We’re going to update data every 1 hour (on page request we’re checking if the timestamp expired). On data expiration, we’re using the logger to save both values: our local counter and a counter from API. This will help later for data comparison.

/**
 * Display counter, data fetched from external API
 * Counter value saved in postmeta
 * Refresh data from API - every 1 hour
 */
$metaKey = 'ct_mycounter_' . $post_id . '_' . $id;
$counterData = get_post_meta( $post_id, $metaKey );
$counterData = is_array( $counterData ) ? $counterData[ 0 ] : $counterData;
if ( ! isset($counterData) || $counterData[ 'expires' ] <= time() ) {
    $counter = $this->getCounterFromAPI( $id );
    // debug
    do_action( 'logger', $metaKey . ' | ' . $counterData['counter'] . ' @ ' . $counter, 'status1_code' );
    $counterDataNew = [
        'expires' => time() + (HOUR_IN_SECONDS),
        'counter' => $counter,
    ];
    update_post_meta( $post_id, $metaKey, $counterDataNew);
} else {
    $counter = $counterData['counter'];
}
//if counter still zero - show nothing
if ( 0 === (int)$counter ) {
    return;
}
echo '<div class="progress-bar">'. $counter . '</div>';

To make things more interesting, we also have Ajax Form. On every submit, the local counter is increased and API is notified about a new submission.

/**
 * Ajax form submit
 * notify API about submit
 * increase counter action in DB
 */
$this->notifyAPI();
// update local counter
$metaKey = 'ct_k1_' . $post_id . '_' . $id;
$counterData = get_post_meta( $post_id, $metaKey );
$counterData = is_array( $counterData ) ? $counterData[ 0 ] : $counterData;
if(isset($counterData['counter'])){
    $counterData['counter'] = intval($counterData['counter']) + 1;
    update_post_meta( $post_id, $metaKey, $counterData );
}

Every 1 hour, our local counter will be “replaced” by a proper counter from API. In theory, those values should be equal. Having wp_data_logger records, we can debug if values are properly saved and increased.

Disabling Prod Logging

Let’s say our work is finished, we’ve found the issue and fixed the code. The good news is that we don’t have to remove our do_action(“logger”) from the code. Just deactivate the WordPress plugin and the system will work without an interruption.

That’s it for today’s tutorial. Make sure to follow us for other useful tips and guidelines.

Need help?

  • Looking for support from experienced programmers?

  • Need to fix a bug in the code?

  • Want to customize your webste/application?

ADD COMMENT

Your email address will not be published. Required fields are marked *

createIT Contact