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.