DEV Community: Carlos Guzmán

How to update meta fields of multiple posts in WordPress using a single REST request

Carlos Guzmán — Sat, 05 Oct 2024 17:10:51 +0000

Building a custom settings page in WordPress using React, I faced the situation where I wanted to update meta fields of multiple posts at once. I want to share the approach I used with the WordPress REST API.

The WordPress REST API has a framework for making a series of REST API calls at once. It is handy to update meta fields of multiple posts using a single REST request. The framework name is REST API Batch Framework. Next are the steps I took to use it.

Registration of the meta fields in the REST API

First I registered the custom meta field in the REST API using the register_post_meta function.

add_action( 'init', function() {
    register_post_meta(
        'post',
        'my_custom_field_name',
        [
            'single' => true,
            'type' => 'string',
            'show_in_rest' => true,
        ]
    );
} );

The first argument I used here is 'post', which means that the custom field is applied for items saved in the posts table (posts, pages and custom post types). Here you can use other entities like 'comment', 'term' or 'user'. If the meta field is used in a custom post type, then the custom post type should support custom fields. During the custom post type registration, you can use the supports field to add custom-fields.
The second argument is 'my_custom_field_name' which is the key name used for the meta field.
The last argument describes the meta field. In this example, the meta field has one value per post only, its type is string and its value is accessible via the REST API. Indeed, the value of the 'show_in_rest' key can be an array with the key 'schema' to describe its data structure in the REST API.

Using the Batch Framework to update meta fields of multiple posts in WordPress

The React component uses the Batch Framework and it is in charge of doing the request to update the posts. It has a function to update the meta fields of multiple posts in WordPress using a single request. The request looks like this:

const requests = [
    {
        path: '/wp/v2/posts/10',
        method: 'POST',
        body: {
            meta: {
                my_custom_field_name: 'hello world',
            },
        },
    },
    {
        path: '/wp/v2/posts/11',
        method: 'POST',
        body: {
            meta: {
                my_custom_field_name: 'lorem ipsum...',
            },
        },
    },
    {
        path: '/wp/v2/posts/12',
        method: 'POST',
        body: {
            meta: {
                my_custom_field_name: '123abc',
            },
        },
    }
];
apiFetch( {
    path: 'batch/v1',
    method: 'POST',
    data: { requests },
} )
    .then( response => handleBatchResponse( response, requests ) )
    .catch( err => console.log( err ) );

The apiFetch call use the next config object:

The path and the method properties of the Batch Framework endpoint, batch/v1 and POST respectively.
The data property is an object with the property requests which contains an array with the configuration of each one of the requests we want to execute. Each configuration is an object with the required property path and optionally the properties method, headers and body. In this case, these are the configuration to make the requests to the WordPress endpoint POST /wp/v2/posts/<id> to update the posts.

Handling the response

Finally here is how to handle the response of the request to update meta fields of multiple posts in WordPress. In the React component, I defined the next function:

const handleBatchResponse = ( batchResponse, requests ) => {
    batchResponse.responses.forEach( ( requestResponse, idx ) => {
        // Get the data of the request related to the current response.
        const requestData = requests[idx];

        // Check if the response was not successful.
        if ( 200 !== requestResponse.status ) {
            // Show error message here.
        }
    } );
} );

The custom function handleBatchResponse expects 2 parameters, the response of the batch request and the array of requests sent in the batch request. This function is called when the response of the request is received and parsed by the apiFetch call. The response of the batch requests is an object with the property responses which is an array of enveloped responses objects for each one of the requests sent in the batch request. Each enveloped response has the properties status, headers and body. The order of the items in the responses array corresponds to the order of the items in the requests array sent in the batch request, so the first object in batchResponses.responses is the response of the first object in the requests array.

Conclusion

It is possible to update meta fields of multiple posts in WordPress using a single REST requests. The REST API Batch Framework allows to run multiple requests at once in WordPress. However, take into account that it accepts up to 25 requests in a single batch. Additionally, the framework doesn’t support GET requests. Using parallel requests or linking and embedding are the recommendation in this case.

The post How to update meta fields of multiple posts in WordPress using a single REST request appeared first on Carlos Guzman.

Prevent access to WooCommerce downloadable products in WPEngine

Carlos Guzmán — Fri, 08 Oct 2021 13:20:07 +0000

If you are using WPEngine, WooCommerce and you sell digital products, then you might have realized that your downloadable products are public to anyone. You can use redirect rules to protect access to WooCommerce downloadable products in WPEngine. But now it has a feature called web rules that allows you to block access in a similar way that .htaccess does.

First go to the dashboard of your site in WPEngine. Then click on the Web rules option at the bottom in the sidebar menu:

Then you just need to create an access rule to block direct access to the WooCommerce downloadable products in WPEngine:

When you are creating the new rule, use the next configuration:

Order: 1 (or a lower value order than any rule that could interfere)
Action: Deny
IP: All
Condition type: URI
Condition Operator: Regex matches (~)
Condition value: wp-content/uploads/woocommerce_uploads/

This configuration blocks the direct access to the files in the WooCommerce uploads folder. When your downloadable products is bought, then WooCommerce gives a link to the customer. Then the customer uses this link to download the product.

Do you need help with the configuration of your website? Don’t hesitate into hire me now.

Now that you have protected your files, let’s see what is the “issue”. The summarized explanation is that WPEngine uses Nginx instead Apache as web server. WooCommerce creates an .htaccess file in its upload folder. Apache uses it to block the access to the content in the folder. However, the .htaccess file doesn’t work in Nginx. This web server works in another way and it is configured in other way. Unfortunately, WooCommerce doesn’t have a way to make this configuration and only the administrator of the web server can setup the configuration and block the access. Before it was possible to prevent direct downloads in WPEngine using redirect rules. Now WPEngine has a feature named web rules that allows us to make this configuration and block the access to some sections in our website easily.

The post Prevent access to WooCommerce downloadable products in WPEngine appeared first on Carlos Guzman.

Responsive dynamic background images in WordPress

Carlos Guzmán — Mon, 19 Oct 2020 12:46:32 +0000

The most common ways to show images in a website are using the HTML tags <img> and <picture> or using the CSS property background-image. There are attributes in the HTML tags to show different images based on the browser viewport. Or you can use media queries to show different images with background-image. You could find the article The CSS background-image property as an anti-pattern very interesting. If you are using background-image anyway, this article describe how to use it to have a responsive dynamic background images in WordPress.

Nowadays one trend is to use eye-catching images at the top of articles and news in websites to draw the attention of visitors. Downloading images in a website is one of the main factors in the speed loading. Large images increase the quantity of data to download. Most of the traffic of websites is done through mobile devices. Optimize the loading of these images is important.

WordPress has the field featured image in to link a representative image with an article. Some websites use this image in the header of the article. The next solution also works if the image is not in the featured image field but in a custom field of the article.

1. Define the CSS breakpoints

CSS breakpoints define the ranges of device screen width where the content responds in a certain way. In example, the framework Twitter Bootstrap defines 4 breakpoints and 5 ranges: extra small, small, medium, large and extra large.

Extra small screens: <576px
Small screens: ≥576px
Medium screens: ≥768px
Large screens: ≥992px
Extra large screens: ≥1200px

2. Register image sizes for each screen width range

Each screen width range defined by the CSS breakpoints requires to define the dimensions to show the image in the range. Let’s continue with the example of Twitter Bootstrap. We are using its containers and we are displaying the image using the full width of the container, then we could define the next dimensions(WxH):

576×350 for containers in extra small screens
540×350 for containers in small screens
720×350 for containers in medium screens
960×400 for containers in large screens
1140×400 for containers in extra large screens

The WordPress function add_image_size registers images dimensions. WordPress creates a cropped version of the image for each registered dimension when an image is uploaded.

// register image sizes
add_image_size('header-image-xs', 576, 350);
add_image_size('header-image-sm', 540, 350);
add_image_size('header-image-md', 720, 350);
add_image_size('header-image-lg', 960, 400);
add_image_size('header-image-xl', 1140, 400);

3. Include the image in the theme template

A WordPress theme has different templates for different kind of pages. In this example, we are displaying the images for the articles. Thus we edit the single-post.php template to include the image.

// ... content before the background image

<div class="site-content">
  <div class="header-image-container">
    // ... some content over the background image
  </div>
</div>

// ... content after the background image

4. Include the media queries

When we show the image using background-image, then we need to use CSS media queries to display the images in a responsive way. We can use the WordPress hook wp_head to include the CSS code in the head of the HTML document. In the function attached to the hook, then we get the featured image of the article and build the media queries. At this point, we have defined the HTML structure and we know the CSS selector required to point to the element where the background-image is used.

// print the background CSS rules
add_action('wp_head', function(){
  // link breakpoints and image sizes
  $images = [
    '0' => 'header-image-xs',
    '576' => 'header-image-sm',
    '768' => 'header-image-md',
    '992' => 'header-image-lg',
    '1200' => 'header-image-xl',
  ];

  // check if the post/page has a featured image
  if (has_post_thumbnail()) {
    // get the thumbnail images
    array_walk($images, function(&$item) {
        $item = get_the_post_thumbnail_url(get_the_ID(), $item);
    });
    ?>
    <style>
    <?php foreach($args['images'] as $breakpoint => $image_url): ?>
      <?php if ('0' == $breakpoint): ?>
      .site-content .header-image-container {
        background-image: url("<?= $image_url ?>");
      }
      <?php else; ?>
      @media (min-width: <?= $breakpoint ?>px) {
        .site-content .header-image-container {
          background-image: url("<?= $image_url ?>");
        }
      }
      <?php endif; ?>
    <?php endforeach; ?>
    </style>
    <?php
  }
});

And that’s all. You can find here a demo of this approach:

Demo of responsive dynamic background images in WordPress

You might found useful the library wp-responsive-background-image. I created this library which offer an interface with a couple of methods to allow add the background rules easily. It uses the approach mentioned before to insert responsive dynamic background images in WordPress.

The post Responsive dynamic background images in WordPress appeared first on Carlos Guzman.

Datetime or Timestamp: readability matters

Carlos Guzmán — Fri, 12 Jun 2020 20:39:48 +0000

When you are designing the schema of the database for your project and you need to store dates and times, then the question about what data type to use appears. Recently, I started a project to build a REST API and I used timestamps, a total mistake. Later, I was applying to a job and again I decided to use timestamps in the project to show my skills. During the interview, the recruiter asked me why I decided to use timestamps and I realized that I didn’t make any analysis for this decision. I just wanted to try it…what a mistake.

After this, I decided to investigate the pros and cons for the different options to store dates in a database. There are multiple articles about this topic. I want to highlight this article where it is explained with details, examples and benchmarks using MySQL. Next is a too short summary about the article:

Using DATETIME allows to make SQL queries using functions related to dates(i.e: WEEKDAY in MySQL) in the SQL server. It allows to use dates from year 1000 to 9999. Queries over DATETIME are faster than queries over TIMESTAMP. The format used to print the DATETIME is user friendly and legible.
Using TIMESTAMP also allows to make SQL queries using functions related to dates. It allows dates until 2038 only. TIMESTAMP is lighter and it saves 1 byte of storage compared with DATETIME. The format used to print the TIMESTAMP is user friendly and legible.
Using UNSIGNED INT allows dates until 2106. It is not possible to use CURRENT_TIMESTAMP with this data type. SQL queries over INT are much faster than DATETIME and TIMESTAMP. To use date functions, the integer should be converted to a date(using function FROM_UNIXTIME in MySQL). In this case the SQL queries are slower than DATETIME.

One of the disadvantages with TIMESTAMP is the limit of 2038. Personally, I think that the SQL servers will change this in order to preserve compatibility with existing software using this datatype. It is not the same with INT because it is a datatype not intended to be used for dates. However there are integer types using more bytes of storage like BIGINT in MySQL.

After my experience using timestamps in a REST API, definitely I will use DATETIME in next projects unless performance and storage are critical. When you are debugging, readability matters. When you see a bunch of numbers that not make sense, then you need to expend time converting those numbers to readable dates. Also working in the frontend, sometimes I needed to understand why I was getting those dates and then again it was stressful to see unintelligible numbers in the API response.

Timestamps in a REST API response

In my opinion, using UNSIGNED INT has sense if the performance of the app is critical AND you have one or multiple queries that doesn’t require to use date functions and they are in processes that run frequently in the app.

The post Datetime or Timestamp: readability matters appeared first on Carlos Guzman.

Running PHPUnit tests in a WordPress plugin with Docker

Carlos Guzmán — Sat, 25 Apr 2020 15:16:24 +0000

There are several resource about running PHPUnit tests in a WordPress plugin with Docker. Here I want to share how I do it. You can find the configuration files in Github.

I explain how to create the development instance in 5 steps:

The folder structure
Build a docker image to host the WordPress site
Configure the testing environment in your WordPress container
Docker compose to launch the containers
Run tests while coding

1. The folder structure

Let’s start creating a folder to host all the docker configuration files and the WordPress code including the plugin source files.

How the folder will look at the end

This is a picture of how the folder will look at the end. my-project is the root folder of the project. The wordpress-image folder contains the Dockerfile and an the entry point script for the WordPress environment. The wordpress folder contains the files of WordPress and the plugin to work on.

I use to run the wp-cli tool as the www-data user instead as root. So I assign www-data as group and my user as owner of the wp-content folder inside the wordpress folder. Then I give write access to the group to the wp-content folder. In this way, www-data is able to write on those files without problem and I can edit the files from outside Docker with my user.

2. Build a docker image to host the WordPress site

I built a custom Docker image based on the official Docker image for WordPress. The purpose of this custom image is to setup the development instance to run the unit tests automatically. This file is placed inside the wordpress-image folder. Next is the Dockerfile of the image:

#1. Docker base image
FROM wordpress:php7.4-apache

#2. Install WP-cli and dependencies to run it
RUN apt-get update \
    && apt-get install -y \
      less \
      subversion \
      sudo \
      default-mysql-client-core \
    && curl https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar -o /usr/local/bin/wp \
    && chmod +x /usr/local/bin/wp

#3. Create the files for the testing environment
RUN \
    #3.1 Install phpunit
    curl -L https://phar.phpunit.de/phpunit-7.phar -o /tmp/phpunit \
    && chmod a+x /tmp/phpunit \
    #3.2 Install wordpress
    && cp -r /usr/src/wordpress /tmp/wordpress \
    && curl https://raw.github.com/markoheijnen/wp-mysqli/master/db.php -o /tmp/wordpress/wp-content/db.php \
    #3.3 Install the testing libraries
    && svn co --quiet https://develop.svn.wordpress.org/tags/5.3.2/tests/phpunit/includes/ /tmp/wordpress-tests-lib/includes \
    && svn co --quiet https://develop.svn.wordpress.org/tags/5.3.2/tests/phpunit/data/ /tmp/wordpress-tests-lib/data \
    #3.4 set owner and permissions
    && chown -R www-data:www-data /tmp/wordpress \
    && chown -R www-data:www-data /tmp/wordpress-tests-lib

#4. Copy the script to create the testing environment when the container is started
COPY init-testing-environment.sh /usr/local/bin/

#5. Run the script and send as an argument the command to run the apache service
ENTRYPOINT ["init-testing-environment.sh"]
CMD ["apache2-foreground"]

The section #1 in the Dockerfile shows the base image used. In this case the container will run WordPress in a Apache web server running PHP 7.4. You can see other options of images for WordPress in Docker Hub.

The script installs wp-cli in the section #2 . This tool is required to create the testing environment to run unit tests with WordPress easily. I run the wp-cli as the www-data user using the sudo package. Subversion downloads the testing libraries in the next section of the script. The mysql client package is used to check the connection to the database in the configuration of the testing environment later.

The section #3 creates the files for the testing environment. It is not required to download these files again when the container is started. In this way, there is a saving of data downloaded but mainly the container starts faster. It creates the WordPress instance for testing and download the libraries used by WordPress to run PHPUnit. This section does part of the job of wp scaffold plugin-tests which will be invoked when the container is launched.

In sections #4 and #5, the entry point script is copied and its parameters are configured. More about this script follows in the next section.

3. Configure the testing environment in your WordPress container

In the Dockerfile above, when the container starts, it runs a custom script instead running the Apache service. This script basically finishes the testing environment if it is not complete yet before launching the Apache service. This script is based on the steps to create a testing environment in WordPress and it is placed inside the wordpress-image folder.

#!/bin/bash

#1. check if the database is ready
cd /var/www/html/
if ! (sudo -u www-data -- wp db check)
then
    # wait a moment for the database container
    sleep 1
    exit 1;
fi

#2. check if wordpress is already installed/configured
if (sudo -u www-data -- wp core is-installed)
then
    #3. init the testing instance
    sudo -u www-data -- wp scaffold plugin-tests $WP_PLUGIN_FOLDER --force
    cd wp-content/plugins/$WP_PLUGIN_FOLDER && sudo -u www-data -- bash -c "./bin/install-wp-tests.sh $WP_TESTS_DB_NAME $WORDPRESS_DB_USER $WORDPRESS_DB_PASSWORD $WORDPRESS_DB_HOST latest true"   
fi

#4. back to the root WP folder
cd /var/www/html/

#5. execute the entrypoint of the parent image
bash docker-entrypoint.sh "$@"

In the section #1 of the script, it checks if the WordPress instance have connection to the database. If it is not the case, then it finish with error core but it sleeps for a bit first to give some time to the database to be ready.

The script checks if the WordPress instance is already configured in the section #2. The configuration of the testing environment requires the WordPress site to be already installed. If it is not active, then it skips the section #3 and launches the container.

The section #3 uses wp scaffold plugin-tests to create the configuration for the environment to run PHPUnit. One of the configuration files is install-wp-tests.sh. The install-wp-tests.sh script creates the WordPress instance in the tmp folder by default. I already created this instance in that folder in the previous step. The script doesn’t download the WordPress files again because the WordPress files are already in the folder. The docker compose file, explained in the next step, passes the values for the variables like WP_TEST_DB_NAME or WORDPRESS_DB_USER.

The last 2 sections in the script just move back to the main folder and executes the default entry point of the WordPress Docker image.

4. Docker compose to launch the containers

The next step is to create a docker file to run easily the backend and the database containers.

version: '3'

services:
    db:
        image: mysql:5.7
        volumes:
            - db-data:/var/lib/mysql
        ports:
            - "3360:3306"
        environment:
            MYSQL_ROOT_PASSWORD: password
            MYSQL_DATABASE: wordpress
            MYSQL_USER: wordpress
            MYSQL_PASSWORD: password

    wordpress:
        depends_on:
            - db
        build: ./wordpress-image
        ports:
            - 8080:80
        restart: on-failure
        volumes:
            - ./wordpress:/var/www/html
        environment:
            WORDPRESS_DB_HOST: db:3306
            WORDPRESS_DB_USER: wordpress
            WORDPRESS_DB_PASSWORD: password
            WORDPRESS_DB_NAME: wordpres
            WP_TESTS_DB_NAME: wptests
            WP_PLUGIN_FOLDER: my-plugin-folder

volumes:
    db-data:

The first service in the docker compose file launches the container for the database. It is based on the MySQL Docker image. The values for passwords, database and user names are values that you configure at your wish.

The second service is used for the WordPress container. It is based on the custom WordPress image that I created in the step 2 explained previously. This container uses a volume for the root folder of the WordPress instance. The values used to configure the database connection of the WordPress instance should match the values used for the database container. The official WordPress Docker image doesn’t use the variables WP_TEST_DB_NAME and WP_PLUGIN_FOLDER. The script explained in the step 3 uses these custom variables. The first variable is the database name used to run the PHPUnit tests. The second variable is the name of the plugin folder under development and testing.

Last to highlight is the directive restart with value on-failure that allows this container to try to be launched again if the script to create the testing instance fails or if there is another problem starting the container. In example, if the database is not ready as we saw in the previous step.

5. Run tests while coding

The development and testing environment is ready after all this configuration. First go to the project folder and lunch the containers using docker-composer up. The testing environment will not be configured until you have configured the WordPress site. After lunching the containers by first time, you would need to visit localhost:8080 in your browser to setup the WordPress site.

The next time you lunch your container, if you have already setup the WordPress site, then the testing environment will be configured automatically. Then you need a bash session in the WordPress container to run the tests:

Bash session in the WordPress container

An alternative is to use composer and install PHPUnit in the plugin’s source code. In the step 2, I already downloaded it and place it in the tmp folder:

PHPUnit tests results

If you want to run your tests automatically while you are coding, you could take a look to a previous article where I explain how to run tests automatically using the bash script watch-and-do.

So this is the way I run PHPUnit tests in a WordPress plugin with Docker. You can find these configuration files in Github.

The post Running PHPUnit tests in a WordPress plugin with Docker appeared first on Carlos Guzman.

Running PHPUnit tests automatically

Carlos Guzmán — Sun, 01 Mar 2020 17:30:52 +0000

I have found test-driven development(TDD) a very interesting development methodology. Just recently I have been applying this in the development of a WordPress plugin. One of the issues during the development was wasting time launching tests manually after making changes to the code. You don’t know what you could do and achieve in those few seconds. Running PHPUnit tests automatically became important to save those precious seconds. In this post I want to share how to run tests automatically when a change in code is detected.

There are multiple options that you could use for running phpunit tests automatically. In example, phpunit-watcher is a PHP script that you can install in your project easily through composer. In my case, I created watch-and-do, a bash script and it is now hosted in Github. Honestly I think I didn’t google it well and I didn’t find phpunit-watcher before. But let’s say that I wanted to learn and create a bash script.

Running PHPUnit tests automatically with watch-and-do

A testing environment with WordPress configured and running is required in order to run tests for the WordPress plugin. In the official documentation of WordPress, you can find how to create the testing environment for your WordPress plugin.

The bash script is based on inotifywait to watch and detect changes in the code. This tool can use some filters to notify when a file is created, modified, deleted or moved only:

# listen for changes
inotifywait -m -r -q -e modify -e create -e delete -e move --format "%w%f %e" $WATCHDIR

When a change is detected, then the script waits for a couple of seconds before launching the tests. Sometimes I am editing multiple files and then I save all of them. With a delay in the script, the test are launched after the last saving instead launching the tests after saving each file:

# increase the stock
echo $(( $(cat $STOCK_FILE) + 1 )) > $STOCK_FILE

# sleep for a moment while more changes are detected
sleep $CHANGES_DETECTION_SLEEP

# decrease stock
echo $(( $(cat $STOCK_FILE) - 1 )) > $STOCK_FILE

# if stock is empty (this discard multiple execution)
if [$(cat $STOCK_FILE) -eq 0]
then
    # run tests
    run_tests $@
fi

It is important to run the tests in a new process and store its PID because it is used to stop the process if required. Before launching the tests, it is possible that the tests are under execution due to a previous modification of a file. In order to not get conflicts and to not get a mess in the console, it is a good idea to stop the current execution of the tests. We stop the tests using the PID of the process and the kill command with signal SIGTERM. The tests are not stopped immediately, so it is important to wait until they have been stopped:

while [$LASTPID] && [$LASTPID -gt 0] && (ps -p $LASTPID > /dev/null)
do
    # kill previous testing
    if [$KILLING -eq 0]
    then
        KILLING=1    
        kill -SIGTERM $LASTPID
    fi

    # wait until previous tests are finished
    echo "Wait while current tests are stopped..."
    sleep $TESTS_KILLING_SLEEP
done

Finally, when previous tests have been stopped, the new tests are lunched and the PID of its process is stored. The command to run the tests is passed as an argument to the script. In this way the script is not attached to how phpunit is configured in the system:

# execute tests
echo "Running command: $@"
$@ &

# store the pid of the thread running the tests
echo $! > $PID_FILE

Using the script requires as arguments the folder to watch and the command to run the tests:

$ ./watch-and-do my-base-folder phpunit -v

As mentioned before, this script is just an alternative to other tools to watch for changes in your code and run the tests automatically. This bash script is open source and you can find it in Github as watch-and-do.

The post Running PHPUnit tests automatically appeared first on Carlos Guzman.

How to see the error logs in WordPress with Docker in Linux

Carlos Guzmán — Fri, 24 Jan 2020 17:47:42 +0000

Recently I was working in the development of a WordPress plugin and I didn’t find an easy way to see the error logs in WordPress with Docker. I started to read and learn about Docker some few time ago. I created a WordPress development instance using the official Docker image for WordPress in Docker Hub. In some cases, you want to see the log of errors and do not activate the debug mode in WordPress. In example, a plugin can generate warnings that make difficult to debug and that could break responses for Ajax requests in your site.

My first attempt to see the error logs was to login in a bash session it the Docker container. Then I searched for the error log file but the errors are sent to the I/O stream STDERR by default.

Default configuration of error logs for WordPress with Docker

Instead to create a custom image to change this configuration, I tried with the Docker cli tool to access to the logs of the container. Using docker logs ID_CONTAINER, I was able to see the logs of the web server. It was progress but it wasn’t what I want. I got all logs entries of the web server including access and warning entries. It would be difficult to spot the error entries easily in a website loading multiple resources and doing multiple Ajax requests.

Show logs of the Docker WordPress image container.

The solution

If we discard the output sent to the standard stream, then the access entries are gone. So using docker logs -f ID_CONTAINER >/dev/null, we get only the entries sent to the error stream. Most of the entries here are the useful entries for debugging, they are the warning and error messages. The option -f in docker logs command is to follow and refresh automatically the logs in the console.

Show entries sent to the error stream only

Extra tip

If you want to see the error messages only without changing the error reporting directive, you can use the grep tool to filter the other entries. Using docker logs -f ID_CONTAINER 2>&1 >/dev/null | grep -i error, the entries are filtered to display only the lines with the error word in them. This command replaces the output of the standard stream with the output of the error stream. Then grep filters the content. The option -i in the grep command is to be case insensitive in the search.

Show only error logs of WordPress with Docker

Maybe it isn’t the most elegant but at least it is an effective way to see the error logs in WordPress with Docker.

The post How to see the error logs in WordPress with Docker in Linux appeared first on Carlos Guzman.