Should WordPress Provide an API for Third-Party Editors?

Imagine a future where you log into your website’s admin. You head over to the editor. This particular editor has all the tools and features in place that make you more efficient at producing whatever content you put out for the world to see. You immediately start tapping keys or dragging your mouse around the screen, satisfied with what the software you’re using has to offer.

Today, that editor may be the default block editor for WordPress. Some may be running the Classic Editor plugin for a familiar writing experience. Others will be crafting beautiful layouts with the Elementor page builder.

As of this week, people are finding themselves at home with Iceberg, an interface built on top of the block editor for folks who prefer a minimalist environment and love Markdown.

Some bloggers post by email. Others use apps from their phone. And, an entire class of people works in third-party, offline editors such as Microsoft Word, Atom, and plain ol’ Notepad.

If there is one thing I have come to realize over the years it is that editing environments are as varied as the people who use them. There is no one-size-fits-all solution. The experience I am looking for is not necessarily the same experience you need.

Given the freedom to choose, most people would rearrange their desk, use a different notepad, and opt for a different writing utensil than their neighbor. Even if starting with the same tools, we eventually make tweaks to accommodate our personal tastes.

Throughout most of its history, WordPress has had a single editor that its users shared. It has changed over time — even the addition of TinyMCE was once controversial. However, the default editor has never been sufficient for every user. Personally, I abhorred the classic editing experience. It led me to write in various Markdown editors over the years for efficiency and a true distraction-free experience. It has also led to developers taking on the challenge of creating alternative experiences for large swaths of end-users.

As much as many people love the classic WordPress editor, it was a pain for many others. Otherwise, all of the tools that have cropped up over the years would have been unnecessary.

In much the same way, the block editor is often a love-it-or-hate-it experience. It is the ideal editing environment for many users. For others, it is a roadblock at best. At worst, it is worthy of a gasoline soaking and a book of matches.

The promise of WordPress is to provide an editing experience that allows people from all walks of life to publish their content on the web. The promise is to make that experience as pain-free as possible and to continue iterating toward that unattainable-but-worthwhile-goal of perfecting the publishing process.

WordPress — any publishing platform for that matter — is only as good as its editor.

It is a predicament. There is no way to make the ideal editor for all people.

What’s the next move?

An Editors Registry and API

In the comments of the Tavern’s Iceberg editor coverage, Phil Johnston proposed a solution for WordPress going forward. “With all of the amazing publishing experiences coming out, I wonder if it’s time for WP to include the concept of ‘Editors,’”, he wrote. “Like an official registry of installed Editors.”

He later created a feature request that called for an API that would make it easier for plugin authors to create new editing experiences on top of WordPress. The proposal is a high-level idea about how the editing screen could allow users to choose their preferred editor.

Potentially, users could install and use various editors, depending on what type of content they are building. A user may want something akin to a Markdown editor for blog posts but switch over to a page builder for their site’s pages. eCommerce plugins might have custom editing interfaces that are ideal for shop owners. Ultimately, the possibilities are endless. But, it all starts down at the WordPress level.

The idea is not about dropping the default WordPress editor. It is about creating a flexible framework for plugin developers to cater to more users’ needs. Additional methods of editing content would make WordPress a stronger CMS, drawing in users who would otherwise prefer a different experience, regardless of the type of site they are building.

It is possible to do this now. However, what could WordPress be doing to improve this process for developers?

Jeffrey Carandang, co-creator of Iceberg, believes that core could open the editing space to more third-party solutions. “Creating our own editor mode was challenging but a super exciting experience overall,” he said. “Gutenberg is still far from being extensible compared to other parts of WordPress, but we managed to hack on some areas that needed to work.”

Carandang identified a few hurdles his team had to overcome when building the Iceberg editor:

  • Limited hooks and filters outside of block development, such as the top and bottom areas of the editor and wrappers.
  • Little-to-no options to remove editor components, relying on CSS hacks to hide them.
  • The core editor’s reliance on localStorage.

In addition to the primary issues, his team had to develop against multiple versions of the block editor to ensure a seamless experience for users. Despite the issues, he still believes in a future where the block editor project can open up “potential innovations” in the space.

Today, I am composing this post in an offline Markdown editor. I will copy and paste my second or third draft into the block editor, which does a great job of converting Markdown into blocks, before final edits. On other days, I work directly in WordPress, depending on my mood. However, my preferred writing experience is as simple as it gets and often happens in Atom. It is what I am accustomed to.

I wonder if there will one day be an editor that will convert me to writing full time from within WordPress. I eagerly await the plugin developers who will make the attempt. My hope is that WordPress cultivates these ideas without standing in the way.


18 responses to “Should WordPress Provide an API for Third-Party Editors?”

  1. Is it possible that the REAL underlying problem is the the_content approach to storing document data? I believe that problem should be solved first. Imagine a future where the_content is pulled from its own API that can optionally be stored in a noSQL database. A hybrid db approach. So continue to use MySQL, but use a noSQL db just for post/page/cpt content. Then allow such an API to interact with that instead. Just my 2 cents.

    • A nice thing about an Editor API (as proposed here) is that you could load your own Editing interface which pushes/pulls/stores data however your system needs it. WordPress would not need to dictate that for each Editor.

  2. I write my posts in Markdown, using VS Code: it’s as simple as it can get, and I don’t need to be online to use it. If there could be an extension for VS Code that already synchronized the content with my WordPress site, and allowed me to access the images from the media gallery, that would be amazing!

    • One of the other reasons I often write in Atom (besides Markdown support) is that I don’t need to be online. Far too often, out here in a rural area, I lose internet access. The power goes out every time the wind blows is a saying we have around here. The electric companies can’t seem to keep up with keeping the trees cut back and away from the power lines. So, offline support is definitely a high priority.

  3. In short, yes, WordPress should provide an API for third-party editors. I remember third-party clients being one of the promises of the WordPress REST API but that hasn’t appeared. And I think that users should have a choice about how they publish. I use micropub clients a lot, and rarely touch the editor anymore, for example, and I think if someone else wants to do that an API for editing would make that easier.

    • The ideas presented here are my own and those of the people I quoted. Authors at WP Tavern are given freedom to independently explore ideas, regardless of whether they become a part of the core platform or sanctioned in any way. The goal is to point out interesting ideas, start a discussion, and see where it takes us.

      • I think what he meant was: Is this discussion a good use of that nonrenewable resource called time? People can dream here all they want — it’s stimulating — but personally, I do not believe Matt / Automattic cares one iota about anyone’s ideas here if they don’t translate into ROI for his company’s investors. As a result, I have to conclude that discussion takes every one to the same spot: a dead-end and nothing to show for the time expended.

        • I hope that all discussions we have here are a good use of our time. Otherwise, what are we all doing?

          Not every idea is going to make the cut. Sometimes, it’s the collection of ideas and discussions that leads us to the places we need to go. We might be talking about an editors registry here that never lands in WordPress. Over time and over various discussions, the community builds up an even better idea that does make it in.

          We have to have some level of belief that all these roads lead to the same place — a future where WordPress is even better than it is now. And, part of that is having discussions such as these.

          As for the belief that Matt is only concerned with ROI for investors, I simply have not found that to be the case over the years. I’m asking that we veer away from that line of discussion and that we focus on the topic of the article. We’re getting a bit off track now.

  4. While I really like the Gutenberg experience, I have recently split my writing and publishing processes. It’s quite nice to be able to write offline (in Atom or VS Code as others have suggested, though I’ve recently discovered Notable) without worrying about how I am going to typeset this or align that.

    The two things — writing & publishing — require different mindsets and it would be great if the the tools we use are aware of that context. A change that would bring us closer to that reality (Micropub already does a little) would be welcome!

  5. Speaking as a website owner, I basically do this already. Preferring to use Elementor for pages and Gutenberg for posts and others.

    Speaking as a plugin developer, I think this would be very welcome by developers. Creating proper support and standards for plugin companies to create unique editors that all play nicely with WordPress would be great. Then natively giving the site admin the choice of which editor to load for which post type, of course with Gutenberg leading the way as the default editor out of the box with WordPress when you install.

    I’m all for it and I think a lot of others would be too. It’s very much in the spirit of WordPress.

  6. If blocks themselves had a proper server side registry (much like register_post_type, register_taxonomy) where the full block attributes were registered, sanitize callbacks for saving blocks, etc, we could have many different versions of UIs that interact with blocks. Gutenberg could be just one version of interacting with blocks.

    I wrote about this in 2017 in this issue:

    “Let’s be honest. Gutenberg is not going to solve everyones’s problems. No matter how awesome it is or will become, it simply will not meet everyone’s needs. There will still be a market for creating content in different ways. Page builders currently completely dismiss the Post Edit screen, and these alternative post creation solutions will continue to exist post-Gutenberg.

    With a solid Server Side schema, hopefully the Page Builders could at least start to adhere to a standard way of interacting with “Blocks”. . .that way, if Page Builder A thinks using Modals to edit content makes more sense than the fixed-right sidebar of Gutenberg, they could build their own UI to interact with Gutenblocks, but still ensure the blocks are saved in the same way.”

  7. I have no real opinion on the Classic Editor vs. the new Block Editor as far as how convenient they are to use. I’m not a blogger; I put together websites for clients. The issue for me is that I have no desire to convert dozens of existing client sites to using the Block Editor, and then to spend hours training them to use it. And I just did not need to be forced to learn what is basically entirely new software on top of all the other work I have. The Classic Editor was fine, and using a theme like Divi improves my WordPress experience 1000%. I just don’t need this big hassle and massive extra work. There’s so much more to what I do than which Editor I’m using. I’m trying to run a business :-)


Subscribe Via Email

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

%d bloggers like this: