I’ve been working on a WordPress Multisite installation that is going to eventually have upwards of 20,000 sites. Somewhere around the 50 site mark, I noticed the WordPress admin panel was beginning to slow down. And, after some investigation, I discovered the “My Sites” menu in the admin bar was part of the problem.
Using the admin_bar_menu action hook, we can bind to this admin bar (like most things in WordPress), and remove items we don’t want to show.
If you’re working with WordPress Multisite, you might encounter a scenario where you want all uploaded media to share the same folder. In my case, I needed all sites to use the same uploads directory as the parent site.
As with most things in WordPress, there is some hook or filter you can use to change core WordPress functionality. For the upload directory, there is a filter called upload_dir which is called when the upload directory is configured.
Recently, I created a WordPress Multisite installation on Amazon AWS Lightsail. I had this bizarre issue where my child sites were working, but whenever I would try creating posts or pages, the new button would take me to the root domain. Chalk this one up to stupidity (on my part).
It was a perplexing issue because it was acting like I was in the admin panel for the root domain, not the child site. It was even showing my post counts for the root domain (but not posts). Going to the permalinks screen was showing the root domina, everything was a disaster.
The WordPress REST API is one of my favourite features in WordPress. The ability to create custom endpoints for getting data and other facets of building in WordPress makes life so much easier.
Recently, while building a custom endpoint that allowed for some custom post type content to be searched, I encountered a snag.
register\_rest\_route( 'raw-queue/v1', '/queue/(?P[a-zA-Z0-9-]+)/(?P[\\d]+)/(?P[\\d]+)/(?P[a-zA-Z0-9-]+)/(?P([a-zA-Z])+)', array( 'methods' => 'GET', 'callback' => 'rest\_get\_news\_stories\_from\_category', 'permission\_callback' => '\_\_return\_true' ) ); For singular search terms, it worked well. However, once I searched for words like “basketball player”, I would get the dreaded 404 error.
WordPress documentation is usually robust. However, recently I had a use case where I needed to query sites by custom meta values.
In WordPress 5.1, the WP_Site_Query was introduced to allow a faster way to query sites in a WordPress Multisite setup without using the old hack of needing to get all ID values using get_sites and then inside of a loop using switch_to_blog to query the sites and get values.
Out of the box, Advanced Custom Fields offers immense power but provides no functions to work with WordPress Multisite sites. Fortunately, WordPress makes it easy to work with multisite sites.
Throw the following function into your theme functions.php file and call it at will. Just provide the field name and site ID, the function will get your value from that site (if there is a value and field exists).
function get\_acf\_site\_option($field\_name, $site\_id) { switch\_to\_blog($site\_id); $value = get\_field($field\_name, 'option'); restore\_current\_blog(); return $value ? $value : null; }
What is the most efficient way to delete thousands of posts, custom post types, media attachments and other things in WordPress? The answer is: not through the admin panel.
If you have ever tried deleting a couple of hundred (or so) items from the WordPress admin panel before, then you would know if the request doesn’t timeout, you’ve won the WordPress lottery. And, if it does timeout, you have to keep spamming the refresh button until it works.
If you are working with WordPress version 5 and up, you might be using the REST API. I love the in-built REST API WordPress provides, especially for creating applications on top of WordPress.
The Node WPApi package makes this a breeze, especially when it comes to authentication based actions.
My first test with this package was creating a new post, and I got this error message:
Sorry, you are not allowed to create posts as this user. I was confused at first because I entered the correct username and password for my WordPress installation. Well, as you will discover, WordPress won’t just allow you to perform authentication-based requests using your standard credentials.
WordPress comes with a lot of stuff out of the box. Throw in some plugins, and it gets even noisier. Next minute, your menu sidebar in admin looks like that drawer in the kitchen you shove everything into (known in Australia as a crap draw).
Now, you’ll want to hide some menu items for particular roles or even users (whatever floats your boat). The first hurdle can be knowing what each item is registered as (the slug matters). The core menu items like plugins and tools are easy enough, but custom menu items like “Custom Fields” and “Elite Video Player” — you need to know the slugs these were registered using.
Believe it or not, finding this information in the official WordPress documentation was a nightmare. I had to go through the WordPress codebase itself to find these values.
In a site I am working on, I wanted only to enable specific WordPress Gutenberg blocks. By default, my client will never use a lot of junk, like buttons and page separators that I wanted to disable.
I am using the allowed_block_types hook to create an inclusion list where I specify what blocks I want to enable. You can also add your custom blocks to this list.