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.)Continue reading “Building a Reusable Gutenberg Section Block”
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.
In order to have your plugin or theme customizable by other developers, you should apply a lot of filters, but of course only when it might make sense (you should empathize with fellow developers to imagine possible situations). According to the WordPress Codex, filters exist to allow others to modify the filtered content before it is processed further.
Filters are functions that WordPress passes data through, at certain points in execution, just before taking some action with the data (such as adding it to the database or sending it to the browser screen).
This is definitely the general rule you should stick to. But you cannot only modify content via filters, you can furthermore actually create content – and in some cases this is a much more efficient approach.
Continue reading “Apply WordPress Filters the better Way”
One out of all the WordPress APIs is often overlooked by developers – the Transients API. Sure, at the time you had started developing for WordPress, you first needed to get around in the system. But trust me, you definitely want to know how to use transients – because transients make your WordPress website faster. This is not only important to make sure that potential visitors don’t leave your site before it has even loaded, but also for SEO these days – Google & Co. put a lot of emphasis on your website’s page speed. The faster it loads, the better it possibly ranks. In any way, a faster page speed is better than a not-so-fast page speed. That’s why you need to use transients in your WordPress themes and plugins.
Continue reading “How To Use Transients To Speed Up Your WordPress Theme”
A day ago, Ian Anderson Gray from iag.me opened this new thread in the Github repository for Yoast’s WordPress SEO plugin. He surely isn’t the only one thinking about using Schema.org markup in WordPress (I do too!), so if you are also interested, you should join the discussion. In this article I will not tell you the great unique amazing solution for this. BUT – I will show you how to modify the WordPress SEO plugin (using filters only) so that the plugin’s breadcrumbs will be using valid Schema.org markup instead of the old RDFa markup.
Continue reading “How To Modify WP SEO Breadcrumbs For Schema.org”