Posts tagged: tips
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.
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.
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.
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.
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
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.
If you are a WordPress developer, you may have used the WordPress hook
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’.