By default the Gutenberg Block Editor loads its default CSS/stylesheet on the front-end of your WordPress site. This is fine for most cases, but there may be situations where you want to disable the Gutenberg styles for whatever reason. For example, my free WordPress plugin, Disable Gutenberg, enables users to disable the Gutenberg Block Editor and restore the Classic Editor. Included in the plugin settings is an option called “Enable Frontend” that lets users enable or disable the Gutenberg CSS/styles as desired. This quick DigWP tutorial explains programmatically how to disable Gutenberg styles on the front-end.
Digging WordPress serving the community online since May 27th, 2009 :)
Thanks to David McCan over at WebTNG for his in-depth review of my WordPress firewall plugin, BBQ Pro. It’s a pleasure to read and packed with plenty of awesome screenshots :)
Thank you to the fine folks at ThemeIsle for the great interview. Always a pleasure talking about my work, WordPress, web dev and security :) Cheers!
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.
TasteWP enables anyone to setup a test/temporary WordPress instance in seconds. So you can play around and do things like test plugins on a live site. I know this kind of thing has been done before, but I’ve never seen it made SO EASY. Like stupid easy. And FREE. Awesome tool.
Excellent in-depth article from Chris about all the ways to develop WordPress themes in 2021 (and beyond).
Had a great interview with Eric Karkovack at Speckyboy magazine. Goes deep into WordPress, web development, security, future of things, and other key topics. Grab a beverage and check it out! :)
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.
Book updates! New versions of all books including Digging Into WordPress now available for download. As always, updates are FREE for all book owners :)
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.