Category: Plugin Development

  • If you’re a WordPress plugin developer, you may have come across the concept of autoloading options. Or you may not, since knowing about autoloading options is, technically speaking, entirely optional when implementing a WordPress plugin that uses options. However, being unaware of the concept of autoloading options can lead to massive performance problems for large WordPress sites. It can notably slow down the server response of sites using your plugin. And by doing that, it hurts their “Time to First Byte” (TTFB), which directly contributes to the Core Web Vitals metric “Largest Contentful Paint” (LCP).

    This post is about explaining what autoloading options in WordPress is, how it works, and how plugins should go about it. We’ll go over the basics as well as explore how to use more recently introduced WordPress Core enhancements, including some code examples. This will hopefully help you get to a comprehensive understanding of how to apply autoloading in your WordPress plugins in a way that’s both efficient (for your own plugin’s usage) and responsible (for the overall sites using your plugin, in a gazillion of combinations with other plugins).

    Read more

  • While I was making minor updates to my Attachment Taxonomies plugin (GitHub repository) the other day, I noticed that the e2e tests were failing when run against WordPress version 6.1. Since the plugin’s minimum requirement is that version, I still run tests against it, to make sure it keeps working as expected.

    After some investigation, I noticed the issue was happening due to the way the block editor used to work prior to WordPress 6.3, when it started to be iframed by default. So the failure most likely wasn’t happening due to an actual bug in the plugin, but due to an issue with the e2e tests.

    Read more

  • When using a content management system like WordPress, it is obvious that the content site owners and collaborators create and manage needs to be persistently stored somewhere. In WordPress, this storage space is typically a MySQL database. For most WordPress sites, every single request to the site results in several queries to the database so that the content stored can be displayed.

    When extending the capabilities of WordPress through plugins, such plugins usually leverage that same database to store their own data. As a plugin developer you are probably already familiar with the many APIs that WordPress provides to integrate with database storage; for example the Options API to store and retrieve options, or the Meta API to store and retrieve metadata. However, do you ask yourself what the consequences of storing data in a WordPress database are?

    Not all data is equal. Certain types of data that plugins (or WordPress core itself) need to store are more sensitive than others. Think about personal data from all the customers of your WooCommerce shop, the figures of revenue you are making from affiliate links, or API credentials to access personal information from your Google account. For any data you deal with in WordPress, you should ask yourself:

    1. How sensitive or potentially confidential is the information I would like to store?
    2. What can I do to store the information safely?

    In this post, we will look more closely at how we can deal with more sensitive information in WordPress from a security perspective.

    Read more