WP REST API Delayed, Contributors Facing Gridlock

wp-rest-api

The WP REST API team met yesterday in the #core-restapi Slack channel to discuss the status of the existing post, term, user, and comment endpoints. There are a few outstanding issues with these four core objects, which the team wants to tackle via a feature plugin approach instead of holding the API back from merge. These outstanding items include things like password-protected posts, autosaves and post previews, and meta handling.

“For now, we’re not going to support them, and will be working on them in a separate feature plugin instead,” WP REST API project lead Ryan McCue said. “Again, this will be an enhancement to the API in the future, and doesn’t block compatibility here.”

In September 2015, McCue and contributors outlined a merge plan for the REST API which brought the infrastructure into the 4.4 release with the endpoints on deck to follow one release later in 4.5. Contributors to the REST API believe that the project is still on track for this goal.

“Our proposal is that we ​merge the four core objects​ in the REST API with full read, create, update, delete support, with the more peripheral features to come ​when they’re ready,” McCue said.

Several WordPress contributors, including project lead Matt Mullenweg, voiced concerns about the REST API shipping without the features that have been temporarily spun out.

“I know it’s a minority opinion, but I would be pretty skeptical of merging a partial API into core,” Mullenweg said. “I think it would do a lot more damage than benefit.”

McCue contended that the team has been working towards shipping a product that can be progressively enhanced.

“The API is specifically structured around progressive enhancement, which is a key difference from many APIs,” he said. “Allowing clients to detect features and support them when they’re ready allows us huge flexibility.”

Does the WP REST API Need Full wp-admin Coverage?

Aaron Jorbin noted that while the four core object types allow for some innovative themes and content editors, they do not yet allow for full wp-admin replacements. This particular point was a deal breaker for several contributors attending the meeting.

“The cases where the current API covers today aren’t terribly interesting because they’re not really enabling something that was impossible to do before,” Mullenweg said. “It’s just a different approach to doing something that was already possible before. I don’t even think we have XML-RPC parity of feature support yet.

“I wouldn’t have included REST examples in the SoTW, or encouraged plugins to use the scaffolding, or even let the scaffolding in the last release, if I didn’t think it was the most promising thing out there right now,” he said. “But uptake definitely feels slower than I would have expected. It’s taken so long to get to this point, if we don’t pick up the pace, it could be another year or two before we get full wp-admin coverage.”

Despite the fact that the WP REST API recently had its own conference dedicated to it, most of the people who are building with it are those who are also contributors on the project. Adoption is not yet widespread, but this could be due to the fact that many developers don’t want to build on it until the core endpoints are officially merged.

“We’ve got a bit of a chicken and egg: without core adoption, potential API consumers are hesitant to take the plunge, but without adoption it won’t be tested sufficiently to be merged,” REST API contributor K. Adam White said.

“From a project point of view I’m not really excited about shipping an API that has ‘some assembly required,’ vs making the core release paired with interesting non-trivial killer apps (mobile apps, something calypso-like, big plugins using / supporting it),” Mullenweg said. “To me a complete API is one that covers everything that’s possible within wp-admin. A subset of that is a partial API.”

Multiple contributors on the REST API project, however, agreed that shipping with full admin replacement capability is unrealistic, especially after Mullenweg confirmed that it should support everything possible in the admin, including the file editor.

“We’re significantly more interested in getting read/write access to core types, so that we can interact with WP from a host of other platforms,” K. Adam White said. “I think that pushing everything off until it’s ‘Calpyso ready’ blocks myriad use cases before they can get off the ground.”

In response, Mullenweg asked why WordPress should support something in its web interface that isn’t supported through its official API. At the conclusion of the two-hour meeting he summarized his final proposal: “No partial endpoints in core. Let’s design a complete API, not half-do it and foist it on millions of sites,” he said.

This is a critical juncture for the WP REST API project. While most contributors seemed agreed on further iterating the existing endpoints and ramping up usage before merging them into core, attendees remained divided about the need to have full wp-admin coverage prior to merge.

WP REST API team members are squarely committed to iterating separately on peripheral features, but another contingent of WordPress contributors who joined the meeting yesterday are adamant about seeing a more polished API with better support for the admin. A plan forward has not yet emerged.

86 Comments


  1. What a great news on two fronts
    1. the rest API BS will not bother my sites for one more release
    2. Matt is back in the house and shows leadership. IMHO the last releases might be ok technically but have no sense of direction, Matt getting more involved hopefully will fix that.

    The main sin of the REST API from inception was the lack of a use case it should answer, so now we have at last some actual goal posts
    – minimum: parity with XML-RPC
    – full: parity with web admin

    IMO replacing XML-RPC with REST API is a valid goal by itself due to the security problem the xml-rpc protocol has which can not be fixed, but endpoint for posts comment etc should be left for plugins to implement.

    Report


      1. so now you have to be “productive” (whatever that means) to be able to comment on anything…

        I said it you you in the 4.4 merge proposal post that the endpoints are not ready for anything, that they are just badly designed, so it took you another 2+ months to meet other people that think the same and somehow it is me not being productive.
        You know some time, even people that are not core contributors know something about software development and API design.

        From the start it was obvious that you lack a model of the client that will use the API, what will it be used for and how. This is basic software development mistake, coding before thinking that almost never end well. I was simply shocked when I discovered that the API did not return the thumbnail as part of the post object (hope it was fixed by now).

        IMO parity with XML-RPC is low hanging goal as the xmlrpc code is organized and it should not be too difficult (easy for me to say ;) ) to map endpoints to it. Since RPC-XML have extensions maybe it will be possible to make endpoints in such a way as to support them as well, and then jetpack will be to communicate over REST-API instead of xml-rpc, enabling all the people that keep it open just for jetpack to turn the xml-rpc endpoint off.

        BTW, I actually admired the way you held yourself in the chat, and I do understand the need to vent it off, but why did the target had to be me ;)

        Report


      2. how would you like it if someone called your work BS?

        Report


      3. people do it all the time? If you can’t handle criticism better don’t do anything.

        Report


    1. How is the REST API going to bother your sites? Can’t even tell if you’re trolling :/

      Report


      1. a little trolling here, but obviously the unneeded bloat will hurt the performance and probably have several security issues. I don’t like code that it is unlikely I will ever use on my sites. Emoji and oEmbed are small bloat compared to the rest-api.

        Report


      2. Anything that goes to core is “on” by default and you will not have an admin option to disable it. To be able to disable you will need to install a plugin.

        Report


  2. Sounds like Matt is pulled a “Bill Gates.”

    For those who know the history of Visual Basic, Bill Gates told the Visual Basic team (I am paraphrasing): You cannot ship Visual Basic until you add extensibility.” And for those who know the history of Visual Basic, that extensibility was key to its success and dominance for over 10 years.

    Kinda like how WordPress and plugins have dominated for more than 10 years now.

    Report


    1. For every ‘Bill Gates’ there are a thousand other guys who failed with the same behavior.

      Report


      1. @Kevin,

        Given your reply, I think you missed the takeaway. The point was: “Extensibility matters.”

        OTOH, don’t assume by my comment I’m taking a position pro-or-con on the ship-vs-don’t-ship debate. I am not. It was just an interesting anecdote that I thought I would share.

        Report


  3. Support to replace all the admin is too much for me. I agree with progressive enhancement. Smart baby steps is always better, IMHO.

    Report


  4. I think this article has has unfairly characterized the discussion that happened in the REST API chat yesterday as “facing gridlock”.

    In one camp you have the core REST API team who have toiled away on prepping four core object endpoints for merge, another team of core contributors and committers who feel like four core objects with some flavor like meta support would be a good jumping off point, and then Matt, who fills his project lead role quite well in shooting for the stars, asking for nothing less than complete wp-admin parity prior to merge.

    Early in the chat, George Stephanis cited a proverb (For Want of a Nail) that ended up being particularly poignant to yesterday’s discussion, “for want of a nail the shoe is lost”. The majority of this article is focused on Matt basically saying “for want of a complete API the API is lost,” a wholly unrealistic expectation that flies in the face of continuous iteration, a core philosophy of WordPress development.

    We have three releases a year (possibly more in the future), we have feature plugins, we have incremental progress, all with continuous iteration in mind. And for some reason, Matt is still of the apparent mindset that the REST API should follow the feature plugin model — a concept I think we’re beyond at this point for the REST API. As Ryan McCue so aptly pointed out, “continuing to exist as a feature plugin hurts us more than it helps”. It hurts us because it forces us to consider feature-completeness as the measure for a core merge. And yet, we’ve already partially merged the REST API infrastructure in 4.4, which sort of throws that logic out the window.

    As I and others from the contributor/committer camp said in the chat, there can be a middle ground. Whether that ends up looking like the four core endpoints alone, four core endpoints with some flavor, XML-RPC parity, or some measure of wp-admin parity, remains to be seen. Let us not lose the (horse) shoe for want of a nail.

    Report


    1. Really odd reply.

      There is a disagreement as to whether (a) to merge a partial API into core or (b) wait for the complete package. You say there’s a middle ground.

      Yet what is this middle ground? Merge a partial API!!

      Report


      1. How is the middle ground between A) Incomplete merge and B) Complete merge to choose A) Incomplete merge? That seems to be choosing all of choice A, and none of B. Please explain.

        *Michael Musgrove* Owner *web design POP, Ltd. Co.* (502) 264-2353 musgrove@webdesignpop.com MichaelMusgrove.com [image: Twitter] [image: LinkedIn] [image: banner]

        Report


      2. @Michael,

        That’s precisely my point!

        Report


      3. Middle ground would be to ship complete pieces of the API in parts. What we have in the current four core objects proposal doesn’t fit the bill for merge-readiness, in my opinion.

        For instance, I would not consider shipping a posts endpoints, sans metadata support, or sticky/password-protected support to be considered complete.

        I think we would go a long way toward establishing developer trust to commit to shipping complete endpoints one at a time or in multiples. If full-featuredness can be assured in incoming individual endpoints – with an eventual goal of “wp-admin parity” (whatever that means) – that would be a good middle-ground approach.

        Report


  5. The reason it hasn’t had mass adoption yet is WP is not typically viewed as app framework and clients are not aware of this. Clients come to WP shops for websites not applications. Calypso is fantastic but it’s going to take more than that to change opinion.

    if the readied endpoints are not in core then stop blaming adoption as an excuse for moving forward. Build it and they will come.

    Report


    1. I wonder. REST API is not a requirement for most sites that are made with WP. In practice its very niche. REST API is fun for devs to connect app to site, service to service, but those cases are not the typical WP use case. Endpoints or no endpoints adoption rate will be small. (I think)

      Report


      1. If you read the log, matt was very disappointed with the adaption rate, and maybe his expectations were totally not realistic in the first place. The REST API can be used to do nice standalone JS widgets for lazy loading, live updates, etc which even “normal” sites will like to have. The problem (as was pointed out in the chat) is one of the egg and the chicken, no one is going to do plugins for that before the API stabilizes and it is hard to stabilize the API without concrete use cases to work against.

        Report


      2. You dont need the REST API for anything that you write. You’ve been able to do that pretty easily since forever.
        For adoption I dont think REST API endpoints by themselves is enough, there needs to be helper/wrapper functionality built around it. Such as live update widget class etc. Latest posts and comment widget is good example of use cases.

        Report


      3. Totally agree that there is nothing new in the REST-API, therefor I refer to it as BS, FAD and other not very nice names. Still there is advantage in having a stable API for computer to computer communication. XML-RPC is too clunky and wp-ajax is a weird end point (admin that serves also non admin) and both are hard to cache easily.

        I agree also with the wrapper, if the REST-API had come with some JS module that for example can be used by themes to get an out of the box infinite scroll, adaption would have been higher.

        Report


      4. I think the lack of adoption comes from the fact it’s not production ready or still lack of use cases and tutorials.
        In the common use cases, I can see developers replacing admin-ajax calls with the rest api and gain significant performance on the front-end. I can also see using WP as a backend for mobile apps.

        Report


      5. In the common use cases, I can see developers replacing admin-ajax calls with the rest api and gain significant performance on the front-end.

        Is there are performance increase? I dont use admin-ajax.php I’ve just hook into init and exit. Done so for years. Which is what most devs do (I think). Pretty easy. And getting REST like behavior is really easy.

        Report


      6. There is. admin-ajax loads the entire admin, which has significant overhead.

        Report


      7. Then it is just a test of how much you care to use the Rewrite API :)

        Report


      8. Timoty, so I need both underscore and backbone just to get an abstraction that does nothing by itself. Lets ignore the waste, why is it needed at all, why can’t there be a simple JS API, call it even wp_query, to do it?

        So here is the obstacle, core developers and many other good developers will have no problem with using the rest-api if needed, but most of the wordpress developers, including theme and plugin developers, are mediocre at best (After so many years I see on stackexchange people that don’t understand how ajax should work in WP) and for them anything that is not a simple copy and paste from the codex is too complex to use. REST API should probably have a simple JS SDK so people will not even have to know how the communication is going on.

        Report


      9. Both underscore and backbone are packaged with WordPress. You don’t have to do anything else but enqueue that client script. It is about as simple as it gets.

        Report


      10. Those are two more libraries that need to be sent on the wire which make the site slower…..

        Report


      11. That is a horribly uninformed argument. The two libraries combined are only 13kb. There are much more higher impact performance problems than 13kb of javascript.

        Report


      12. So are we entering a new age of wordpress development, bad performance by design?

        Report


      13. 13kb of javascript is not bad performance in the slightest. Stop trolling.

        Report


      14. You seriously think what you say? why is it not bad, because it is better than 130k? ok, got your level of understanding in web performance issue, no need to continue the discussion.

        Report


      15. If you want to build a lightweight vanilla JS, you are more than welcome to. But the majority of people who are going to use the API are already going to be using a javascript framework. Since backbone is bundled with WordPress core, it is one easy choice. However, people could write a react library if they chose to.

        Making use of a small external library is a non-issue for 99% of use cases where someone would use the backbone client.

        Report


  6. Hi,

    While I usually share the same opinions as Matt Mullenweg concerning WordPress, I feel that I somewhat disagree this time.
    He is right that the adoption should have been higher than this by now but I think that merging part only of the REST API into core in 4.4 created some confusion among users who preffered to delay their experiments until the endpoints have been merged.
    So my opinion is to merge the endpoints in WordPress 4.5 and let the users experiment with more confidence, even if it’s not a 100% feature complete, because then, there will be more users, and following the feedback we will know which missing features need to be prioritized.

    Cordially, M.

    Report


  7. I’m confused why anyone on either side of this argument is surprised that the adoption rate is still low. It’s not finished yet! I’m not going to read a novel that’s missing all the dialogue. When 4.4 came out it was made clear that the infrastructure was there, but the endpoints weren’t. I’m pretty sure a lot of devs aren’t even sure what that means, but whether you do or not, you’re waiting for the whole thing to arrive to take the plunge.

    Report


  8. Am i missing something here. Why dont they just release the rest api as a plugin like lots of adopted features of WP have done in the past and when matt thinks its acceptable level they can build it into core?

    Report


    1. You are not alone in this opinion. As a plugin (usually offering Drop-Ins for existing plugins) and theme author, I have no reason for the WP Rest API to come with pre-packaged WordPress.

      I also run sites with event calendars, and don’t think that these event calendar plugins should be part of core. having a great WYSIWYG? That’s core functionality. You could even make an argument for Caching, but this is still much higher than the level of technical experience of the average WordPress user.

      I don’t agree with the push to merge this into core, at all.

      Seems really great though, and I hope there is some path forward. #opensource #community #driven #software

      Report


      1. I don’t think the headline is sensationalist at all. Here’s one that is though, “WP REST API Delayed, WordPress Project is Doooooomed!” I think if the people spearheading the REST API project have a plan and want to go one way but the overall WordPress project leader thinks maybe going a different way would be better, that seems like gridlock to me.

        Report


  9. While some delay makes sense but converting everything in the wp-admin before merging doesn’t. IMHO that’s not the core purpose of WP REST API. Progressive enhancement makes more sense. But hey, that’s just my opinion.

    Report


  10. I wouldn’t call it a gridlock either, though out of context I see how statements sound different than they did in the flow of conversation.

    In development it’s important that we first be critical of ourselves and question assumptions we might have had in the past. I learned a ton during the meeting and thought it was a very productive conversation that I hope will continue.

    Although you characterize there as being sides, everyone involved wants the same thing: to have a modern and flexible API widely available to enable things built on WP far beyond what we can imagine today. I still believe that REST + React is the future of plugin interfaces as well. We’re just figuring out the best way from A to B, and I really appreciate the thoughtfulness and passion everyone is bringing to the table on the subject.

    Also if you feel strongly about this, the plugin could always use more contributors and is a great way to get involved in WP development working alongside some of the sharpest minds and contributors.

    Report


    1. Really, Matt? The owner of a billion dollar WP hosting company and the final say in what get’s put in to WP core, is asking for volunteers for the WP REST API?

      Honestly, focus less on “open source” projects like Calypso that were not requested, and focus on projects that users and developers actually want, such as the WP REST API which has had thousands of hours put into it of people’s free time.

      Report


    2. You’re right it’s not gridlock. The people actually working on the project all think it’s going to be useful and ready for merge in 4.5, and then there’s Matt Mullenweg who doesn’t. You are the *only* person I’ve seen that would block the api from core until it has 100% wp-admin coverage. The only one.

      You also have a clear conflict of interest that you haven’t addressed. WordPress.com already has a JSON API. Delays to the core API benefit Automattic from a competitive standpoint. That fact alone should greatly temper your involvement in this discussion.

      Report


      1. Yes, it’s baffling to me too. You would think he’d be fully on board with getting the API out without delay if it’s the way of the future.

        But it benefits Automattic for a very simple reason. .com has a JSON api and core doesn’t. So now that can be a talking point in meetings with VIP clients. E.g.: “Client: Hey Matt, what can .com do that self-hosted can’t?” “Matt: Well we have this API…”

        I’m not saying that’s the reason he’s advocating further delay of merging. I am saying it’s a legitimate conflict of interest that should be addressed, and his opinions on this topic should be viewed with those conflicts in mind.

        Report


      2. This isn’t the first time during the REST API’s development that Matt Mullenweg asked questions and raised issues that challenged assumptions. For instance, when the discussion took place on the best way to merge the API to WordPress, Matt questioned whether the API should remain as a plugin versus being merged into core. That was quite the discussion.

        Report


      3. @Bradley Kirby,

        There’s no question that Matt does have a conflict of interest between wordpress.com and the WordPress project. But that’s been true for some time. So why are you bringing it up now?

        Even with a conflict of interest, Matt would have to be an extraordinarily Machiavellian character to advocate first so strongly for the REST API and then so strongly in favor of delaying its integration into core. That’s a new — and very harsh — allegation. Is that what you’re saying?

        Because, if it isn’t, it looks like you’re just hurling insults because he doesn’t happen to agree with you this time.

        Report


      4. Business is business. Automatic has venture capital and that means he and the rest of the company are legally responsible to the investors at the end of the day, not to you, not ever.

        Why does it keep coming up? Because it’s relevant. It should come up every time. Sometimes abstaining from a vote is the right ting to do and that’s a decision only he can make. If Automatic were publicly traded company, though, .org having a fully featured api would have to be listed as a potential risk. If you disagree with that you need to go back to finance class.

        Personally, I love what Automatic has done. Their success has made a lot of things happen for WP that likely wouldn’t have otherwise. But a stance that appears hardline by the leader who won’t admit a clear conflict of interest is suspect every time.

        This should be an engineering discussion about the merits of partial vs complete merge (and defined by whom), of which Automatic’s conflict must be a discussion.

        Partials may not matter to someone who only is a WP only developer, but to an engineer at a Fortune 100, it can make things a lot easier.

        Report


      5. @Taylor,

        I agree 100% that it should come up every time. I am just suspicious of someone who brings it up only when it happens to suit them.

        That doesn’t make the conflict any the less; it just means there is also reason to doubt the motives of those who pick and choose when to bring it up.

        Report


      6. @kts915 I agree with you, that’s a fair point.

        Report


  11. This is an interesting use case to see how independent WordPress really is from Mullenweg. It’s no secret that Automatic dominates everything commercial with WordPress and Jetpack does offer its own API.

    To say that a large project cannot be included unless it is completely ready defies common sense, so long as there is an agreed to plan and incremental changes are negatively influencing others. I understand the point of featured plugins, but this particular project is outside the use case bell curve.

    Not being in core, even for limited endpoints, is holding developers back and reducing project integration.

    Report


    1. This is an interesting use case to see how independent WordPress really is from Mullenweg. It’s no secret that Automatic dominates everything commercial with WordPress and Jetpack does offer its own API.

      Mm yes, sinister stuff indeed. I suspect the Illuminati is behind it all and Matt is the senior priest.

      Props to you for reminding us all of the overlap between the various organizations and actors in this drama – something we’d all be unaware of were it not for the comments added to every second Tavern post.

      Report


    2. Actually, it’s insanely bad form to release something that isn’t anywhere near complete. It discourages adoption of the new product, and in the long run may doom it because developers learn it’s limits very quickly and decide not to bother – even as it improves over time.

      Further, it’s something that likely should be a plug in until such time as it’s completed. Core doesn’t need the bloat, and it certainly doesn’t need it from a half finished product.

      No office to the REST API team, but a half baked cake is a waste of the ingredient – few will eat it, and even fewer will enjoy it.

      Report


  12. It’s pretty disappointing how quickly people will paint Matt as some money-grubbing villain. He’s provided a career for most of the people on this comment thread (even though many of them don’t like to admit that, for whatever reason).

    Report


    1. OK, this line of thought is popular, but quite unfair. I do work with WordPress on a daily basis.

      If it wasn’t for Matt, I’d not have a career? *That’s insulting.*

      I’d simply be using OTHER software. I don’t owe my allegiance, nor my livelihood, to him.

      Sorry for pointing this out on your comment (I’m not picking you out in particular), but I’ve seen this so often that I now have to point out how (unintentionally) offensive this line of thought actually is.

      Matt has been thanked by a whole lot of people, admired and recognized by a whole lot of people, and what’s more, financially compensated pretty darn well.

      That we all owe him more, owe him our careers, our obedience and deference of our opinions, is … well, there’s hardly anything left to say about it.

      Report


  13. This is a mangerial decision, which people that spend their time solely in development would obviously be irritated with. Matt has a duty, not to mention vested interest, to protect core, which he’s doing by taking a conservative stance.

    Is it the right decision? It’s a tough call. Personally, I’d allow it because the benefits and rewards could vastly end up outweighting the negatives, which would be that the thing blow up and either quick patches have to be made or some “plan B” that developers with bigger brains than I have can have ready to implement if necessary, which would be the smart thing to do. By not allowing it, it opens up opportunities for competing CMSs that are willing to take some risks, show faith in their colleagues and embrace progress vs. safety. And pisses a lot of people off that are vital to the success of (open-source) WordPress.

    Report


  14. Unlike some, I am not at all surprised that the JSON API has seen slow adoption, and not for the reasons stated thus far.

    WordPress has grown like a weed since Matt forked B2, and a necessary-but-not-sufficient reason for that has been that WordPress has being so easy to build with. Designers with no prior programming experience have filled the world with themes and others with little to no prior programming experience have filled the world with plugins, and most of those themes and plugins are useful and effective on small-scale sites.

    But working with a REST API and Javascript is not little league and requires more developer skill and experience, both on the client and on the server. And most of the people who are actively building WordPress sites do not have that level of skill and experience (yet?)

    Further, among professional developers, people who develop for WordPress are after looked down on, as lesser capable developers. Go to a local PHP or JavaScript meetup and introduce yourself as a WordPress developer and watch the subtle eye rolls by most people there. Or worse, go to a Ruby, Python, Java or .NET meetup and tell them you develop using PHP and then feel the pity ooze. WordPress developers are considered the epsilons of the PHP/Javascript developer world, and PHP developers are considered the epsilon’s of the broader developer world. So we are the lowest rung of the caste system.

    How does that apply tangibly? The hourly rates and salaries that a WordPress developer can charge are one of the lowest when you compare to other platforms. So those who are agnostic about their platform often go where they make more money.

    I don’t mean to be negative, but those who ignore reality are blind to to the eventual outcomes (any potential solutions.)

    I do not mean to say there are no good WordPress developers. There are some really truly amazing developers who have chosen to focus on WordPress, but people of that calibre make up a tiny percentage of the people who work with WordPress professionally.

    And I am not putting the rest of those people down, they are typically highly skilled in other valuable areas such as design or marketing. But they are just in class with even average developers when you consider all development platforms.

    To a certain extent I blame this state on the (lack of) guidance from the core team towards meeting the needs of professional developers. But that’s only a small bit of it.

    Mostly WordPress does not attract top developer talent on a broad scale simply because WordPress is sp easy for someone with very little skill to build something useful. And that’s a large part of why WordPress has succeeded where it has. But it also limits it from attracting better developers en masse.

    Bringing it back to the REST API and lack of broad adoption: simply put it’s going to be a very slow slog because most people who work with WordPress professionally are going to struggle with building things that use it. And I currently don’t see that there is much likely to change that.

    P.S. I also think that the “Learn JavaScript Deeply” mantra is going to result in some of the people with aptitude for development realizing they can make a lot more money moving to Node.js and Angular/Ember/React, or Meteor, but most others will struggle to achieve the same level that people have been able to achieve with WordPress and PHP.

    And that will mean the adoption for REST API and Javascript will be much slower than Matt would prefer.

    JMTCW. FWIW.

    Report


    1. Ugh. Sorry for the bolding at the end. Can an admin on this site fix for me, perchance? :)

      Report


      1. Sarah: You are the best! Seriously.

        (BTW, wish you had the ability to edit comments for 15 minutes after posting…)

        Report


      2. These statements are perceptions, not reality.
        I’m willing to bet there are more people than you perceive that want to work, and are capable of working, on WP using the REST API, than you seem to believe. I’m one of them, who now has had a couple of projects it would have been useful on. But I’m waiting until it’s fully-baked. And even if they aren’t there yet, they certainly are capable of learning how to use it–the WP crowd is pretty smart. (Sometimes not as smart as they think, but still pretty sharp. :-))

        And as far as being looked down upon, that’s only by other developers, and they aren’t the ones paying the bills. My bills, at least. I still know more than my clients, and that’s what matters, and why they hire me. My rate for WordPress work is currently $95/hr, and I’m about to raise it because I feel like it’s a good time to due to my skills and my demand. I don’t think that’s too bad, for Louisville, KY. So I really don’t care if another developer wants to look down his/her nose at me. I realize I don’t have a masters from Stanford in CS. So although I prefer to be welcomed and respected at least a little among developers, it’s not all that relevant to what’s important, which is my business.

        *Michael Musgrove* Owner *web design POP, Ltd. Co.* (502) 264-2353 musgrove@webdesignpop.com MichaelMusgrove.com [image: Twitter] [image: LinkedIn] [image: banner]

        Report


      3. Michael,

        Everyone’s statements are based on their perception, so that goes without saying as are yours. So unless there are quantified stats, your perceptions are no more definite reality than mine.

        That said, no reason to get defensive. Sounds like you are one of the skilled ones, and that’s great. But that does not mean that most “WordPress developer” do not have your skills.

        As for only developers being the ones looking down on other developers, sorry but that is objectively not true. Many technical project managers at agencies started out as developers and they bring their bias with them.

        In my business we typically do backend work for digital agencies who only use WordPress because their client want them to, not because they want to.

        I live in Atlanta, GA USA and there are easily 100+ agencies here, most of which would prefer not to use WordPress if their clients would allow it (they often want to use SiteCore or similar there the billing rates are much higher.) The same may or may not be true elsewhere, but I suspect that it is true more often than not (except for very small agencies serving small business.)

        Go to a local WordPress meetup or WordCamp. Many who attend in Atlanta at least would struggle to write a basic plugin in PHP, let alone use code functionality to the REST API.

        Bottom line. There is no reason for this to upset you. Lean into it, it means you are worth a lot more to clients than the average “WordPress developer.”

        Report


      4. I didn’t mean to hijack this comment thread with my superfluous thoughts.
        But it doesn’t upset or worry me, except that when people keep repeating it, it tends to help set the larger public perception of it as fact, which isn’t necessarily true; that’s all. And that’s also helping keep WordPress work rates too low for a lot of talented WP developers. I’ve been to WordCamps and Meetups, and know that many people there are just getting started. But there’s an army of people – tens of thousands & growing by the minute – that are pretty capable at figuring out WordPress and enough PHP and JS to build on it and hang out a shingle. It becomes clear pretty fast that you simply have to know more than WP if you’re serious about what you’re trying to do.

        I’ve been around long enough now to have seen lots of debates over “WordPress developers” vs. “Real” developers, and although there certainly is an obvious technical difference and the experiences and training that’s led someone to a point in their career, it’s no different that if I, as an MBA, were to look own my nose at businesspeople that don’t have one. That would be silly. Its occurence is more of a matter of personal insecurity or some other shortcoming, rather than reality, and in either case, doesn’t matter in the long run.

        *Michael Musgrove* Owner *web design POP, Ltd. Co.* (502) 264-2353 musgrove@webdesignpop.com MichaelMusgrove.com [image: Twitter] [image: LinkedIn] [image: banner]

        Report


    2. Mike, your comments are spot on. Federal salary data will back you up. As an aside, I’ve respected all that you have done to help others on StackExchange for a long time.

      The very things that made WP so attractive when I was a junior are the same things that can make it so appealing as a senior. For example, in one project with an an Angular and Cordova frontend I have it hooked up to Firebase. But building backend data management systems is time consuming, so WP is the v8 engine that really manages everything. I use the api to manage 70,000+ posts, tens of thousands of comments, 50,000 media files and to sell products using the WooCommerce api. Oh, and these posts have a lot of meta.

      WP manages all this like a champ and allows me to spend dev time building great products. Revision and media management are two time intensive examples that are things I don’t need to worry about.

      WP is great as a backend core, but that message isn’t being told as loudly as it should imo.

      Thank you, Ryan & team for everything you have done & continue to do.

      Report


      1. Nice comment. I think WordPress is underrated in tech circles but the JSON Api is such an interesting factor. Other backends that developers use to build modern projects could be gone the next day. Parse is a recent example and it wouldn’t surprise me if Firebase gets phased out too. I know these backends are very different to what WP might evolve into, but there is immense value in having a popular OSS platform that just does a lot of the grunt work so developers can focus on the end product for the end user. I think the talent pool is bound to grow and getting paid properly is a perception management thing.

        I do think feature completeness and the lack of (current) resources are the main hurdle to getting adoption right now. I’ve parked a project since work on the API was started, waiting for the right moment, years have gone by now. But then, getting it right is a big undertaking.

        Also, it’s a pain to work with a fast evolving, partial API. If you have to use a fallback with the ajax api or custom end points you’re doing lots of added work, with far more code for little gain. Having said that, I do like what’s in core already and I’ve leveraged that in a handful of plugins already.

        Report


      2. Peter,

        Thanks. I do agree that WordPress is a great platform but as agreed most of WordPress’ user base are not great developers, nor do most developers via it as a serious platform. While we may think otherwise, our thinking it won’t change the broader landscape.

        As for “the talent pool growing and getting paid properly?” I dunno, WordPress has been around for a really long time; I don’t see that happening any time soon, if much at all. I think those of us who like WordPress like you and me should just resign ourselves to the fact things won’t change that much or rapidly outside of the WP bubble.

        Also agree that a fast evolving API is not a good thing, though not sure my opinion on partial vs full.

        Report


      3. I don’t disagree directly, when it comes to salary the ‘WordPress dev’ shingle doesn’t do any favours (unless you are well known core contributor). But developers can pitch their value differently to get competitive rates. It doesn’t resolve market wide perception, but it can help individuals get paid.

        And now especially, you can do WordPress projects and use tools and frameworks that are associated with more pay such as Node.js & React, mobile development etc.

        It is interesting though, you mention Node.js, but people in that ecosystem lament over similarly sounding issues: variable code quality, slow performance, iffy developers and general messiness. And for JS centric developers in general life is not that straightforward either because frameworks and best practices move at a ridiculous rate. It’s not a given that React is going to sustain its current dominant status. Grass can’t be that much greener.

        Once the JSON API is feature complete it will be a nice stable platform to work with that people can’t count on for years to come. No worrying about a disappearing 3rd party service with 0-12 months notice. No lock in with any particular framework or tool. I think that’s a good basis for attracting new talent, but that’s just speculation on my part.

        Report


      4. Peter,

        In general with me as a single data point, I have been able to make pretty good rates, but mostly because the people who hire us have difficulty finding people qualified for the more complex projects. Even so, many prospects who are used to paying lower rates for “WordPress developers” turn away because our rates are higher than they were expecting to pay.

        As for Node.js, you may have missed my point. Compare the skill required to start theming or even writing a plugin to the minimum skills required to developer for Node.js. In my mind, those two are worlds apart.

        One of the reasons the average Node.js, Ruby and Python developers are so much better than the average WordPress developer is because the former have to be a minimum level of good or they can’t even build anything; it’s a self-limiting criteria.

        As for the JSON API being stable for years to come, I am not so sure. When it was first blessed as a feature plugin I voiced concern that it was being built prior to understanding RESTful web services and their use-cases. At this point I’m not 100% certain that hurdle has been overcome so I an tentative on it not needing to be constantly improved.

        That said, I have admittedly not worked with it much on client projects so anything I say about it is purely pessimistic conjecture at this point.

        Report


      5. My Main question is if you are running WordPress with tens or hundreds of thousands of records, what hardware are you needing to throw at it to manage that? I’m guessing at high-traffic to keep responses lean you are needing to cache and use some ingenuity, and it’s not just Core WordPress doing heavy lifting.

        The main reason people rag on WP, is that some of it’s core structures, such as EAV. They don’t scale, it’s not a WordPress thing, it’s a mixture of database system internals and basic compute performance. Look at Magento, it’s wonderfully complex, but without the 2.0 refresh and a lot of caching, it eats server resources. If generic structures could perform incredibly well, nobody would take the time to invent complex specialised objects.

        While I don’t doubt WP can likely handle hundreds of thousands of posts, all with ~50 meta fields. I know it will crawl doing so for reporting, and other features that will become necesarry as a site grows. I say this without conducting any testing; not because I’m mad, but because such large result sets and queries will inevitably lead to the DB doing more thinking than it should. I’m a little concerned to see so much ignorance of the fact that to do more (including casts for some WP meta logic), will always take time and require rewrites and change-in-approach to problems.

        Report


      6. Those are really non issues. If you have such a big scale site and need reporting, run it on its DB backup/replication. which you need to have in any case.

        Front end users are absolute priority and you should design you DB structure and caching to serve them best, but reporting? as long it is reasonable time, who cares how much time it takes so give less priority for reporting even if it means it will take 10 min instead of 1.

        Report


  15. I’m waiting for the endpoints. And better authentication support.

    Delaying shipping major endpoints until it mirrors wp-admin capabilities is a bad idea. Correct me if I’m wrong, but Matt appears to think that the success of the API should be measured by the adoption rate in plugins. I don’t think this is where the real success lies.

    The real success will be the third party integrations – other sites, services and apps that are able to talk to WordPress without the need to install custom plugins – plugins that may be unsupported or half-tested.

    We need those endpoints shipped – even if the full API is not complete. I don’t need to be able to edit theme files, upload images or access password protected posts to use the API – all I need is access to the core data endpoints, and I’m sure many others agree. The rest can be added later – progressive enhancement is not unexpected at all.

    As soon as that happens, you’ll start seeing some amazing uses of WordPress that go beyond “Just another WordPress site”

    Report

Comments are closed.