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’ve written numerous tutorials explaining how to troubleshoot WordPress, plugins, email, and more. When investigating issues, diagnosing problems, and hunting bugs, troubleshooting is a critical core skill for any web developer. To help readers level up their tool belt, here’s a quick round-up of free plugins to help troubleshoot any of your WordPress projects.

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:

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.

Something I did not know about when working with Custom Post Types and Custom Taxonomies. Normally when checking if a regular WP Post belongs to a specific category, we can use the WordPress function in_category(). But that does not work with Custom Post Types. To check if a CPT belongs to a specific term in a Custom Taxonomy, use has_term() instead.

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.

WordPress plugins that clean up after themselves are pure awesome sauce. If you are developing a plugin that adds any sort of data to the WordPress database, it is important that the plugin removes any unwanted or unused data if and when the plugin ever is uninstalled. This complete guide explains useful techniques for doing this using the powerful and handy uninstall.php file.

There are numerous ways to add custom content to your WordPress feeds. If you’re not using a plugin, it’s possible to just add a code snippet to your theme’s functions.php file. For most cases, I think probably going the plugin route is the easiest way to add custom content to your WordPress RSS/feeds. Just install, activate, add your content and done. But for WordPress developers and designers who want more fine-grained control, this article explains how to add custom feed content programmatically using the WP API. So whether you need to add copyright text, advertisements, hyperlinks, or virtually anything at all, this post explains how to make it happen.

One of the few regrets anyone can have in an online business is the failure to collect email addresses of their visitors. Simply put, the failure to have a list.
More often than not, you will hear people say, “the money is in the list” and that by itself is a statement of truth. Email list gets people coming back to your website, and by extension increases profit in business, because you are already dealing with a targeted audience.

One of the most annoying things in the WordPress universe are plugins and themes that don’t conditionally load their scripts and styles (i.e., JavaScript and CSS files). For example, you install a dashboard plugin and it loads its scripts in the entire Admin Area and the frontend. Instead, the developer should have used conditional logic to NOT load the script on the frontend (e.g., via !is_admin()), or anywhere in the Admin Area EXCEPT the dashboard (e.g., via get_current_screen()). It’s just basic human decency.

Just to be crystal clear, this post is all about displaying basic statistics about your site, not about your visitors. So if you are thinking something like, “duh, just use Google Analytics or whatever,” then imagine a giant buzzer sound telling you that you’re incorrect. Sure, Google Analytics gives you information about your visitors, like how many, where from, how long, and so forth. But GA et al do NOT provide information about your site itself. Things like the number of registered users, number of posts and pages, number of comments, and all the other cool little details about your site. That is what we’ll be covering in today’s DigWP tutorial. So grab some popcorn and enjoy the show! ;)

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!

During the latest site redesign, I removed the Subscribe to Comments plugin. Wisely, the plugin does not delete any subscriber information from the database. So as a part of the site’s redesign slash clean-up, I wanted to export/save and then delete all subscriber information to decrease overall database size. After searching and not finding any specific solution or preferred technique for this process, I rolled my own. Actually it’s just a simple SQL query to get it done! :)