The Difference Between Taxonomies, Categories, and Tags (Oh My!)

Category Image 052

A common question for new WordPress users is, “what’s the difference between categories and tags?” Like everyone knows what a “category” is, but the idea of “tags” can seem very similar. And then you throw in related WordPress concepts like “taxonomy”, and things can get confusing very quickly. But no worries, it’s really not that complicated. Let’s break it down..

Contents

Taxonomies

In WordPress, Taxonomies are used to organize posts. There are different types of taxonomies. The two most familiar types of Taxonomies are Categories and Tags. Both are enabled by default when you install WordPress. So when you create a post, you can choose which categories and tags should be assigned.

Currently, WordPress provides three taxonomies by default:

  • Categories – hierarchical taxonomy
  • Tags – non-hierarchical taxonomy
  • Post Formats – non-hierarchical taxonomy

In addition to these default taxonomies, a WordPress site also may support some Custom Taxonomies that are provided by plugins. For example, an e-commerce plugin may add custom taxonomies for things like “Product Type”, “Price Range”, “Brand Name”, or any other attribute. And for each of these taxonomies, you can add any number of terms.

Note: You can learn more about Post Formats at WordPress.org.

Notice in the above list of default taxonomies, that Categories are hierarchical while Tags are not. This means that categories can have sub-categories (aka child categories), like this:

  • Hats
  • Shirts
  • Pants
  • Shoes
    • Fast shoes
    • Slow shoes
    • Nice shoes
      • Smooth shoes
      • Fancy shoes
      • Funny shoes

Categories can have as many sub-categories as needed. Tags on the other hand, are non-hierarchical, so there are no child tags or grandchild tags. It’s a “flat” taxonomy. Further, any custom taxonomies may be either hierarchical or non-hierarchical, depending on how they are configured.

Note: Some themes also provide their own custom taxonomies, although they shouldn’t. According to WordPress best practices, adding custom taxonomies is “plugin territory”. Only plugins should provide custom taxonomies.

Simple example

To illustrate, say we have a post that describes a store product, like shoes. It might have the following taxonomies (left column) and terms (right column):

Post = Shoes that don't leave any footprints

	Category:      Store
	Tags:          stealth, speed
	Product Type:  shoes
	Price Range:   $100-$300
	Brand Name:    Rolf Ahl

This shows how taxonomies are used to define relationships between posts. So on the front end, visitors can sort items based on their category, tags, product type, and so forth. Indeed, any Aspect of your posts can be classified and organized with taxonomies.

Real-world example

To check out an effective use of taxonomies, visit Amazon.com and do a search for something like “shoes”. Then look in the sidebar at all the different ways to sort the results. Each of those sidebar sections (like “Shoe Size” and “Shoe Width”) are added via custom taxonomies. Amazon doesn’t actually run on WordPress, but it’s a great example of taxonomies.

Search results for 'shoe' at Amazon.comAll the sidebar options are examples of custom taxonomies.

As shown here, taxonomies enable your visitors to easily sort through your posts and find related and similar content.

Categories vs. Tags

As discussed, both Categories and Tags are types of Taxonomies. The only technical difference is that Categories are hierarchical, while Tags are not. So with categories, you can create sub-categories (or child categories). With tags, you cannot. Tags always have a “flat” organizational structure.

Other than that, the main difference between Categories and Tags has to do with scope. With WordPress:

  • Categories are used to broadly organize posts into groups
  • Tags are used to denote any specific post characteristics

I know that’s a bit abstract, so let’s go through some “real-world” examples..

Categories: real-world example

Let’s say it’s our job to clean up a house that has tons of junk in it. There are piles of stuff all over the place, and it’s our job to go in there and clean it all up. First we create two piles: “stuff that stays”, and “stuff that goes”. Those two piles represent categories.

After hauling away the “stuff that goes” pile, it’s time to organize the “stuff that stays”. Again, we use categories to make things easier. There are many ways we could categorize all the remaining items. We could organize by room, so our categories would be like:

  • Living Room
  • Kitchen
  • Bathroom
  • Bedroom

Makes sense, right? It’s the same idea with WordPress posts. Categories simply group similar types of posts together. For the purpose of organizing content and making it easier for visitors to find.

Categories: another example

Generally categories represent broad similarities among items, but you can get as specific as you’d like. For example, it’s common for a web-development site to group posts into the following categories:

  • CSS
  • HTML
  • PHP
  • JavaScript
  • Etc.

..such that each coding language gets its own category. That’s gonna keep posts broadly organized based just on the language. All posts about CSS go into the “CSS” category. All posts about HTML into the “HTML” category, and so forth.

But you can get more specific with categories. Say our tutorial site has a LOT of posts on all the coding languages. We might want to refine our categories to include version information, for example:

  • CSS
    • CSS 1.0
    • CSS 2.0
    • CSS 3.0
  • HTML
    • HTML 4.0
    • HTML 5.0
  • Etc.

Because categories can be hierarchical, we can get as specific or as broad as is necessary to organize your posts. And to organize things even further, we can throw tags into the mix..

Tags: real-world example

Returning to our “hoarder house” example, let’s look at how we can use tags to help further organize things. Recall that all the stuff currently is organized by room. So our categories are:

  • Living Room
  • Kitchen
  • Bathroom
  • Bedroom

In each room, we can further organize things by adding a tag to each item. For example, we tag the “chairs”, “tables”, “desks”, “electronics”, “clothes”, “food”, “towels”, and so on. And the nice thing about tags is that they can be added across categories. There may be “chairs” in both Living Room and Kitchen categories. Or there may be “electronics” in all categories. So when visitors arrive at your house, they can click the “food” tag and eat all of your food, regardless of which room it’s in :)

10-second summary

The difference between Taxonomies, Categories, and Tags:

  • Taxonomies are used to organize posts. WordPress provides two default Taxonomies: Categories and Tags. It’s also possible to create Custom Taxonomies. Taxonomies may be hierarchical or non-hierarchical.
  • Categories are used to broadly organize posts into groups. Categories may have a hierarchical structure.
  • Tags denote any specific post characteristics. Tags are non-hierarchical, flat organizational structure.

Resources


How to Prevent Changes to Plugins, Themes, and WordPress Core Files

Category Image 091

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..

Contents

Prevent Changes via File Editor

Did you know that WordPress provides a Plugin File Editor and Theme File Editor in the WP Admin Area. You can find them:

  • Under the Appearance menu ▸ Theme File Editor
  • Under the Plugins menu ▸ Plugin File Editor

These tools enable admins to make changes to any plugin or theme files. Huge convenience for those that need it. For those that don’t, you can disable any changes via the file editors by adding the following line to your site’s wp-config.php file, which resides in the root WordPress directory:

// disable file changes via plugin and theme editors
define('DISALLOW_FILE_EDIT', true);

Once this line is included in the site’s configuration file, all file-editing via the Admin Area will be disabled. No menu items, no editing, nada. It’s another layer of security that effectively minimizes your site’s attack surface, so sensitive files cannot be modified by any user, including admins. This helps to protect against any changes that could compromise or crash your site.

Note: As explained at WordPress.org, disabling the file editors via DISALLOW_FILE_EDIT constant may affect any plugins that check for sufficient capabilities using current_user_can('edit_plugins'). Plugins should check if the constant is set, and if so display an appropriate error message.

Prevent All Changes via Admin Area

While the previous technique disables changes to plugins and themes via the file editors, this next technique prevents all changes to any files from inside the Admin Area. This includes:

  • Updating, deleting, installing plugins
  • Updating, deleting, installing themes
  • Updating the WordPress core files

It also includes changes made via the plugin and theme file editors. Basically this technique staticizes a site to its current version. So if that sounds like you, here is the magic code to lock it down:

// disable all changes to all files via admin area
define('DISALLOW_FILE_MODS', true);

Once this line is included in the site’s configuration file, all changes (installing, updating, deleting) to plugins and themes will be disabled. Note that the above line also disables updates to the WordPress core files, so trying to update WordPress via Dashboard ▸ Updates will not work.

Of course, it always is possible for changes to be made directly on the server via SFTP or similar method. But any file changes from within the Admin Area will be disabled completely.

Note: As mentioned, the above line disables all changes from anywhere within the Admin Area, including the file editors. So you do not need to set both DISALLOW_FILE_MODS and DISALLOW_FILE_EDIT. Just including DISALLOW_FILE_MODS takes care of everything.
Note: Be careful when adding DISALLOW_FILE_MODS to your site’s wp-config.php file. WordPress needs to be able to make changes in order to keep plugins, themes, and core files current via updates. So only disable changes if you are 100% certain that you don’t want any updates on your WordPress site.

Round Up: 18 Free Plugins to Help Troubleshoot and Debug WordPress

Category Image 036

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.

Plugins to troubleshoot & debug WordPress

There are TONS of great troubleshooting plugins available at the WordPress.org Plugin Directory. Some of these plugins you’re probably familiar with, others are newer with their own unique features. While nobody is gonna need all of these plugins, it is comforting that there are so many to choose from. So you can find the best tools for whatever inspecting or debugging is needed. Plus all of these plugins are open source and 100% free. So without further ado..

BugFu Console Debugger
Handy plugin that enables logging of PHP directly via the browser console. Can be a huge time saver for developers.
Code Profiler
Measures the performance of your plugins and themes at the PHP level. Finally a replacement for the once-great P3 Profiler.
Debug
Handles the configuration of debug and other variables via wp-config.php. So you don’t have to edit the file manually.
Debug Bar
Adds a debug menu to the admin bar that shows query, cache, and other debugging information. Super useful tool for analyzing performance.
Debug Info
Provides important details about your WordPress operating environment. Easy way to get PHP configuration (via phpinfo()).
Debug Log Manager
Provides all sorts of tools for managing your site’s debug logs and more. Another massive time-saving tool.
Debug This
Displays lots of details about your WordPress site via the admin bar. Reveals “under the hood” what’s happening on each page.
Log HTTP Requests
Incredibly useful plugin for measuring and logging outgoing HTTP requests. One of my favorite plugins when developing.. other plugins :)
Plugin Detective
Holds your hand through the process of troubleshooting your site. Could be super useful depending on your workflow.
Query Monitor
Enables debugging of database queries, PHP errors, hooks, and much more. Hands down one of the best plugins for debugging WordPress.
System Dashboard
Monitors WordPress components, processes, server hardware, software, and resource usage. A must-have for serious WordPress developers.
Variable Inspector
Enables you to inspect various PHP variables via the dashboard in the WP Admin Area. Huge time-saver when working with PHP variables.
WP Console
Adds PsySH runtime developer console, interactive debugger and REPL. Write code and view the output right in your browser.
WP Crontrol
Enables you to view and control what’s happening in the WP-Cron system. Excellent plugin and highly recommended.
WP Debug Log
Enables you to check the debug log from the dashboard and optionally send email notifications. Looks super useful for debugging with WordPress.
WP Debugging
Adds the requisite PHP constants to the wp-config.php file to enable debugging. So you don’t have to edit the file manually.
WPPerformanceTester
Measures performance of your WordPress site. Looks interesting and useful but hasn’t been updated in a while.
WordPress Hosting Benchmark tool
Tests the performance of your server and compares with results from other servers. A great tool for diving deeper into server performance.
Explore even more debug tools..
The WP Plugin Directory is loaded with many plugins for developing, troubleshooting, and debugging your site. Try a few searches and browse the results. All free and open source. Amazing.
Shouts out to the developers working to provide these free tools to the WordPress community. Your work is important and appreciated.

Note: WordPress plugins tend to change over time, usually for the better but not always. So to be safe, make sure to check the official homepage/docs for more details before trying any of the above plugins. If anything should or should not be on the list, please let us know so we can update the post. Thank you!

Props

Gotta give props here. I was inspired to put this round up together after seeing this post in David McCan’s Dynamic WordPress group on Facebook. Check it out for some interesting comments and more ideas for troubleshooting your WordPress-powered websites.

Cheers! 😎


Stay Logged in to WordPress

Category Image 091

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.

Here are three easy ways to stay logged in to WordPress for a longer period of time.

Three ways to do it..

Check the box

The easiest way to increase the expiration date/time for logins, is to simply check the “Remember Me” checkbox when logging in to WordPress. That will increase the expiration to 14 days, or whenever the browser is closed. After that time, the session cookie expires and you’ll need to log in once again.

This is useful if 14 days is enough time for your workflow.

One downside is that it requires an extra click to check the box. Fine I guess if you’re logging in manually. But if you’re using a password manager or other auto-login app, the extra checkbox step requires action on your part, thus adding friction and slowing things down.

Another downside is that 14 days is not always enough. For my own workflow, I prefer to minimize as many needless steps as possible. So I prefer the next method of extending the login duration, using a slice of custom code..

Add custom code

For more flexibility and less friction, you can add the following code snippet to stay logged in to WordPress for however long is necessary, even indefinitely if it makes sense to do so. This is the preferred technique for my own websites.

Important: Be mindful of any other users who may be logging in on public machines. Only extend the login duration if you know 100% that it’s safe and secure.

Here is the magic code to stay logged in to the WordPress Admin Area. You can add this code via your theme functions file, or add via simple custom plugin. Here is a guide that explains how to do both.

function shapeSpace_stay_logged_in($expires) {
	
	return 172800; // default 48 hours
	
}
add_filter('auth_cookie_expiration', 'shapeSpace_stay_logged_in');

As written, this code hooks into auth_cookie_expiration and filters the expiration duration (in seconds). By default the duration is 48 hours. You can change that to anything that works best.

To stay logged in forever, change the interval to some very large number, like 3153600000 to stay logged in for 100 years ;) To help with converting time to seconds, you can use a free time conversion calculator.

Thanks to Alex Mills (Viper007Bond) for sharing this code at Stack Exchange.

Update! Thanks to Scott Fennell for pointing out that WordPress provides a set of time constants that we can use instead of typing out seconds like animals:

MINUTE_IN_SECONDS
HOUR_IN_SECONDS
DAY_IN_SECONDS
WEEK_IN_SECONDS
MONTH_IN_SECONDS
YEAR_IN_SECONDS

So we can do like 3 * HOUR_IN_SECONDS to specify a time interval of 3 hours.

Bonus: Check the “Remember” box by default

Bonus tip! To automatically check the “Remember Me” box on the WP Login Page, add the following code via theme functions or custom plugin.

function shapeSpace_custom_login_checkbox() {
	
	?>
	
	<script>
		document.getElementById('rememberme').checked = true;
		document.getElementById('user_login').focus();
	</script>
	
	<?php
	
}
add_filter('login_footer', 'shapeSpace_custom_login_checkbox');

No changes need made, just add and done. One in place, the remember checkbox will be selected automatically by default.

Install a plugin

If you want to extend the login beyond 14 days, but don’t want to go the custom code route, installing a plugin is the way to go. Currently there seems to be only a couple of capable plugins in the WP Plugin Directory:

Let me know if I’ve missed anything! :)


Subscribers: Update Your Feed URLs

Category Image 035

To our feed subscribers. In case you haven’t heard. Feedburner is dead man walking. As a result, we changed our RSS and Atom feed URLs to host them directly at DigWP.com. So if you want to continue getting our awesome WP-related content delivered to your feed reader, take a moment to update your feed URLs. Our new (and permanent) feed URLs:

Visit the DigWP Archives for more feed options.

Direct link to article | View post at DigWP.com

How to Add Custom Code to WordPress

Category Image 091

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:

Add this code to your theme (or child theme’s) functions.php file, or add the code via simple custom plugin.

So what does that actually mean? Let’s take a closer look. First we’ll go through how to add custom code via the functions.php file. Then we’ll explain how to add code by making a simple custom plugin. Finally we’ll wrap things up by explaining the difference between the two methods and how to go further.

Contents

Add custom code via theme functions.php

Every WordPress theme can have a file named functions.php. If present in a theme, the functions file must be located in the root directory of the theme:

/wordpress/
	/wp-content/
		/themes/
			/my-theme/
				functions.php

If the functions file does not exist, create it. Then open the file in a code or text editor and add your custom code. Save the file, upload to the server, and done. It is very straightforward. Just make sure to test any new code on a private/test site before adding to a live production site.

Learn more about building themes in my book, WordPress Themes In Depth.

Add custom code via simple custom plugin

With WordPress, plugins add functionality, and themes display content. There is some overlap (and grey area), but in general the best way to add functionality to WordPress is with a plugin. That’s one reason why there are over 50,000 plugins in the WordPress Plugin Directory.

Plugins range in complexity. They can be very advanced, comprising many files and lots of code. Or they can be very simple, made with one file and a few lines of code. To add a custom code snippet, a simple plugin will suffice.

How to make a simple custom plugin

To make a simple custom plugin, follow these steps:

  1. Create a new PHP file
  2. Name the file whatever makes sense, can be any alphanumeric string (plus dashes and underscores if needed)
  3. Open the file and add the header code provided below
  4. Save the file and done

After creating this file, it is ready for your custom code snippet(s). To save you some time, I’ve created an example plugin that you can download below. It’s ready to go for any custom code that you want to add.

Download a simple custom plugin

Download a copy of our simple custom plugin, ready for your custom code.

Download Simple Custom Plugin (ZIP file < 1 KB)

Usage: Download and unzip the file. Open simple-custom-plugin.php and customize the file header as explained below. Then add your custom code snippet, save changes and done.

Plugin file header

At the beginning of your plugin file, add the following lines:

<?php 
/*
	Plugin Name: Simple Custom Plugin
	Plugin URI: https://digwp.com/2022/02/simple-custom-plugin/
	Description: This is a simple plugin template for adding custom code to WordPress.
	Author: Jeff Starr
	Author URI: https://plugin-planet.com/
	Requires at least: 5.9
	Tested up to: 5.9
	Version: 1.0
*/

if (!defined('ABSPATH')) die();

// add custom code snippets below this line..

You can customize the header lines with your actual information. As our simple plugin is meant only for your site and will not be distributed publicly, the file header can be much simpler than what’s required for plugins destined for the WP Plugin Directory. Learn more about plugin file headers at WordPress.org.

Also: notice this line:

if (!defined('ABSPATH')) die();

That line is included to prevent direct access to the file. It basically checks if WordPress is loaded; if not, the script simply exits. This is a basic security measure to help prevent anyone from meddling with your custom code.

Remember to use code snippets only from trusted sources. And then test the code on a private site before going live.

What’s the difference?

What’s the difference between adding code via theme functions vs. simple plugin? The main difference is scope. When code is added via your theme template, it will run only when the theme is active. So for example, say we add a custom code snippet that displays social media buttons on posts. If we change themes, the custom code will not run, and the buttons will not be displayed.

Contrast that with adding custom code via simple plugin. As long as the plugin is active, the custom code will run always, regardless of which theme you’re using. Going the plugin route also benefits in terms of things like extensibility and maintainability. Managing custom code via plugins generally is easier than burying it within the theme’s functions file.

So which is best? Neither. The two methods are just different. Which one is best for any given code snippet depends on various factors. Most importantly whether or not the custom code is theme specific or global in scope.

For an easy, no-fuss way to add custom code snippets, check out WPCodeBox.

Going further..

The above simple plugin example is the most basic possible. To go further with plugin development, visit the Plugin Developer Handbook at WordPress.org.

Questions and comments welcome! :)


Migrating Book Accounts

Category Image 035

Heads up! We’re migrating all book accounts to the new bookstore at Perishable Press Books. This will make it easier to manage everything under one roof. To transfer your account to the new site, send a quick email and let us know 1) the site/URL where you purchased the book (e.g., DigWP.com), and 2) your registered username or email address. Thank you!

Direct link to article | View post at DigWP.com

How to Disable Gutenberg Styles on the Frontend

Category Image 091

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.

Bonus: Disable Gutenberg plugin also enables restoring of Classic Widgets!

Why?

One reason why people may want to remove extraneous/unnecessary CSS/stylesheets from loading is improved site performance. So by disabling the Gutenberg CSS when it’s not needed, that’s one less asset that needs to load for every page request. That can have a huge cumulative effect on the performance of your WordPress site.

FYI the default Gutenberg stylesheet looks like this when included in the source code of your web pages:

<link rel='stylesheet' id='wp-block-library-css'  href='https://example.com/wp-includes/css/dist/block-library/style.min.css' type='text/css' media='all' />

So you know what to look for.

Disable Gutenberg styles on the front-end

Without further ado, here is the magic code snippet sauce to add to your WordPress-powered site. You can add this code using a plugin such as Code Snippets, or you can add directly via theme (or child theme) functions.php, or add via simple custom plugin. Many ways to add the following code:

// disable gutenberg frontend styles @ https://m0n.co/15
function disable_gutenberg_wp_enqueue_scripts() {
	
	wp_dequeue_style('wp-block-library');
	wp_dequeue_style('wp-block-library-theme');
	
}
add_filter('wp_enqueue_scripts', 'disable_gutenberg_wp_enqueue_scripts', 100);

This script disables the default Gutenberg stylesheet wp-block-library, and it also disables the theme-specific Gutenberg stylesheet (if applicable) wp-block-library-theme. That’s all it does, plain and simple.

Note: To re-enable the Gutenberg styles, simply remove the above code snippet.

Bonus: Disable other block stylesheets

In general, any WordPress stylesheet can be disabled using the WP core function, wp_dequeue_style(). For example, if you are using WooCommerce and the Storefront theme, you may want to prevent their related Gutenberg Block CSS/stylesheets from loading on the front-end. To do it, modify the previous code snippet so it looks like this:

// disable gutenberg frontend styles @ https://m0n.co/15
function disable_gutenberg_wp_enqueue_scripts() {
	
	wp_dequeue_style('wp-block-library');
	wp_dequeue_style('wp-block-library-theme');
	
	wp_dequeue_style('wc-block-style'); // disable woocommerce frontend block styles
	wp_dequeue_style('storefront-gutenberg-blocks'); // disable storefront frontend block styles
	
}
add_filter('wp_enqueue_scripts', 'disable_gutenberg_wp_enqueue_scripts', 100);

The wp_dequeue_style() function is what’s doing all the work here. It is very effective and can be used to disable any stylesheet that is registered with WordPress. Check the docs at WordPress.org for more details.

One for the road..

The code techniques so far are kept very minimal for the sake of clarity. But as you probably know, there is much more that can be done when customizing asset loading and so forth. For example, you can add conditional logic so the stylesheets will be disabled only under certain conditions.

To give you an idea of the possibilities, here is a “real-world” example showing how Disable Gutenberg conditionally disables the front-end styles depending on user preference in the plugin settings.

// disable gutenberg frontend styles @ https://m0n.co/15
function disable_gutenberg_wp_enqueue_scripts() {
	
	global $wp_query;
	
	if (is_admin()) return;
	
	$post_id = isset($wp_query->post->ID) ? $wp_query->post->ID : null;
	
	$options = get_option('disable_gutenberg_options');
	
	$enable = isset($options['styles-enable']) ? $options['styles-enable'] : false;
	
	if (!$enable && !disable_gutenberg_whitelist($post_id)) {
		
		wp_dequeue_style('wp-block-library');
		wp_dequeue_style('wp-block-library-theme');
		
	}
	
}
add_filter('wp_enqueue_scripts', 'disable_gutenberg_wp_enqueue_scripts', 100);

Again this is just an example taken from an actively developed plugin. So much more is possible, as WordPress core provides all sorts of useful functions with which to work. So have fun and build something creative :)

Note: The above code snippet taken from the Disable Gutenberg plugin is for example purposes only; so don’t try to use it on any live site. Instead if you want to explore, download the plugin and examine the source code.

Related Posts

More of our posts on Gutenberg Block Editor:


TasteWP FTW

Category Image 035

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.

Direct link to article | View post at DigWP.com