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:

How sensitive or potentially confidential is the information I would like to store?

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.

The Site Kit plugin by Google makes it trivial to integrate your WordPress site with various publisher-facing Google services such as Google Analytics. In addition to exposing key insights from these services directly in your WordPress dashboard, it also automatically places the necessary code snippets on your page to ensure these metrics can be gathered properly.

In this post we will look at Google Analytics specifically and how you can customize its behavior in the Site Kit plugin. While the default configuration already gives you access to many valuable metrics, Google Analytics becomes really powerful when you have tailored it to your specific use-cases. With Site Kit currently still in Beta, the user-facing configuration options for Google Analytics are minimal. While we are exploring how we can expose more customization opportunities through the plugin’s settings UI, it may be a while until these improvements are included in a new plugin’s release. Since its beta 1.0.4 release though, the plugin includes filters to modify the Google Analytics configuration, so as a developer you can tweak it in almost any way you like already today.

In my post about how I renewed my website with Gutenberg and native AMP support I mentioned that I’d be sharing some implementation details. A couple days ago I posted about how I built a reusable section block with Gutenberg. Today we’re going to look at an AMP-specific feature and how I made use of it for my site. While the AMP plugin for WordPress does a great job in ensuring your WordPress site becomes AMP-compatible, there are still tons of additional AMP features to explore, some of which are too specific to generally add support in the plugin. An example of this is the amp-timeago component, which allows displaying relative time periods, pretty much in realtime. In other words, instead of showing a concrete date and time, it will show a string such as “x seconds/minutes/hours/days/weeks/months/… ago” – you get the gist. You can see a live-example of this when looking at when this post was published, just above, below the headline. And this is precisely what we’re going to focus on in this post, how I implemented this feature and how you can implement it for your Native-AMP WordPress site.

As I announced in my last post in which I explained how I updated my website using Gutenberg and AMP, I would like to share some more details on specific implementations for some of the block types and AMP support integrations. Let’s start today with looking into building a reusable Gutenberg section block type. What do I mean by this? It is common for websites to have their main content width limited to a maximum, to keep line lengths readable on larger screens. However, sometimes you still want certain components to break out of those limitations, or you might even want to break an entire page into different full-width sections which are differentiated by their visual appearance and allow to host content that itself is then again limited in its maximum width. The homepage of my website makes heavy use of this, if you prefer to see an example, or you can also look at the following example blocks embedded in this post. (Note that you will need a screen with a resolution of at least around 1200px width in order to see the width limits to take effect.)

Writing automated tests for your WordPress project is a must in order to verify that your code works as expected. Of course you should always do severe manual testing for your plugin or theme, but as always, humans aren’t as precise and thorough as computers can be with that. Furthermore having sufficient automated tests (i.e. solid test coverage for your code) also indicates whether a subsequent change, as in a later release, unexpectedly breaks something you wouldn’t have detected otherwise. This post gives you an introduction on the test suite that WordPress core includes, which you can also use to test your plugin for example, but of course too if you’re contributing to WordPress core. Continue reading “Using the WordPress Test Suite”

If you’re a theme developer, you’re probably aware of the bits and pieces you need to look out for to have your theme be compliant with WordPress standards, for example in order to get it to appear in the wordpress.org themes repository. A theme is pretty much a separate unit within the infrastructure of a WordPress setup, it uses several specific functions that WordPress core provides and may also use some markup that is already part of core, such as a default search form or pagination. What is less commonly known though is that there are also things to look out for to make your theme fully compatible with the Multisite feature of WordPress. It’s nothing complex for most cases, but it is often overlooked. I’ll highlight the two special requirements in this post. Continue reading “Making your themes compatible with Multisite”

We hate SVN. At least most of us do. We all love GitHub (or Bitbucket, GitLab or similar). Yet, we wanna do WordPress plugins and put them up in the plugin repository.

There comes a time when everyone needs to get in touch with SVN, which is not wrong. As a developer, you should be familiar with it so that you can contribute to WordPress Core. 🙂 But using SVN to manage your plugin is a pain, especially since you probably have all development happen on a platform like GitHub. Fortunately, it doesn’t need to be like that. There are ways to deploy new plugin releases without even knowing that SVN is being used. Even if you love SVN to death, a deploy script for your plugins is worth using – let me introduce one to you in this post. Continue reading “Improve your WordPress Plugin Deployment”

If you’ve been getting your way around with WordPress, you have probably heard of that thing called Multisite. Multiple web sites in one WordPress installation, that is. You may also call it a network of sites. If you haven’t actually used it, that’s another issue – maybe you have not (yet) come across a project where Multisite would have been the right fit. (In any case, I would encourage you to try it out on your dev environment then.)

This post is not about Multisite though. It’s about how you can make your regular plugin that you would like to write or might have written years ago compatible with Multisite. Because even if your plugin does not do anything related to Multisite in any way, there are some things to take care of, in particular you need to take care of your plugin’s activation / deactivation / uninstallation routines (if you have something like it in your plugin). Otherwise you are locking out some users from using your plugin, and you certainly don’t want that, I’m sure. Now that you have read this, please don’t run away, it’s not something you need to spend days for – it might only take a few minutes, and if you don’t have any of these routines, there actually is nothing else to do to make the plugin compatible (at least not for the scope of this tutorial). But now, let’s get started! Continue reading “Making your plugin routines multisite-compatible”

I’ve been developing for WordPress over a few years now. I love the simplicity of the system (compared to other content management systems) and that it is nevertheless as powerful as all of its competitors. However, one thing always annoyed me, and I bet everyone else too: Setting it up is just a pain. Not because it is in any way hard, but because it costs some time. It’s only about 10 minutes maximum, but I didn’t want to invest this time doing the exact same thing for any web site I set up. Yeah, it’s just 10 minutes – but you probably heard that developers are lazy. You probably set up WordPress sites as well, so I don’t need to tell you this. But there is another way which I’ll illustrate in this tutorial. I will explain how you can set up your WordPress installation by executing just one single script in Terminal (you should have a basic understanding of how to use it before reading this article). Furthermore you will learn how to include a WordPress starter theme that has all the important tools built-in. But now let’s get started in kickstarting your projects!

Have you ever heard of IFTTT? It has become pretty popular in geeky Social Media circles, and if you’re not using it yet, I bet I can change your mind. But now let’s get to the actual topic.

After I had started developing stuff for WordPress, I have always looked for an easy-to-use solution to backup my WordPress sites that is reliable and free. There are tons of plugins that can handle that for you, backing up the database in intervals you specify – and we will use one of them – but the problem is where to store the backups. On the server, you might answer. But if you don’t have the money to afford a high quality dedicated server or something like that, some hosting providers, for example Bluehost, forbid storing additional data that is not directly part of your website on their server – so they might shut down your account if they realize you have been backing up your files there regularly. You could also send the files to you via email, but this would not be very efficient as you would have to browse through your mails for finding a specific backup. This article, though, tells you how to automatically send your backups to a cloud platform like Google Drive (or any other) for free. It’s easy to setup, but it’s even easier after it has been setup – you don’t need to do anything about it. It only requires that you use a free WordPress backup plugin like BackUpWordPress, that you have a Google account with Gmail and Drive and that you have a free IFTTT account.

Page navigation

See you at

Subscribe

Enter your email address to subscribe to this blog and receive notifications of new blog posts by email.

Email Address

{{#message}}{{{message}}}{{/message}}{{^message}}Your submission failed. The server responded with {{status_text}} (code {{status_code}}). Please contact the developer of this form processor to improve this message. Learn More{{/message}}

{{#message}}{{{message}}}{{/message}}{{^message}}It appears your submission was successful. Even though the server responded OK, it is possible the submission was not processed. Please contact the developer of this form processor to improve this message. Learn More{{/message}}

This Site Uses Cookies

My site, like many others, uses small files called cookies to help me improve and customize your experience. Learn more about how the site uses cookies in the cookie policy. If you have questions, you can find my contact details in the imprint.