WordPress is incredibly powerful, and every so often, a new feature gets added that goes under the radar that can dramatically change how you build sites. In WordPress 5.1, an addition of a new WP_Site_Query class was created. It allows you to query your network of sites but goes beyond just getting IDs and making you loop over them to use with switch_to_blog($id)
Here is another super-specific use case I had with WordPress Multisite recently.
In WordPress, creating new sites from the admin interface can be tedious, especially if you want to add custom metadata to sites/ACF option fields.
I had a scenario where I needed to create 1800 sites from a spreadsheet. Doing it one-by-one was not going to cut it, so I needed a code solution where I could loop through these sites and create them without needing the UI.
Like almost everything in WordPress, there is a function you can call. It’s called wpmu_create_blog — I have a Multisite subdomain install, so this code won’t work for directory-based multisites (it’s not hard to change, though). And I found the documentation to be quite poor. But, here is what I ended up doing.
The beauty in WordPress is not only its ecosystem. It’s the ability to customise almost every facet of it using a filter or hook.
I had a scenario recently where I wanted to put a web application theme in a less painful directory to access. I wanted a folder called themes in my root directory.
Instead of wp-content/themes/my-app-theme I wanted themes/my-app-theme instead.
The structure resembles something like this:
themes
my-app-theme
wp-content
wp-includes
index.php
wp-config.php
As much as I love WordPress, there are some fundamental flaws in how it works. For the average user, WordPress out-of-the-box will do everything you want and can be run on affordable hardware. For the project I have been working on, scaling considerations have reached a code level.
I needed to speed up some WordPress REST API endpoints in my use case. Between the core heft, plugin weight and size of the database causing some queries to be slower than your average site, I had to look for a solution that functioned like a cache.
WordPress ships with a bunch of neat core Gutenberg blocks. However, there may be situations where you need to change the output of a Gutenberg block. In my use case, I needed to modify the core/image block to add an image credit field I created using Advanced Custom Fields.
Like most things in WordPress, this is possible using an action and a few lines of code. Some solutions around on the internet make you call register_block_type to override the registration of the core block (which is wrong, in my opinion).
When performing intensive or long-running operations on a WordPress website, the admin panel is terrible. Have you tried to delete 100 posts from the posts screen? It’ll time out and delete maybe 10-20 if you’re lucky. This is one example of many.
Naturally, I opted for the WP CLI (WordPress CLI), which allows you to perform operations on your WordPress site from the terminal. I needed to delete custom post types from within a date range in my use case.
In WordPress, you add theme styles and scripts using the trusty wp_enqueue_script and wp_enqueue_style methods. However, by default, your enqueued scripts and styles will be added to your WordPress site as straight scripts.
What happens (and the reason you’re probably here) is the browser will cache your scripts, which is what we want to happen.
There is nothing more frustrating than making a change, only for the client or QA team to say they can’t see the changes, for you to go back then and tell them to do a “hard refresh.”
WordPress is the most popular CMS on the planet, powering over 40% of the internet and continually growing. Despite what you have been told, WordPress isn’t dying, and it’s not the terrible mess some dramatic PHP hating developers make it out to be.
I was tasked with building a WordPress capable of sustaining millions of visitors per minute (a project I can’t reveal the details of just yet). The brief was a platform that could handle upwards of 100,000 visitors per second. Keep in mind this is across hundreds of WordPress Multisite domains, not one single site.
I love WordPress. To me, WordPress is comfortable. I am familiar with it and have never encountered a situation where I couldn’t make it accommodate my use case or needs.
In the years that have passed since WordPress became the dominant CMS, a few other CMS’s and frameworks have come and gone, threatening to take WordPress’ mantle (it still hasn’t happened).
Some elitists out there believe that WordPress is underpinned by spaghetti legacy PHP code that makes it a non-option for some. Most of those against WordPress are more opposed to PHP itself than the CMS.
Did you know WordPress Multisite got some powerful new functionality in WordPress 5.1, allowing you to query sites by meta values?
This functionality allows you to query sites in a WordPress Multisite network by meta values and other query-based syntax to get back one or more locations.
Like many who develop WordPress websites, I use the awesome Advanced Custom Fields plugin. What ACF Pro gives you is powerful field functionality that really should be core functionality in WordPress itself.