This is a common question I get from folks in the WordPress community. How can I “lock things down” and prevent any changes to plugins, themes, and WordPress core files. For example, how to prevent any themes and/or plugins from being updated or deleted, and how to prevent any new plugins from being installed. This is useful for certain projects where it’s necessary to lock a website to a static version. Fortunately, WordPress makes this super easy with a couple of PHP constants. Let’s take a quick look..

I work from home so can afford to leave tabs open for each of my WordPress sites. That way I can jump on anytime and update or add new content very quickly. The problem I kept running into is that WordPress automatically logs out users after 48 hours. Which means I have to log back in every day even when it’s not necessary. So I needed a way to stay logged in to WordPress indefinitely. Fortunately WordPress is very flexible and easy to customize, and the login duration can be changed via several different methods.

Quick tip: how to disable embeds for any URL(s). The other day I was adding URLs to a draft post in WordPress. Some of the URLs were for Twitter tweets. Checking a preview of the post on the front end, I was surprised that WordPress had automatically embedded the actual tweet in place of the URL. After a few minutes searching for a way to disable the automatic embedded tweet, I remembered about WordPress oEmbed (now referred to as Embeds), which I’ve actually written about in several tutorials. Turns out the solution is dead simple.

There are many books and tutorials that share useful code snippets for WordPress. For example, you can find hundreds of custom functions right here at DigWP.com. You can also find them in my WordPress books, tutorials, and code snippets. For many code snippets and custom functions, the usage instructions will say something like:

I just finished up my latest book, Wizard’s SQL Recipes for WordPress. And it’s packed with over 300 time-saving code snippets for managing and optimizing your WordPress database. For example, one of the recipes from the book shows how to delete unwanted user-agent data from the WP comments table. This is an easy optimization step that can help to free up some precious disk space.

Quick post that explains how to fix the error, “The authorization header is missing”. This error may be found under “recommended improvements” in the WordPress Site Health tool (located under the WP menu ▸ Tools ▸ Site Health).

When running a Site Health check, the “authorization header” warning happens when you’ve upgraded WordPress (to version 5.6 or better) and have Permalinks enabled, but the site’s .htaccess rules have not been updated with the latest. This DigWP tutorial explains what’s happening and shows how to fix the error easily with a few clicks.

Easily hands down the most common thing that I find myself explaining to WordPress users is how to troubleshoot WordPress in order to find the cause of some issue. And it makes sense if you think about it. WordPress and all of its plugins and themes are made of code. And code is a complex thing. The more code you add to a site, the more likely it is for bugs and issues to happen. And when they do, it can be confusing and frustrating to the average user.

People often ask me whether it is safe to run plugins that are not tested with the latest version of WordPress. And it’s a good question, because software in general is something that you want to keep current and updated with all the latest. For WordPress plugins however, there are many plugins that simply don’t need to be updated with each new version of WordPress.

For a long time, premium WordPress plugins and themes were sold as a one-time payment. So for example, if you wanted to buy a new WordPress theme, you would make a single purchase and own the theme indefinitely, with no future payments due. Then somewhere along the way, a recurring pricing model became popular. These days, it is very common for themes and plugins to be sold via recurring payment scheme. So for example, if you want to use some awesome pro plugin or theme, you pay an annual or in some cases monthly fee.

Just a quick post to share some recommended useful resources for anyone working with the new Gutenberg Block Editor. Our book Digging Into WordPress now links to this post, so readers can learn more and dive deep into Gutenberg. Or just bookmark for future reference. What does that mean? It means that this page will be updated with any new useful and official resources. And by “official” just means the information is sourced/hosted at WordPress.org.

Previously, we covered numerous techniques to disable Gutenberg. For example, you can disable Gutenberg on specific post types, user roles, post IDs, and so forth. But what about doing the opposite and conditionally enabling Gutenberg? For example, if Gutenberg is disabled by default, you could then selectively enable it on whichever post types, user roles, or whatever criteria that’s required. So this tutorial explains how to enable Gutenberg using simple WordPress filter hooks. You’ll learn how to enable Gutenberg for any single posts, new posts, post meta, categories, tags, and post types. Plus some juicy tips and tricks along the way!

Upgrading from older versions of WordPress is designed to go without a hitch, but depending on the setup and the two versions involved, you may encounter some hangups along the way. For example, if you are upgrading from a version of WordPress older than 3.0, eventually you may encounter the dreaded “Warning! WordPress Encrypts User Cookies” error. This quick DigWP tutorial explains what it is, why it happens, and how to fix the problem asap.

Gutenberg soon will be added to the WordPress core. This is great news for some, not so great for others. With 99.9999% (estimate) of all WordPress sites currently setup to work without Gutenberg, the massive changes barreling down the pike are going to affect literally millions of websites. And as swell as the whole “Gutenberg” experience may seem, the simple truth is that a vast majority of site owners will not be prepared when it finally hits. Nor will many small business have time or budget to test and update client sites to accommodate ol’ Gut’.

I’ve been working on updating my collection of WordPress plugins for the imminent Gutenberg update. So far it has not required much time to learn, and the API is straightforward. It will however take significantly longer to integrate Gutenberg support into 20+ plugins. To help keep things organized, I will be posting tips and snippets here at DigWP.com. Blocks are the foundation of all things Gutenberg, so this first post is all about block recipes. Some of these code snippets are far less useful than others, hopefully they will be useful to others.