by ·0 Comments

Version 1.3 of the Disable REST API plugin is out now, to support the recent updates to the REST API introduced in WordPress 4.7.

Previous versions of the plugin accessed the available filters which let developers to turn the REST API off like a light switch. These filters have been deprecated in 4.7, which means that while they exist they no longer actually disable the API.

This shift makes a lot of sense from the core team’s point of view. Editing tools in the admin area are going to plan to use the REST API in the future, to improve the admin area experience for editing content. To that end, they don’t want something which easily disables the content endpoints of the REST API.

The new recommendation is to raise an authentication error if you do not wish for endpoints to be accessible, so that’s exactly what the plugin does as of version 1.3. If you are logged into a website as a user, the endpoints will all function as designed. However, if you are an unauthenticated anonymous user who tries to access endpoints of the API (even ones that are typically designated as publicly accessible) you will be greeted with an authentication error when this plugin is installed and activated.

WordPress versions 4.4x, 4.5.x, and 4.6.x will all continue to use the `rest_enabled` filters; but please don’t use this as an excuse to not patch your website. I still strongly recommend everyone keep their websites up to date and running the latest version of core whenever possible.

I will gauging interest in an update to the plugin which would allow administrators to further tighten up access to the REST API based on user role: it is very possible that websites that have basic Subscriber users or custom low-permission users (like websites running WooCommerce, BuddyPress, or numerous other custom applications with user login areas) will still want to disable the REST API for some reason, and currently any site that allows these types of users could still easily be accessed by one of those users.

by ·0 Comments

Recently I posted a note to a WordPress group on Facebook about BruteProtect no longer issuing new API keys, and naturally Automattic’s Jetpack plugin was mentioned since that is where you have to go for BruteProtect functionality nowadays. Since the internet never disappoints, Jetpack detractors there were there almost immediately chiming in with the usual comments about how “bloated” the plugin is (I don’t personally agree); how awful Jetpack is because it starts with numerous modules activated out of the gate (I don’t see this as a big problem, as they are easily enabled/disabled and it is something you only have to worry about once per site installation); and how much of a pain it is to manage Jetpack installations for clients due to its requirement for connection to a wordpress.com account.

jetpack logo
This last complaint caught my attention, because it reminded me of a discussion we’d had a few months ago at the agency where I work. We were discussing a rollout plan for giving Jetpack to many of our existing clients, but we knew that we would need to connect each site to wordpress.com in order to do so. For ease of use we wanted to use a single email alias such as `[email protected]`, but this was immediately ruled out. When you have multiple independent clients, you can’t connect everyone with the same email address because don’t want each one having access to each others data (especially stats and plugin management!). We needed a different approach.

Our final solution ended up taking about 5 minutes to configure, and allowed us to go through the Jetpack installations with ease. New clients who receive Jetpack are quickly connected with no additional setup required.

Continue reading

by ·0 Comments

While I wasn’t planning on making a new plugin, this one just presented itself and had to be done.

Over on the Advanced WordPress facebook group, a post was made about an amusing javascript plugin called echochamber.js, which let you easily add a comment area to your site which looked like a normal form but in reality didn’t actually post to the website. Instead, the comment is saved to Local Storage so it appears to save (and if you come back to the page, you will still see your comment there) but your comments are never seen by anyone.

It’s a tongue-in-cheek way of keeping snarky/nasty comments off your content, while giving people the appearance and feeling of user engagement. Looking at the code, I saw how easy it would fit into a WordPress plugin so I whipped this one together. All credit for the functionality goes to Tessalt on GitHub, since it’s all her code: I just wrapped things up so it tucked nicely into the WordPress ecosystem.

If you’d like to take a look, you can find the plugin in the Echo Chamber Comments in the WordPress repository.