Full stack web developer, interested in all the things, but especially the web, code, design, Linux, OS X, PHP, WordPress, JavaScript & robots.

Tagged: rest api

WordPress REST API Vulnerability Exploits Continue image/svg+xml

Over the weekend the attacks increased and WordPress security firms have seen more attempts blocked by their firewalls. Sucuri, the website security firm that reported the vulnerability to WordPress, was tracking the “Hacked by w4l3XzY3” campaign last week and estimated 66,000 defacements. That particular campaign has now passed 260,000 pages indexed by Google. It is one of nearly two dozen defacement campaigns targeting the vulnerability.

Ouch! The WordPress REST API has certainly gotten off to a rocky start. Personally, I love the REST API, but I’m thinking this hasn’t helped convince its detractors that it should remain as part the WordPress core.

Abusing the WordPress REST API

Earlier, I was playing around with the WordPress REST API and I was struggling to figure out why the WordPress function is_user_logged_in() was not working with my custom endpoint. The function returns false regardless of whether the user is logged in or not. Turns out, this is by design and I needed to send a nonce within my endpoint request. Doh.

Anyhow, before I figured this out (RTFM, Philip), I came up with a rather fugly workaround. The hack was to add an action to the rest_api_init hook, call the is_user_logged_in() function and set a global variable, which could then be accessed from within the endpoint. Now, I’m not sure I would recommend using this hack, but it did occur to me that there could be a scenario where it’s not possible to send a nonse with the request, in which case the only way to test if the user is logged-in would be within the endpoint’s code.

How bad am I?

How we’re using the WP REST API at Washington State University image/svg+xml

Our primary use for the WP REST API is to share content throughout the University via our WSUWP Content Syndicate plugin. With the simple wsuwp_json shortcode, anyone is able to embed a list of headlines from articles published on

Nice to read about another example of how the WP REST API is being used. A little surprised by the number of sites and networks, it would have been good to found out more about these numbers.

REST API will not be included in WordPress 4.5 image/svg+xml

This news comes after last week’s conversation during which Matt Mullenweg said he was uncomfortable merging the REST API until the endpoints were complete. He was referring to the fact that the four default endpoints aren’t ready, even though they are available in the plugin. The conversation ended with the future of the API uncertain, and now it appears the merge is on hold until that can be fixed.

This doesn’t come as a big surprise. I’ve been keeping an eye on this story and the more I’ve read, the more I’m inclined to agree with Matt’s cautious stance. I mean, I can understand why the API team are pushing for its inclusion, but it’s not going to cause any harm by letting it remain as a plugin for the time being. I think this is a victory for common sense.

WordPress Contributors Look for a Path Forward for the WP REST API image/svg+xml

Over the weekend, discussion continued surrounding the direction of the WP REST API, as both Matt Mullenweg and Ryan McCue took to their WordPress blogs to clarify statements from last week’s status meeting. Differences of opinion are driving a heated debate about what constitutes a goalpost for the API’s readiness for core.

I’m finding this debate fascinating and I can empathise with both sides. What’s really interesting are the different writing styles Matt and Ryan have used in their clarification posts. Matt’s post/argument is based on a passionate analogy of “good” music production, whilst Ryan’s post is more technical and a lot lengthier. It’s kind of obvious who is more directly involved in the project, although this is not indicative of how correct that person’s argument is — sometimes you can be too close to be able to make an objective decision.

Anyhow, it will be interesting to see how this pans out. From where I’m sitting, the argument for progressive enhancement is looking strong and I’m sure a compromise will happen.

Does WordPress have a future?

I was asked on Twitter today, “Do you think WordPress will have a future in the next 5 years?”

Now, I don’t have a crystal ball, but I do read a lot and I try to keep up-to-date with what is happening in the world of WordPress. With this in mind, I’m confident that WordPress does have a future, in fact, all the signals point to an impending boom in usage and development.

In case you missed it, the most important feature of the lastest WP release was the inclusion of the REST API in the WP core. This feature is a game changer and has opened a whole new realm of possibilities for developers. Now, I could attempt to list a bunch of imagined applications which would no doubt leave you cold and uninterested, but luckily for you, I don’t have to, because documented real-world examples have already started to be published. A couple of examples being:

And it’s only just beginning. I’m expecting to see many more examples of how the REST API is changing the way users and developers interact with WP.

Personally, I’ve only just begun to experiment with the API myself, but from my limited experience, I can testify that it’s incredibly easy to work with — I was able to implement my own custom endpoints in a matter of minutes. I’m looking forward to playing with it some more and I’m already thinking about how it will change some of the projects I am currently involved with. I’m excited about that and I would say the future for WordPress, and its developers, is bright, very bright indeed.