WordPress.org Has Fewer Than 20 Plugins Using the WP REST API in Core

Plugin Recommendations Featured Image
photo credit: when i was a birdcc

During yesterday’s pivotal WP REST API meeting, WordPress contributors discussed adoption of the API. A cursory search of the WordPress.org plugin directory shows that fewer than two dozen plugins are currently using the API scaffolding included in WordPress 4.4. For reference, here are the 20 plugins identified by Mika Epstein during the meeting, along with active installation numbers for each:

With a few notable exceptions, most of these plugins are hovering around a range of 10 – 100 active installs. These low numbers may indicate that plugin authors have not yet readily embraced building with the scaffolding that was merged into core in 4.4. However, some developers who have embraced building with the API have opted not to offer their plugins and themes for large scale distribution on WordPress.org.

“I think the plugin directory is the wrong place to look for adoption,” WordPress developer Nate Wright said at the most recent meeting. “As a plugin author myself, I have to bend over backwards to ensure compatibility with tens of thousands of weird plugins and themes. Javascript itself is highly unstable in the ecosystem because of all the terrible code out there. I’ve used the API in client projects and am currently integrating it with some customizer tools I’m building. My publicly available plugins will be the last thing I’ll introduce to the API.”

Taylor Lovett, author of Custom Contact Forms, believes that it’s important to get REST API-powered plugins into the hands of users, despite the support challenges of public distribution.

“It pushes plugin and theme developers to start working around API JavaScript conflicts now,” Lovett said. “There are many plugins that conflict with the API for a variety of reasons, one of the big ones being modifying Backbone.sync. Having plugins use it now is painful but will push people to start reporting those JS conflicts.”

Custom Contact Forms is currently the most widely-used plugin running the WP REST API with more than 70,000 installations, but the journey to using the current version has been fraught with challenges.

“There have been a number of backwards compatibility breaks with the JSON REST API project,” Lovett said. “If I had known going into it what would happen, I probably would have not used the API.

“I am still not completely comfortable with using the API because of the perceived instability of the project,” he said.”

Nevertheless, public distribution has brought Lovett considerable feedback from users which has been invaluable for his contributions to the REST API project.

“I’ve had a number of patches to the API that were discovered through Custom Contact Forms,” he said. “I’ve discovered some real edge cases while maintaining the API across more than 70K installations.”

Distributing his plugin on WordPress.org while the API went through significant changes was more challenging than Lovett anticipated, but through it the API has gained more exposure.

“The faster the API is exposed to people and people get comfortable using it, the sooner we will see some major strides in applications being built around WordPress,” he said.


23 responses to “WordPress.org Has Fewer Than 20 Plugins Using the WP REST API in Core”

  1. We are building Postmatic 2 to leverage the REST api (for delivering comments from email), but it degrades to use admin-ajax if REST fails or is unavailable.

    It’s a hoop to jump through, but by taking a progressive approach we get plenty of flexibility and immediate gains. I look forward to the day that the install base for REST is strong enough that we can use it 100% of the time.

    Epoch 2 (for displaying and publishing comments from the web) is built completely on, and will require, REST. There is no looking back when it comes to loading comments via REST and displaying them with Angular. It’s fantastic.

      • The benefits we’re most interested in are speed and reliability. Previous to REST most apps or services which interacted with WordPress did so over the ancient and insecure XML-RPC or would write their own API to hit admin-ajax.php.

        The former just isn’t reliable or secure. The later isn’t performant because it load WordPress each time you hit it. 

        As far as day-to-day from the user end of things you can expect to see faster comment loading in Epoch, as well as a much smaller overall plugin footprint as it won’t be adding our own custom API…

        • Gotcha, thanks! So on the API front, would that mean less or more opps to work/integrate with other plugins? Or does that only mean other REST plugins, due to how the API works?

          And please excuse ignorance on this topic – it interests me immensely, I just don’t know what it means. :)

          • Once we see widespread adoption there will be tons of opportunities for plugins and services to share data and leverage each others assets. For sure. Imagine someone leaving a comment and it generating 3 replies. Epoch would be able to pass that whole thread along to, say, Evernote. Easily. 

            Or you could make any comment which has received 4 upvotes automatically trigger a tweet….

            Interestingly cooperation between WordPress plugins isn’t technically difficult right now as most use native data storage (posts, comments, users, meta). So passing subscribers from, say, MailPoet to Postmatic (or the reverse) is already easy to do… it just has to be politically and/or economically agreeable. 

  2. So tricky… IMO the best think to do is to wait for public usage of the API.
    I’m working all the days with distributing Telecom APIs for public or paid usages and believe me, you can not make any good development (that works in all the cases) based on those APIs until they are stable.
    In the case of the WP API the result for the users is that they’ll think that your plugin is so bugged… Just because of the WPREST API is not finalized… And as Nate Wright said.. You must keep compatability with previous releases if you are some….
    Not so good for business.

    It is like future CSS4 or 5…Nobody will use it in production as porting are more or less implemented on all browsers ..
    For the moment it is just for testing purposes…

    But in // we can all use them for mockups, just to be ready when the D Day will arrive…

  3. Envira Gallery’s Adobe Lightroom Addon that we launched last week utilizes the REST API


    Although it’s a premium addon, the REST API was essential to allow users to create WordPress galleries straight from Adobe Lightroom and keep that in sync.

    I believe the low number of plugins in the repo is because devs are eagerly waiting to see what happens before putting all their eggs in a project.

    I honestly wish that the REST API was here even earlier so we didn’t have to build a custom API for our OptinMonster SaaS which is powered by WordPress.

      • Hey Ron,

        I don’t see how your comment is necessary or helpful here. Syed contributed to this conversation to point out a very cool integration that would never have been economically feasible without REST. Keeping Lightroom galleries in sync with WordPress galleries? Are you kidding? That’s insane and a perfect example of leveraging REST to bring more and more people into the WordPress fold. Sure, both Envira and OptinMonster are premium plugins. But they are part of the WordPress ecosystem nonetheless. 

  4. I think that the API is, for the moment at least, more likely to be used for custom work rather than mainstream plugins. It’s the nature of the beast.

    Being incomplete, the REST API isn’t really ready for prime time yet, and potentially is a bit of a moving target. Development today is potentially tomorrow’s support nightmare if any of the functionality changes. Most people who have developed against this sort of new tool expect it, and the smart ones generally stay away until it’s a couple of version up the road.

    IMHO, REST API should have remained as an optional plug in rather than being part of the core, at least until it is completed and fully functional. Jamming it in there now is just not in the best interests of the core right now.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: