When building a portfolio project, the “what” is often less important than the “how”. I decided building a WordPress plugin with modern architecture and I chose to build a Multi-Crypto Price Converter not because the market lacked one, but because it provided the perfect sandbox to demonstrate and include in my portfolio how WordPress engineering looks like. While the feature set is straightforward, the architecture behind it is designed for scale, stability, and maintainability.

The goal was simple: Create a lightweight, robust, and highly maintainable plugin using modern tools like TypeScript, React, and SOLID PHP principles.

1. A Decoupled Architecture

Most WordPress plugins suffer from “hook fatigue,” where logic is scattered and hard to test. I approached this project with a clear separation of concerns:

• The Backend (PHP): I implemented a Service Container and used Dependency Injection to manage my classes. The backend’s primary responsibility is data orchestration—fetching crypto prices from external APIs and managing a custom caching layer. By using a dedicated service for caching, I ensure that visitors hit my local REST API rather than exhausting external API limits. By coding to interfaces rather than concrete classes, the system is prepared for future-proofing (e.g., swapping out a price API without touching the core logic).
• The Frontend (React): To keep the experience snappy, the actual currency conversion happens on the client side. Once the React component fetches the cached prices from the WordPress REST API, it handles all calculations locally. This reduces server overhead and provides an instantaneous UI for the user.

2. Building “Bulletproof” Software with PHP-Scoper

In the WordPress ecosystem, dependency conflicts are a silent killer (e.g., your plugin uses Guzzle 7, but another plugin loads Guzzle 6). To prevent this, I used PHP-Scoper.

I’ve ensured that the plugin uses prefixes for third-party namespaces to make it completely isolated. It doesn’t matter what other plugins are installed; my dependencies will never conflict. This is a standard I believe should be used in all high-level WordPress development.

3. Modern Frontend & Gutenberg Integration

I wanted to showcase my experience with the modern WordPress block editor. The plugin includes a custom Gutenberg Block built with TypeScript and React.

• Editor Experience: A custom Gutenberg block built with React and TypeScript for a native editing experience.
• Frontend Performance: While I initially considered Vanilla JS, I pivoted to a React-based frontend component to handle the state of price conversions more elegantly and provide a smoother UX but mainly to showcase my experience creating React components. By moving the conversion math to React, I avoided unnecessary admin-ajax or REST calls during user interaction.
• REST API Integration: I built custom REST endpoints to handle data fetching, this decouples the frontend from the backend logic.

4. AI-Augmented Engineering

I used an AI coding assistant as a co-pilot for this project. My goal was to see how much it could accelerate my workflow.

• The Result: It significantly sped up boilerplate and initial implementations.
• The Caveat: It requires a human hand. I found that while the AI is fast, I had to refactor its output to meet my architectural standards, fix edge-case validations, or pivot when I realized a design needed to change (such as switching from a Vanilla JS table to a full React component). I remained the architect; the AI was the builder. By maintaining a strict “Human-in-the-loop” approach—including detailed code reviews and manual refactoring—I was able to code faster without sacrificing the integrity of the architecture or losing control and knowledge of the details of the architecture.

5. Quality Assurance & Tooling

Even for a portfolio piece, code quality is non-negotiable.

• Unit Testing: I implemented tests for the core PHP logic, specifically focusing on the external API requests and the caching mechanism.
• Static Analysis & Type Safety: To reduce bugs in the codebase, I utilized PHP 8 features with strict typing throughout the plugin. I integrated PHPStan into my workflow to catch potential edge cases and type mismatches before the code ever reached execution, ensuring a level of type safety rarely seen in traditional WordPress development.
• Coding Standards: The project enforces PHPCS (WordPress standards) and ESLint to ensure the code is clean and readable for any developer who touches it next.
• Build Automation: Using package.json and composer, I created a streamlined local build process that orchestrates tsc, wp-scripts, and dependency scoping into a production-ready ZIP file.

Summary

This project was a great way to combine my interest in Web3 with my experience in modern software design. It’s not just a price converter—it’s a demonstration of SOLID principles, dependency isolation, and a modern React-to-REST workflow.

View the Source Code on GitHub

Multi Crypto Price Converter in Action

The post Building a WordPress plugin with modern architecture appeared first on Carlos Guzman.

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.

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.

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:

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.

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.

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.

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

1. The folder structure
2. Build a docker image to host the WordPress site
3. Configure the testing environment in your WordPress container
4. Docker compose to launch the containers
5. 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.

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

cd /var/www/html/

#1. check if wordpress is already installed/configured
if (sudo -u www-data -- wp core is-installed)
then

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

	#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 "$@"

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

In the section #2 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 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:

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:

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.

UPDATE(2020-06-17): Change on step 3 with a fix in the script.

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

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.

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.

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.

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.

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.

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.

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.