DEV Community: GP Web Dev

WordPress and Components

GP Web Dev — Thu, 27 Feb 2025 23:32:27 +0000

Even though WordPress has been around for 22+ years (released on May 27, 2003), it is by no means an aged CMS framework.

Two recent improvements in its core showed us that the community behind WordPress is looking to modernize the most popular CMS. Those are the inclusion of JavaScript-based Gutenberg editor as part of the core and the upgrade of minimum PHP version to 7.4 or greater.

The Editor

Gutenberg as part of the core has added modern capabilities for building sites on the frontend. Blocks, a high-level component resembling React’s, are the basic unit to build a webpage’s frontend nowadays. In my opinion, shortcodes, custom fields and metaboxes will soon be a thing of the past, while Gutenberg will probably take over as a full development platform.

Updated PHP min version

By raising the required minimum version of PHP, the WordPress backend has access to the whole collection of PHP’s Object-Oriented Programming features (such as classes and objects, interfaces, traits and namespaces). All these modern PHP features make up of a component coding approach. No more sub-optimal code because of a backwards compatible PHP version.

Components

A component is not always just an implementation, like in React, but more of a programming approach. A coding concept that applies to frontend (CSS like Bootsrap, Bulma or JS like React, Vue) as well as to the backend. The ability to package a specific functionality, decoupling it from the main the application, allows it to be tested and bug-fixed very easily, thus making the application more maintainable in the long term. Improving our productivity by not having to reinvent the wheel each single time is something well known already, so I will not get into more details about packaging, modularization and componetizing a website.

Composer & Packagist

Composer and Packagist have become key tools for establishing the foundations of PHP-based applications. Packagist is essentially a directory containing PHP code out of which Composer, a PHP-dependency manager, retrieves packages. Their ease of use and exceptional features simplify the process of importing and managing own and third-party components into our PHP projects.

Composer allows to declare the libraries the project depends on and it will manage (install/update) them recursively. Similar to NPM, package.json file and node_modules directory, Composer only needs a composer.json file and the vendor/ directory to be ignored in our git to have the project dependencies under version control. This keeps our project’s code thoroughly decoupled from external libraries.

Composer offers plenty of additional features, which are properly described in the documentation, and even in its most basic use, offers developers unlimited power for managing the project’s dependencies.

Enter WPackagist

Similar to Packagist, WPackagist is a PHP package repository. It contains all the themes and plugins hosted on the WordPress plugin and theme directories, making them available to be managed through Composer.

Packages available in WPackagist have been given the type “wordpress-plugin” or “wordpress-theme”. As a consequence, after running composer update, instead of installing the corresponding themes and plugins under the default folder vendor/, these will be installed where WordPress expects them: under folders wp-content/themes/ and wp-content/plugins/ respectively.

Limitations

Composer makes it a breeze to manage a PHP project’s dependencies. However, WordPress’ core hasn’t adopted it as its dependency management tool of choice yet, so it is outperformed by newer frameworks like Laravel that incorporate Composer (since 2013) as part of their architecture.

How deep we can integrate WordPress and Composer together depends on the freedom we have as developers on the project. If the developer can have absolute control of how the software will be updated, e.g. by managing the site for the client, or providing training on how to do it, then we can incorporate Composer in WordPress with no problems.

However, WordPress focuses primarily on the needs of the end users first, and only then on the needs of the developers. For example, a developer can create and launch the website using Composer, and then hand the site over to the end user who might use the standard procedures for installing themes and plugins, bypassing Composer. Since we can’t ask end users to execute a command such as composer install for this, we need to release plugins with all of their dependencies bundled in. That defeats the whole components approach and Composer itself.

In our own websites though, where we have full control on the deployment of updates, Composer can be used for managing the site completely.

As opposed to traditional WordPress setups, Composer treats WP core as a site’s dependency and not as the site itself, that’s why it installs it in a sub-directory. To make it easier to completely manage WordPress with Composer, several projects have taken the stance of installing WordPress in a subfolder. Roots provides a WordPress boilerplate called Bedrock, that I can personally vouch for since we’ve used it on a large multisite WP network for the past 3 years.

WordPress through Bedrock or manually

Bedrock is a WordPress boilerplate with an improved folder structure, which looks like this:

├── composer.json

├── config

│ ├── application.php

│ └── environments

│ ├── development.php

│ ├── staging.php

│ └── production.php

├── vendor

└── web

├── app

│ ├── mu-plugins

│ ├── plugins

│ ├── themes

│ └── uploads

├── wp-config.php

├── index.php

└── wp

There are many improvements introduced here that are out of the scope of this page. The people behind Roots chose this folder structure in order to make WordPress embrace the Twelve Factor App, and they elaborate how this is accomplished through a series of blog posts.

Managing WP with Composer can also be done manually by setting our composer.json file, following this awesome recipe based on core contributor John P. Bloch’s mirror of WordPress’ core.

Either way, and with the freedom to shape the project’s folder structure, we can achieve our requirement of completely managing a WordPress site, including the installation of the core, themes, and plugins.

Conclusion

Composer, first released in 2012, is not what we would call “new” software, however, it has not been incorporated to WordPress’ core due to a few incompatibilities between WordPress’ architecture and Composer’s requirements. And of course, due to the fact that WordPress allows end users to install/update dependencies (plugins), even edit code files directly in wp-admin. That freedom is what made WP so popular but that freedom comes with a cost.

With the launch of Gutenberg and the bumping up of PHP’s minimum required version, WordPress has entered an era of modernization which provides a great opportunity to rethink how we build WordPress sites to make the most out of newer tools and technologies. Composer, Packagist, and WPackagist are such tools which can help us produce better WordPress code, with an emphasis on reusable components to produce modular applications which are easy to test and bugfix.

But that means taking back some of our clients freedom.

Introduction to WordPress REST API

GP Web Dev — Thu, 27 Feb 2025 23:30:40 +0000

The initial goal of the REST API in WordPress is to provide a way for others to interact with WordPress sites by sending and receiving data. The REST API in WordPress, if setting up the endpoints correctly, should be agnostic about what system is pinging the API. As a result, we can use WordPress as an application framework and build the client in whatever programming language we desire.

One main use of the WordPress REST API is the new block editor (Gutenberg). It’s useful to query and store data when creating custom blocks. As mentioned in the official documentation of WordPress, the REST API is language agnostic:

Any programming language which can make HTTP requests and interpret JSON can use the REST API to interact with WordPress, from PHP, Node.js, Go, and Java, to Swift, Kotlin, and beyond.

In simple words we can use any programming language to send data to an endpoint and expect a JSON response in which we can parse on the client-side. In the context of Ajax, we’re sending a payload to the REST API, and then parsing this data in JavaScript and perhaps displaying an output to the user.

WP-AJAX vs WP REST API

Since the introduction of the WordPress REST API, many plugin developers have started converting their plugins to use the REST API instead of the older AJAX API (admin-ajax.php). Aside from the REST API simply being newer technology, it is also faster and more reliable than the older endpoints due to the fact that not as much of WordPress is loaded during a typical REST request.

The REST API was merged in core more recently than Admin-AJAX. It is perfect to be used in mobile apps and API developments.

REST-API PROS

Simplicity. Simple to write, develop and debug
Does not need separate functions for logged-in and non-logged-in users
The core already has built-in handlers that speed up the development process
The response can easily be used in applications or platforms that do not run on WordPress

REST-API CONS

It does not produce any user-friendly response. The output is always in pure JSON. Some might find this an advantage
Working with JavaScript and JSON needs more knowledge than handling a simple text output

Admin AJAX existed in the core from the beginning and it is the way the core itself deals with the requests in the admin area.

Admin-AJAX PROS

It directly outputs the content (JSON, text, HTML, XML etc.) ready to be used anywhere.
It has separate functions for logged-in and logged-out users. While you can do this with a conditional in the REST-API, some may find this useful
Working with the response is easier, since you have already formatted it in your handler

Admin-AJAX CONS

Since the output is plain HTML (by default ) it shouldn’t be used in APIs and application development

They are both useful handlers and if any of them wasn’t secure, it certainly would not have existed in the core for so many years. It’s rather performance, type of request, and development platform that decides which one should be used.

From a performance standpoint, it’s clear that there is a slight advantage when using REST API. Adding custom API endpoints is incredibly easy, and since it doesn’t have to load as much of WordPress core (including the admin area and the commonly-used admin_init hook), it will likely be faster than using admin-ajax.php in most cases.

In terms of reliability, the REST API still depends on the quality and integrity of our code. A poorly coded plugin could still easily interfere with REST requests. Overall, it’s definitely a good idea to at least consider using the REST API. Adding custom API endpoints is incredibly easy, and it doesn’t take much to switch over existing code either.

Endpoints

In the WordPress REST API, routes are a list of available endpoints in the REST API. An endpoint is a final destination for the route. We can visit https://yoursite.com/wp-json/ to see the available routes and endpoints we already have in our website.

Some useful examples could be:

Posts List https://yoursite.com/wp-json/wp/v2/posts/
Pages List https://yoursite.com/wp-json/wp/v2/pages/
Taxonomies https://yoursite.com/wp-json/wp/v2/taxonomies/
CPTs https://yoursite.com/wp-json/wp/v2/cpt\_name/cpt\_ID/

The REST API Handbook provides all necessary information on how to utilize it, along with frequently asked questions, usage examples and how to extend it.

WP Query Functions – What to use and when

GP Web Dev — Thu, 27 Feb 2025 23:25:16 +0000

Core WordPress functions and classes are generally excellent regarding to performance and security.

When it comes to retrieving data from the database, the WP_Query class and its methods provide us with a safe and efficient way to do it, avoiding complex SQL queries. There are some additional wrappers of WP_Query, like query_posts() and get_posts().

query_posts

WordPress Codex explicitly says “Its overly-simplistic approach to modifying the main query can be problematic and should be avoided wherever possible“.

This query wrapper is inefficient (re-runs SQL queries) and will fail in some circumstances, especially when dealing with posts pagination. It instantiates a new WP_Query object and reassigns that to the global wp_query, breaking the main query that many plugins, themes and custom scripts rely on. For secondary queries (custom loops) instantiate your own WP_Query.

Use new WP_Query or get_posts() which are pretty much interchangeable (latter is thin wrapper for former). If you do want to alter the main query, then use the pre_get_posts hook with $query->is_main_query() check. pre_get_posts is a filter for altering any query and it is most often used to alter the ‘main query’. This is the trac about the deprecation of query_posts.

Therefore:

You should never use query_posts().

get_posts

This is essentially a wrapper for a separate instance of a WP_Query object. This isn’t a ‘Loop’, it simply returns an array of post objects.

It accepts the same arguments as WP_Query, doesn’t modify global variables and is safe to use anywhere. It passes 'no_found_rows' => true by default so it is used for non paginated queries only. It ignores sticky posts, needs just a foreach loop to display the $post property and requires a setup_postdata( $post ) to make the template tags available. WP_Query uses the loop and template tags are available by default.

Use get_posts() for some quick, non-paginated, data fetch.

WP_Query

WP_Query is the class behind both the above functions. The power of WP_Query derives from the possibility to create and work with your own instance of it. It is more of a general purpose tool, similar to directly writing MySQL, for a detailed custom query script.

A bit more complex with fewer restrictions, thus making it more powerful while being safe to use anywhere.

Use a new WP_Query for an in-depth, flexible query script.

Reset/Cleanup

Use wp_reset_query() if you’ve used query_posts() or altered global $wp_query directly – hopefully you will never need to.
Use wp_reset_postdata() if you’ve used the_post() or setup_postdata() to restore initial state of global $post.

Performance

All queries are eventually wrappers of WP_Query, and while some are better than other (never use query_posts), the performance differences of get_posts vs WP_Query are negligible. The WP_Query is faster than get_posts by a very small margin.

However parameters provided by the WP_Query class can specifically optimize SQL queries, reducing execution time and resource consumption. (Ref. 1 | 2)

When we don’t need pagination, we should set no_found_rows to true, making the query run dramatically faster.
When specific fields are not required, limit the returned fields to IDs: 'fields' => 'ids'

Data Validation and Sanitization in WordPress

GP Web Dev — Thu, 27 Feb 2025 23:20:43 +0000

When developing for WordPress, appropriate data validation and sanitization is critical for proper security of our themes and plugins.

What's the difference?

Validation – Check to see that the data we have received is what it should be. Example: check that an e-mail looks like an e-mail address, that a date is in date format and that a number is (or is casted as) an integer/decimal.
Sanitization / Escaping – Apply filters to data to make it ‘safe’ in a specific context. Example: to display HTML code in a text area all HTML tags must be replaced by entity equivalents, otherwise browser will render the HTML.

Rule No. 1: Do not trust users

Never assume that any data entered by the user is safe. Also never assume that data coming from database is safe – even if you had made it ‘safe’ prior to inserting it there. This applies to frontend forms and WP admin dashboard.

Rule No. 2: Validate Early, Escape Late

Validate on data input early, as soon as you receive it from the user. Escape (or sanitize) on output late, just before you use, display or return data. What form this sanitization takes, depends entirely on the context you are using it in.

Rule No. 3: Do trust WordPress

As opposed to direct SQL queries, when using native WordPress functions data is properly sanitized (for the appropriate context) by WP core. One more reason to always prefer using native functions, wherever possible, instead of custom code.

Data Validation

The first concern when receiving data from a user is not safety but rather validity. What ‘valid’ means is up to you and if you’re doing it right, WordPress will take care of safely adding the data to the database. Validity could mean a valid email address, a positive integer, text of a limited length, or one of an array of specified options. WordPress offers a lot of functions that can help with any validity we require.

Numbers – When expecting numeric data, it’s possible to it with is_int or is_float and it is usually sufficient to simply cast the data as numeric with: intval or floatval. For zero padding, WordPress provides the function zeroise().
E-mails – To check the validity of e-mails, WordPress has the is_email() function.
HTML – WordPress provides a family of functions of the form wp_kses_* . The wp_kses() is a very flexible function, allowing you to remove unwanted tags, or just unwanted attributes from tags. Specifying every allowed tag and attribute can be a laborious task so WordPress provides wp_kses with pre-set allowed tags and protocols:
- wp_kses_post()
- wp_kses_data()
Filenames – sanitize_file_name( $filename ) sanitizes by removing characters that are illegal in filenames. Replaces spaces with dashes and consecutive dashes with a single dash and removes periods, dashes and underscores from the beginning and end of the filename. wp_unique_filename( $dir, $filename ) returns a unique (for directory $dir), sanitized filename (it uses sanitize_file_name).
Text Fields – WordPress provides sanitize_text_field() to strip out extra white spaces, tabs and line breaks, as well as stripping out any tags when receiving data from a text field.
Keys – WordPress also provides sanitize_key that ensures the returned variable contains only lower-case alpha-numerics, dashes, and underscores.

Further information about Validating Data can be found here.

Data Sanitization

While validation is about making sure data is valid – data sanitization is about making it safe. While some of the validation functions might be useful in making sure data is safe – in general, it is not sufficient. Even ‘valid’ data might be unsafe in certain contexts. What is safe to use in one context, is not necessarily safe in another. This is why WordPress often provides several functions for the same content, for instance:

the_title – for using the title in standard HTML (inside header tags, for example)
the_title_attribute – for using the title as an attribute value (usually the title attribute in <a> tags)
the_title_rss – for using the title in RSS feeds

Sometimes though, we’ll need to perform our own sanitization – often because we have custom input beyond the standard post title, permalink, content etc. that WordPress handles for us.

Escape HTML – to avoid Cross-site scripting with injected scripts, WordPress provides the well known esc_html function. This should always be used when printing variables: <h1> <?php echo esc_html($title); ?> </h1>
Escape Attributes – to escape unsafe characters (such as quotes and double-quotes), WordPress provides the function esc_attr. Like esc_html it replaces ‘unsafe’ characters by their entity equivalents. Example: <input type="text" name="myInput" value="<?php echo esc_attr($value);?>"/>
Translated Escapes – Both esc_html and esc_attr also come with __, _e, and _x variants.
HTML Class Names – WordPress provides sanitize_html_class – this escapes variables for use in class names, simply by restricting the returned value to alpha-numerics, hyphens and underscores.
Escape URLs – When printing variables into the href attribute you should use:
- esc_url – for escaping URLs that will be printed to the page.
- esc_url_raw – for escaping URLs to save to the database or use in URL redirecting.
Escape JS – When you want to print PHP variables in JavaScript you should be using wp_localize_script() – which handles sanitization for you. In the case you do want to do directly then you can use the esc_js function to make it safe: <script> var myVar = '<?php echo esc_js($variable); ?>'; </script>
Escape Textarea – For this WordPress provides esc_textarea, which is almost identical to esc_html, but does double encode entities. Essentially it is little more than a wrapper for htmlspecialchars.
Antispambot – WordPress provides antispambot, which encodes random parts of the e-mail address into their HTML entities and protects them from e-mail harvesters.
Query Strings – the safest and easiest way is to use add_query_arg and remove_query_arg. These functions handle all the necessary escaping for for the arguments and their values for use in the URL.

More info about Sanitizing Data can be found here.

Database Escaping

When using functions such as get_posts or classes such as WP_Query and WP_User_Query, WordPress takes care of the necessary sanitization in querying the database. However, when retrieving data from a custom table, or otherwise performing a direct SQL query on the database – proper sanitization is then up to you. WordPress, however, provides a helpful class, the $wpdb class, that helps with escaping SQL queries.

For a more complete overview of SQL escaping in WordPress, see database Data Validation.