Loading...

Follow Digging Into WordPress | Take your WordPress sk.. on Feedspot

Continue with Google
Continue with Facebook
or

Valid

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!

Update! To selectively enable Gutenberg only on certain posts, you can do it without touching any code. My free plugin Disable Gutenberg now provides whitelist options to always use Block Editor on any post IDs, slugs, or titles :)
First: Disable Gutenberg by default

In WordPress 5.0 and beyond, Gutenberg is enabled by default. So if you want to enable Gutenberg everywhere, you don't need to do anything: it just works.

Otherwise, if you want to enable Gutenberg only on specific post IDs, post types, and so forth, you will need to first disable Gutenberg everywhere. To do this, we can use either of the following filter hooks (depending on WP version):

// WP < 5.0 beta
add_filter('gutenberg_can_edit_post', '__return_false', 5);

// WP >= 5.0
add_filter('use_block_editor_for_post', '__return_false', 5);

So choose either or both of these hooks (to support all versions of WP), and add to your theme's functions.php. Or, if you would rather disable Gutenberg and restore the Classic Editor using a plugin, check out Disable Gutenberg, which is super lightweight, flexible, and easy to customize exactly where Gutenberg should be disabled on your site. However you choose to disable Gutenberg, you will need to do so in order for the following techniques to work properly.

Tip: Notice the third parameter (5) in the two filters above? Setting that value makes it possible to override and enable Gutenberg using techniques such as the ones provided below.
Enable Gutenberg for any Post IDs

Once Gutenberg is disabled everywhere, here is an example showing how to enable it only for specific post IDs:

function shapeSpace_enable_gutenberg_post_ids($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	if (1 === $post->ID) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post', 'shapeSpace_enable_gutenberg_post_ids', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post', 'shapeSpace_enable_gutenberg_post_ids', 10, 2);

As written, this function will enable Gutenberg on post ID = 1. You can change that as needed in the third line of the function.

Tip: To selectively disable Gutenberg on any post, role, type, and so forth, check out my previous tutorial, How to Disable Gutenberg: Complete Guide.
Enable Gutenberg for new posts

To enable Gutenberg for all new posts, you can do something like this:

function shapeSpace_enable_gutenberg_new_posts($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	$current = get_current_screen();
	
	if ('post' === $current->base && 'add' === $current->action) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post', 'shapeSpace_enable_gutenberg_new_posts', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post', 'shapeSpace_enable_gutenberg_new_posts', 10, 2);

As written, this function checks if the user is viewing the post-new.php screen, and if so returns true (to enable Gutenberg).

Tip: Notice the 10 value that these techniques are passing via the add_filter hooks. Why? Remember we set that parameter to 5 when we disable Gutenberg, so by setting it to 10 or any value greater than 5, we easily override the disabling function and thereby enable Gutenberg. It's all about hook priority!
Enable Gutenberg for specific Post Meta

What about enabling Gutenberg Block Editor only on posts that have some specific meta data attached? Easy, here is an example showing how to do it:

function shapeSpace_enable_gutenberg_post_meta($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	if ('Happy' === get_post_meta($post->ID, 'current_mood', true)) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post', 'shapeSpace_enable_gutenberg_post_meta', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post', 'shapeSpace_enable_gutenberg_post_meta', 10, 2);

As written, this function checks the current post for a custom field named current_mood with a value of Happy. If it exists, the function then returns true to enable Gutenberg for that post. Note that these examples are kept as simple as possible to help understanding. Much more is possible!

Tip: Notice that we hook the function name into both Gutenberg filter hooks: gutenberg_can_edit_post and use_block_editor_for_post. This means that the function will run in all applicable versions of WordPress. So if you are not worried about supporting older or newer versions of WordPress, you can simply remove one or the other add_filter() functions and done.
Enable Gutenberg for specific categories

Here is an example showing how to enable Gutenberg only for specific categories:

function shapeSpace_enable_gutenberg_post_cats($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	if (has_category(12)) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post', 'shapeSpace_enable_gutenberg_post_cats', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post', 'shapeSpace_enable_gutenberg_post_cats', 10, 2);

As written, this function uses WP's has_category() to check if the current post belongs to category 12; if so, true is returned thereby enabling Gutenberg. Of course, you can specify your own category or array of categories, or whatever.

Tip: To check if the current post contains any Gutenberg blocks, we can add this logic to any of our enabling functions: if (has_blocks($post)) return true;
Enable Gutenberg for specific tags

Here is an example showing how to enable Gutenberg only for specific tags:

function shapeSpace_enable_gutenberg_post_tags($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	if (has_tag(50)) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post', 'shapeSpace_enable_gutenberg_post_tags', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post', 'shapeSpace_enable_gutenberg_post_tags', 10, 2);

As written, this function uses WP's has_tag() to check if the current post is tagged with tag ID = 50; if so, true is returned thereby enabling Gutenberg. Of course, you can specify your own tag or array of tags.

Tip: Notice the 3rd parameter, 2, passed to either of the add_filter() functions. That specifies the number of parameters passed to the hooked function, which in this case is shapeSpace_enable_gutenberg_post_tags. So if you look at that function, you will see that it accepts two parameters, $can_edit and $post.
Enable Gutenberg for any Post Type

One more for the road! Here is an example showing how to enable Gutenbeg only for specific post types:

function shapeSpace_enable_gutenberg_post_type($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	if ('books' === $post_type) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post_type', 'shapeSpace_enable_gutenberg_post_type', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post_type', 'shapeSpace_enable_gutenberg_post_type', 10, 2);

This function is similar to the others, but hook-wise it does something a bit differently. When working with post types, WordPress/Gutenberg provide the following filter hooks for working with Post Types:

// WP < 5.0 beta
gutenberg_can_edit_post_type

// WP >= 5.0
use_block_editor_for_post_type

So we use these recommended hooks to enable Gutenberg for specific post types. Note also that our function currently checks the current post type. As written, it checks for a post type named books; feel free to modify as needed to suit your needs. The possibilities are endless!


Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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!

First: Disable Gutenberg by default

In WordPress 5.0 and beyond, Gutenberg is enabled by default. So if you want to enable Gutenberg everywhere, you don't need to do anything: it just works.

Otherwise, if you want to enable Gutenberg only on specific post IDs, post types, and so forth, you will need to first disable Gutenberg everywhere. To do this, we can use either of the following filter hooks (depending on WP version):

// WP < 5.0 beta
add_filter('use_block_editor_for_post', '__return_false', 5);

// WP >= 5.0
add_filter('use_block_editor_for_post', '__return_false', 5);

So choose either or both of these hooks (to support all versions of WP), and add to your theme's functions.php. Or, if you would rather disable Gutenberg and restore the Classic Editor using a plugin, check out Disable Gutenberg, which is super lightweight, flexible, and easy to customize exactly where Gutenberg should be disabled on your site. However you choose to disable Gutenberg, you will need to do so in order for the following techniques to work properly.

Tip: Notice the third parameter (5) in the two filters above? Setting that value makes it possible to override and enable Gutenberg using techniques such as the ones provided below.
Enable Gutenberg for any Post IDs

Once Gutenberg is disabled everywhere, here is an example showing how to enable it only for specific post IDs:

function shapeSpace_enable_gutenberg_post_ids($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	if (1 === $post->ID) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post', 'shapeSpace_enable_gutenberg_post_ids', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post', 'shapeSpace_enable_gutenberg_post_ids', 10, 2);

As written, this function will enable Gutenberg on post ID = 1. You can change that as needed in the third line of the function.

Tip: To selectively disable Gutenberg on any post, role, type, and so forth, check out my previous tutorial, How to Disable Gutenberg: Complete Guide.
Enable Gutenberg for new posts

To enable Gutenberg for all new posts, you can do something like this:

function shapeSpace_enable_gutenberg_new_posts($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	$current = get_current_screen();
	
	if ('post' === $current->base && 'add' === $current->action) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post', 'shapeSpace_enable_gutenberg_new_posts', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post', 'shapeSpace_enable_gutenberg_new_posts', 10, 2);

As written, this function checks if the user is viewing the post-new.php screen, and if so returns true (to enable Gutenberg).

Tip: Notice the 10 value that these techniques are passing via the add_filter hooks. Why? Remember we set that parameter to 5 when we disable Gutenberg, so by setting it to 10 or any value greater than 5, we easily override the disabling function and thereby enable Gutenberg. It's all about hook priority!
Enable Gutenberg for specific Post Meta

What about enabling Gutenberg Block Editor only on posts that have some specific meta data attached? Easy, here is an example showing how to do it:

function shapeSpace_enable_gutenberg_post_meta($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	if ('Happy' === get_post_meta($post->ID, 'current_mood', true)) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post', 'shapeSpace_enable_gutenberg_post_meta', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post', 'shapeSpace_enable_gutenberg_post_meta', 10, 2);

As written, this function checks the current post for a custom field named current_mood with a value of Happy. If it exists, the function then returns true to enable Gutenberg for that post. Note that these examples are kept as simple as possible to help understanding. Much more is possible!

Tip: Notice that we hook the function name into both Gutenberg filter hooks: gutenberg_can_edit_post and use_block_editor_for_post. This means that the function will run in all applicable versions of WordPress. So if you are not worried about supporting older or newer versions of WordPress, you can simply remove one or the other add_filter() functions and done.
Enable Gutenberg for specific categories

Here is an example showing how to enable Gutenberg only for specific categories:

function shapeSpace_enable_gutenberg_post_cats($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	if (has_category(12)) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post', 'shapeSpace_enable_gutenberg_post_cats', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post', 'shapeSpace_enable_gutenberg_post_cats', 10, 2);

As written, this function uses WP's has_category() to check if the current post belongs to category 12; if so, true is returned thereby enabling Gutenberg. Of course, you can specify your own category or array of categories, or whatever.

Tip: To check if the current post contains any Gutenberg blocks, we can add this logic to any of our enabling functions: if (has_blocks($post)) return true;
Enable Gutenberg for specific tags

Here is an example showing how to enable Gutenberg only for specific tags:

function shapeSpace_enable_gutenberg_post_tags($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	if (has_tag(50)) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post', 'shapeSpace_enable_gutenberg_post_tags', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post', 'shapeSpace_enable_gutenberg_post_tags', 10, 2);

As written, this function uses WP's has_tag() to check if the current post is tagged with tag ID = 50; if so, true is returned thereby enabling Gutenberg. Of course, you can specify your own tag or array of tags.

Tip: Notice the 3rd parameter, 2, passed to either of the add_filter() functions. That specifies the number of parameters passed to the hooked function, which in this case is shapeSpace_enable_gutenberg_post_tags. So if you look at that function, you will see that it accepts two parameters, $can_edit and $post.
Enable Gutenberg for any Post Type

One more for the road! Here is an example showing how to enable Gutenbeg only for specific post types:

function shapeSpace_enable_gutenberg_post_type($can_edit, $post) {
	
	if (empty($post->ID)) return $can_edit;
	
	if ('books' === $post_type) return true;
	
	return $can_edit;
	
}

// Enable Gutenberg for WP < 5.0 beta
add_filter('gutenberg_can_edit_post_type', 'shapeSpace_enable_gutenberg_post_type', 10, 2);

// Enable Gutenberg for WordPress >= 5.0
add_filter('use_block_editor_for_post_type', 'shapeSpace_enable_gutenberg_post_type', 10, 2);

This function is similar to the others, but hook-wise it does something a bit differently. When working with post types, WordPress/Gutenberg provide the following filter hooks for working with Post Types:

// WP < 5.0 beta
gutenberg_can_edit_post_type

// WP >= 5.0
use_block_editor_for_post_type

So we use these recommended hooks to enable Gutenberg for specific post types. Note also that our function currently checks the current post type. As written, it checks for a post type named books; feel free to modify as needed to suit your needs. The possibilities are endless!


Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

What up! Just to help spread the word about the DigWP newsletter. Get WordPress news, tips, and special offers delivered fresh to your inbox. 3-4 times per year max. Always good stuff, never spam, and we never share your info with anyone. Just a quality newsletter letting you know about awesome stuff happening in our corner of the WordPress universe.

Direct link to article | View post at DigWP.com

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Weak passwords leave your site vulnerable. WordPress sites with more than one user should enforce a "strong password" policy for better security. To help with this, check out Password Policy Manager. It is a CHOICE WordPress plugin that makes it easy to define a strong set of password requirements for your site's users. Easy to use and provides a robust set of features. Check it out.

Direct link to article | View post at DigWP.com

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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

Step 1: Backup Database

Before making any changes to your database, it always is a good idea to make a good working backup copy. This way you can restore your previous content should something unexpected happen.

Also, if you want to keep a copy of all your subscriber infos (i.e., names and emails), then take a moment to export those data as well. You never know when/where the information may be useful.

Step 2: Select Data

Using your favorite database UI (e.g., phpMyAdmin), enter the following query:

SELECT * FROM wp_postmeta WHERE meta_key = "_sg_subscribe-to-comments";

Remember to double-check the database prefix (e.g., wp_) and edit to match your own. This query will return all subscriber data added via the Subscribe to Comments plugin. Just so you are aware of what you will be deleting. Take a moment to observe the total number of entries and so forth. Also as another reminder, now would be a good time to grab a copy of the subscriber data you are about to delete.

Step 3: Delete Data

At this point, there is no going back. Enter the following SQL query to delete ALL data collected via the Subscribe to Comments plugin. Again, remember to check and change the database prefix if necessary.

DELETE FROM wp_postmeta WHERE meta_key = "_sg_subscribe-to-comments";

And DONE. All subscriber data should be removed from your database.

Step 4 (Optional): Replace "Subscribe" Link

After deleting all subscriber data and deleting the plugin itself, there may be one more detail to consider. Namely, a way for your readers to subscribe to comments on your awesome posts. There probably a bunch of different approaches or solutions for this.

For example, if your readers are savvy like ours, you can simply replace the "Subscribe to Comments" button with a link to the RSS feed for each post. Here is a screenshot showing how this was done here at DigWP.com:

Simple link for users to subscribe to RSS feed for post comments

And the underlying code to make it happen:

<div ><a href="<?php echo get_post_comments_feed_link(); ?>" title="Post Comments RSS Feed">Comments feed for this post</a></div>

That is added directly in the theme's comments.php template. Of course, some CSS also is used to dial in everything visually. So while comments are open, each post will display an RSS icon and feed link, for example:

https://digwp.com/2018/08/secure-wp-rest-api/feed/

Using some other plugin?

If you are not using the same plugin, Subscribe to Comments, the previous SQL queries will return zero results. But the concept is the same regardless of plugin. The only thing you need to find out is the name of the database column (and/or table if necessary), and then modify the previous queries accordingly.

Why Remove Subscribe to Comments?

The main reason is that we don't get a lot of comments these days, so it's not really necessary. But more importantly, I removed the plugin to eliminate all the errors. Well, not errors they were just PHP Notices or warnings. But there were a LOT of them. Like many megabytes worth of log entries every month. So basically endless log spam. It was just time to move on.

The Subscribe to Comments plugin was an essential and awesome plugin that served us well for many years. So total respect and props for the amazing run :)


Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Weak passwords leave your site vulnerable. WordPress sites with more than one user should enforce a "strong password" policy for better security. To help with this, check out Password Policy Manager. It is a CHOICE WordPress plugin that makes it easy to define a strong set of password requirements for your site's users. Easy to use and provides a robust set of features. Check it out.

Direct link to article | View post at DigWP.com

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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.

User Data = Public Domain?

Beyond content theft, plagiarism, and such, the REST API opens the door to another potential security slash privacy concern over user data. By default every WordPress site delivers a significant amount of user data to anyone or anything that asks for it. For any user (of any role) that is the author of at least one post, their personal information is openly available to literally everyone.

So exactly which user data are exposed via the REST API? As explained in the documentation, the /users endpoint delivers basically everything except for user email addresses and passwords. Everything else — ID, Name, Website, Description, URL, Metadata and more — all public domain thanks to REST API.

To give you a more concrete example of the data that is shared publicly via the REST API, consider the following URL:

https://digwp.com/wp-json/wp/v2/users/3

Here we are invoking the REST API by calling a specific user endpoint (i.e., user ID = 3). Requesting that URL in a browser, the following data are returned:

{
	"id": 3,
	"name": "Jeff Starr",
	"url": "https:\/\/perishablepress.com",
	"description": "Jeff Starr is a professional web developer and book author with over 15 years of experience...",
	"link": "https:\/\/digwp.com\/author\/jeffstarr\/",
	"slug": "jeffstarr",
	"avatar_urls": {
		"24":"https:\/\/secure.gravatar.com\/avatar\/...",
		"48":"https:\/\/secure.gravatar.com\/avatar\/...",
		"96":"https:\/\/secure.gravatar.com\/avatar\/..."
	},
	"meta": [],
	"_links": {
		"self":       [{"href":"https:\/\/digwp.com\/wp-json\/wp\/v2\/users\/3"}],
		"collection": [{"href":"https:\/\/digwp.com\/wp-json\/wp\/v2\/users"}]
	}
},

This same information also is available at other endpoints, for example:

https://digwp.com/wp-json/wp/v2/users

There you will find the same amount of information provided for every qualified user. Note that you can try this on your own WordPress-powered site. Simply replace digwp.com with your own domain name, and remember to include the subdirectory path if WordPress is installed in a subdirectory.

What's the Risk?

So WP REST API and security. For everything except the user data, the main risks basically are the same as for RSS feeds. Scrapers and content thieves are savvy enough to steal your content regardless of format. If you make it easy for people to steal your content, they will. So whether they're grabbing the data via RSS or JSON format, content is content, and the REST API makes it easier than ever for anyone and anything to manipulate your site's content, categories, tags, meta, and much more. Is that acceptable? Totally your call.

Now for user data, we enter a whole new level of risk. With user data, the information is personal, so there is a potential privacy risk. Even worse, for every user, their "Name" by default is their "Display Name", which defaults to the registered Username unless otherwise specified. This means that your site's registered usernames are publicly available, so there is a potential security risk.

Privacy Risk

For the privacy risk, perhaps it is a non-issue for most WordPress sites. But for the percentage of sites that must abide by an official privacy policy or other company rules and regulations (GDPR, anyone?), publicly sharing information about every qualified user is gonna be a problem. Or maybe your site needs to keep all author information private for legal or political reasons (like at a news reporting or government site). In many such cases REST's default functionality may present serious privacy risk. As someone said somewhere on social media1:

A lot of institutions use WordPress for their staff or students or even patients/clients. They probably have no idea this is exposed and they also probably have some level of security policy that doesn't allow names to be listed publicly. I think it's a problem and should be opt-in.

Security Risk

For the security risk, the significance and extent of the issue is up for debate1,2,3. In general, bad actors require at least two things to gain access to your site4:

  1. Username
  2. Password

And thanks to the WP REST API, they now have half of what they need. So the REST API introduces a security vulnerability by making it easier for attackers to brute-force their way into your site5,6. Instead of having to guess the correct username AND password, now they just have to guess the password. Which unfortunately for many user accounts is just too ridiculously easy to do.

Another on-topic post from social media1:

Its one-half of the puzzle in acquiring unauthorized credentials. If you're trying to follow best practices, you don't expose sensitive data. If you've worked to remove all leakage of user names from your site, this just re-exposed all that data.

How to Secure the REST API

So at this point, you should have a pretty good understanding of how the WordPress REST API works and why it can be considered a privacy and/or security risk for probably a vast percentage of WordPress sites. Now you get to decide whether or not it is necessary to take action and secure your site against unsafe data exposure. Fortunately, there are a couple of easy ways to lock it down using a WordPress plugin. Here are a couple of free options:

Full disclosure, the first option listed here, Disable WP REST API, is one of my own plugins. It is designed to be super lightweight and effective. That in mind, either of these plugins is gonna do the job to protect against unwanted REST exposure. If you know of other/better techniques, share ’em in the comments.

WordPress Team On Point

The WordPress team is aware of this potential privacy/security risk and already has taken steps to lock it down. For example, before the WP 4.7.1 update, the REST API exposed sensitive data for ALL registered users, regardless of whether or not they are credited as Author for any post(s).

So thanks to improvements made in version 4.7.1, WordPress now displays user data ONLY for users (of any role) who are credited as author for registered post types. This important step helps to reduce user data exposure, and tells us that the WP team is actively working to keep WordPress as safe and secure as possible. Hopefully they will take further steps to eliminate unnecessary exposure of sensitive user information.

Closing Thoughts

As simple as it is to properly address the fundamental vulnerabilities inherent in the WP REST API, unfortunately most WordPress users will remain blissfully unaware and do nothing. This is why the REST API should disable the public view of most if not all user data.

Sensitive information should be exposed only to authenticated users. Disabling exposure of user data by default helps to protect the vast majority of WordPress users, and of course developers always will be savvy enough to enable the user data endpoints if/when needed. It's a win win! :)

Footnotes

Here are some related materials and resources FYI:


Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

It's happening: WordPress is being forked. Meet ClassicPress. The original, Gutenberg-less WordPress publishing platform.

Direct link to article | View post at DigWP.com

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

It's been a BUSY year! So far most of my work is focusing on WordPress plugins. Recently announced Disable Gutenberg and Gutenberg Custom Fields plugins. And now I am pleased to announce 5 more plugins designed to improve your WordPress workflow: Disable Responsive Images, Disable WP REST API, Enable Database Tools, WP Cron HTTP Auth, and the BEST for last: Contact Form X. Please check ‘em out, and THANKS for your generous attention.

Direct link to article | View post at DigWP.com

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview