If you are a WordPress developer, you may have used the WordPress hook wp_print_scripts to add any necessary inline JavaScript. Alternately, you may have used the function wp_localize_script() to add your inline scripts. But did you know that not too long ago, WordPress added a new function for adding inline JavaScript? Yep, as of WordPress version 4.5 and better, we can use the superior function wp_add_inline_script() to do the job.

One of the nice things about this newer function is that you can associate it with any registered script AND include more than just JavaScript variables. This DigWP article explains how wp_add_inline_script() works, why it’s better than either of the alternate inline methods, and how to support older (pre-4.5) versions of WordPress. Along the way, we’ll look at some example code that you can customize and use in your own WordPress projects.

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! :)

I think many WordPress users probably underestimate the amount of data that is made available via the REST API. Just about everything is available to anyone or anything that asks for it: posts, pages, categories, tags, comments, taxonomies, media, users, settings, and more. For most of these types of data, public access is useful. For example, if you have a JSON-powered news reader, it can basically replicate your entire site structure virtually anywhere. But that easy access invites potential abuse. Just like with RSS feeds, RESTfully delivered JSON content is easily scraped and used for spam, phishing, plagiarism, adsense, and other foul things.

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.

With each passing day, strong security becomes more important. This article explains some ways to keep WordPress secure while improving the overall security of your WordPress-powered site. Most of the tips provided here are practice-based security steps that require no plugins or hacks. The idea here is that you don’t need to make changes to any code, or modify WordPress in any way in order to maintain strong security. These are security steps that most any WordPress user can use to help protect their site and keep WordPress safe and secure.

The WordPress Toolbar makes it easy for plugin and theme developers to add links and other items. This is great news if you find the added links useful; otherwise, the additional links may be more of a nuisance, cluttering up your current workflow. For example, the database-backup plugin UpdraftPlus adds an “UpdraftPlus” link. Some users probably think this is awesome, but for my own sites it’s just not necessary, and is something I would like to remove. So for this DigWP tutorial, we’ll use the UpdraftPlus Toolbar link to demonstrate how to remove unwanted items from the WordPress Toolbar in general.

As you work in the WordPress Admin Area, you’ll undoubtedly encounter “admin notices” that let you know about errors, updated settings, required actions, and so forth. Most default admin notices are provided by WordPress out of the box, but it’s up to plugins and themes to provide any custom notices that may be required. This DigWP tutorial digs deep into WordPress admin notices and explains how to implement, customize, and everything in between.

Working on the 2020 theme for my book, WordPress Themes In Depth, I noticed that WordPress was including a stylesheet from the Google API. Closer examination revealed that the styles were adding the Open Sans font via Google Fonts. The font itself is great, but I could not figure out where/how/why it was being added to the markup. This quick post explains what was happening and how to disable it.

Continuing with tips for customizing the WordPress Dashboard, here is a look at one way to remove unwanted widgets and clean up the default WP Dashboard.

After updating to WordPress 3.8, the single-column Dashboard disappears with no options to bring it back. For years, users could set the number of columns in the Dashboard to suit their needs, but apparently some brilliant decision was made to just remove it. Personal opinions and feelings aside, here is a quick snippet to bring back single-column Dashboard layout for those who were using it and wish to continue doing so.

The new background updates feature in WordPress 3.7 is great for security and productivity, but it can be tricky getting it to work. This post explains how the same technique posted here also worked for enabling background updates.