A Prayer for the Soul of the WordPress Front-End Editor

This article is about what I believe is the most important issue in WordPress right now: the need for a better post editing experience.

This article is a personal statement about what I believe is the most important issue in WordPress right now: the need for a better post editing experience. It’s fairly long, because I found that I couldn’t write about the topic without trying to synthesize a lot of what I believe is true about how the WordPress landscape works and how it evolves. If I’m wrong about some things, it wouldn’t be the first time (or the last), but I do hope it inspires discussion and action within the WordPress community.

Some terminology notes: “Post” is meant in the broad WordPress sense of all post types—pages, (blog) posts, and custom post types—and not in the narrower sense of just blog posts. The WordPress post editor, often called just the “editor,” is the default backend tool for administering post content in WordPress. The Front-End Editor is a tool (currently a plugin) that allows post authoring and administration directly on the front-end (the user-visible part) of a site.

The Current State of Post Editing in WordPress

Last week, Jeff Chandler of WP Tavern wrote a widely discussed post called “Time To Abolish Metaboxes in The WordPress Post Editor.”

In a lively comments section, it was more or less established that actually abolishing metaboxes is not a good idea. However, what strikes me as more important is the core complaint that led Jeff to his suggestion (emphasis added):

“I’ve used WordPress to write about WordPress for more than seven years, it’s how I make a living. Recently though, writing in WordPress feels more like being a data entry specialist.”

He continues:

“I feel like I’m hitting switches and turning knobs before clicking the publish button… I’m most interested in an interface that consists of less scrolling, searching, etc., that gets me to the publishing stage quicker without feeling like a data entry specialist.”

The WordPress post editor imparts a grayness and a difficulty to editing content.

I know exactly what he means. I use WordPress almost all day, almost every day, and the WordPress post editor imparts a grayness and a difficulty to a huge amount of that experience.

It’s not so much the “metabox fiddling” (I actually don’t mind the Add Media and Save Draft flows very much)—it’s that I’m not really looking at my post, but at a gray, Microsoft WordPad-looking mockup of what my post will eventually look like. It’s a split experience: feed words into one end of an assembly line, press “on,” and venture over to the other end of the factory floor to see the beautifully formatted text and images that come out. Over time, the movement up and down the floor gets tiresome, as does the gray, plain factory itself.

History of the Front-End Editor

My favorite alternative to the default WordPress post editor is called the Front-End Editor.

Since late 2013, the Front-End Editor had been under active development as a “Feature Plugin” designed for eventual inclusion into WordPress Core, with Janneke van Dorpe as lead developer. Work progressed steadily until late 2014.

As I’m slow to every party, I first tested out the Front-End Editor in mid-December 2014, and wrote one of my most excited articles ever about (and with) it. However, by the time of that article, progress on the plugin had been halted; its last group development meeting was in early September 2014, and it’s now listed as “Inactive” on the features as plugins page. It stopped getting new code commits after late November 2014, although (promisingly!) Janneke returned and made another commit less than two weeks ago.

What Happened?

I think the Front-End Editor fits into a recognizable pattern of failure with feature plugins.

As a disclaimer: I wasn’t around for this process, and don’t know the details. However, I have tried to research the project as best I could to get a sense of it; and moreover, I think the Front-End Editor fits into a recognizable pattern of failure with feature plugins.

As Jeff recently put it, the features-as-plugins model, as currently implemented, is “a mess.” Here, in one rearranged paragraph, is what appears to be the crux of the problem:

“Feature plugins are generally driven by one or two people who might be good developers, but lack project management skills.” “It’s almost like someone needs to constantly shepherd feature plugins to make sure they’re following a schedule and keeping them all on the same page”; but this doesn’t happen with the current model. Instead, “Features-as-plugins often become Projects without requirements or tasks, which leads to a non-schedule, and then often require all-or-nothing to go in.”

(That last quote is from Scott Taylor in this really interesting Core development discussion that inspired Jeff’s post.)

I don’t think the project-management skills of the Front-End Editor (and other feature plugin) developers are necessarily at fault. Rather, the key issue is that feature plugins face a sink-or swim environment, and cannot count on additional support from the core development community once launched.

The Feature Plugin Valley of Death

Feature ideas get some measure of official support and recognition when they’re first named as feature plugins, and again when they’re almost ready for Core. In between is the Valley of Death, and it claims most feature plugins.

Feature ideas get some early measure of official endorsement when they’re named as feature plugins. This can attract new developers to the project, give feature plugin developers the chance to share knowledge and ideas with key core developers, and give the project an overall sense of inspiration and official support.

In the happy cases, after lots of development, some of these plugins reach the point where they’re pretty much finished, at which point they again knock at the gates of Core and receive expanded attention, support, and recognition. This happened, after around eight months of development, for the Press This bookmarklet revisions that will go into 4.2.

However, the long development process between being named a feature plugin and being mostly Ready for Core is, in many cases, a solitary rite of passage with very little external support. This phase is the Valley of Death, and it claims most feature plugins.

I think the Front-End Editor project started to hit the huge wall of complexity separating its mostly-good sorta-buggy functionality from being Core-ready code that works across nearly all theme and plugin configurations, hosting environments, and goodness knows what else. (The project is trying to do a very difficult thing, for reasons I’ll briefly touch on later.) There was no end in sight, and also no sense that there were project management, development, support, or testing resources available beyond what were already on hand. That’s when progress stopped.

The Current Situation

So where we are now is: the Front-End Editor works but is buggy, and is no longer thought of as headed into Core. There are also no major sanctioned projects to replace the default post editor, although unofficial third-party solutions are proliferating.

Does that matter? Was the Front-End Editor a good (but, unfortunately, failed) experiment, or are we missing something more important here?

How Much Do We Care About the Post Editing Experience?

Jeff’s post touched off a large discussion about what’s important in WordPress and the future of the post editing experience. I highly recommend reading it all, but I do want to highlight one comment:

What is essential in this discussion is that there are different kinds of users of WordPress. And for each of those, a different kind of editing experience is better. That is the challenge.

For example, you can have non-tech content editors. Say the client you build the wordpress website for. For him/her, the current backend interface, even though it’s relatively well-designed and simple compared to other CMS’s, can be quite complex. So for someone like that, front-end editing could be a good solution…

For more technical developers working with wordpress, such a front-end editing would be of little use, since he/she wants direct access to all more advanced features (meta-boxes, other sections of the admin, etc).

What is WordPress for, and how much does the post editing experience matter to that vision?

This point is mostly about the technical specifications of front-end editing (I discuss that briefly later), but it also points to the larger discussion being had in the comments and underlying any decision about changes to the post editor: what is WordPress for, and how much does the post editing experience matter to that vision?

WordPress: Democratizing Publishing

From the WordPress Foundation site, WordPress.org’s mission is:

“To democratize publishing through Open Source, GPL software.”

Similarly, WordPress.com writes: “Our mission is to democratize publishing one website at a time.”

So publishing is at the core of WordPress in all its incarnations.

I don’t think this means prioritizing the interests of bloggers (like Jeff and, sometimes, myself) over those of other users. I used WordPress to build small business sites before I started blogging regularly, so I’ve personally never seen it as a blogging platform at heart. I think things like WooCommerce are key additions to WordPress; and if WP-API makes WordPress a good candidate as an app platform, I think that’s great too.

So let’s take “democratize publishing” as broadly as possible, to mean: Being able to put what you care about out into the world, without anyone getting in your way. In my mind, that covers the vast majority of WordPress’s use cases, from small-business sites to blogs to online stores to BuddyPress installs to Time.com.

The Post Editing Experience Really Matters

If WordPress had no post editor at all, it would be unrecognizable; I can’t say the same for many of its other features, as wonderful as they are.

Even with this expansive definition of “publishing,” it’s hard to imagine the vast majority of WordPress users not using the post editor constantly. Every website has content, and short of exotic use cases like bulk CSV product imports, the post editor is how you add and change it.

As a thought experiment, let’s imagine WordPress had no post editor at all. In my opinion, WordPress would be so hollowed-out as to be unrecognizable. I can’t say the same for many of WordPress’s other features, as wonderful as they are, like pretty permalinks or the image editing feature set. WordPress isn’t image editing software; it’s software for managing and displaying (often written) content.

Whether I’m doing development or blogging, my work revolves around the post editor as much as anything else in WordPress.

My experience as both a WordPress developer and blogger bears this out. I’m in the post editor all the time—for literally hours per day. It doesn’t matter if I’m doing client work (which often entails inputting and formatting page content), managing my own projects (which requires the same thing), or blogging (which, obviously, is oriented around post creation): my work revolves around the post editor as much as it revolves around anything else in WordPress.

What Do People Want?

Do people really care about improving the editing experience in WordPress?

I tried to take the heartbeat of the WordPress community in an article recently, and the main thing I learned is that people want all kinds of different things. It was a bit humbling to imagine drinking from that firehose as a core contributor.

However, front-end editing and improved post editing were, in this small sample, the most referenced top priority. (Respondents were technically savvy WordPress developers and site admins; around one-fifth put either front-end editing or improved post editing as their top priority.

I’m obviously not attempting to claim consensus on WordPress’s feature needs based on this tiny and noisy sample; in fact, it’s quite obvious that there is no consensus. But from Jeff’s article, the comments in response to it, our survey results, personal conversations with other users, and my own experience, it is clear to me that a large proportion of sophisticated WordPress users, including non-blogger-types, really do want better, easier, more intuitive post editing.

Why I Love the Front-End Editor

I’ve already described my general excitement about the Front-End Editor in my earlier post on it, but here’s more detail.

Flow Comparison

To see how the Front-End Editor works, let’s look at a very simple editorial change in the default post editor, and then in the Front-End Editor.

Here’s the edit in the default editor’s Text mode:

And now in the default editor’s Visual mode:

Now here’s the same task in the Front-End Editor:

Advantages of the Front-End Editor

To me, the Front-End Editor gives a massively better experience.

It’s Faster

With slowish hosting and a lot of small changes, the Front-End Editor saves many minutes per post.

First, it’s faster. Looking at one small, discrete edit, the difference doesn’t seem like a lot; but let’s imagine writing a long post with lots of little changes like this, and doing it on slowish shared hosting, meaning that both wp-admin and the post draft load slowly. In that situation—the one a lot of bloggers and site owners are likely to be in—it’s a difference of many minutes per post.

(You can argue, “Well, you just shouldn’t save drafts that often then; you should make a lot of changes and save them all at once.” But that’s the tail wagging the dog: you’re telling me how to change my editorial flow so that my editing tool looks less inefficient relative to a better tool.)

It’s Better in Many Other Ways

Speed aside, the other reasons to prefer the Front-End Editor experience are at least as persuasive:

• You see your content exactly as it’ll look in the final version, as you’re writing it. You don’t have to guess at formatting, or keep a mental picture of the post you’re writing.
• When you save a draft on the front end, you can still undo your changes—without browsing revision versions.
• You don’t have to keep two browser tabs open to edit efficiently.
• It feels right: You’re writing content to your website, and there it is on your website. You’re not feeding something into a TinyMCE window, and watching your changes pop up all the way on the other end of the factory floor.

I’ve written many long posts with the Front-Editor (buggy as it is), saved myself a lot of time, and been much happier at the end.

None of this is theoretical: I’ve written many long posts with the Front-Editor (buggy as it is), saved myself a lot of time, and been much happier at the end. For the first time ever, the WordPress editing experience flows, and that’s worth an awful lot.

In fact, I wrote this article almost totally in the Front-End Editor; and, although it was time-consuming and took a lot of effort, it was never a bummer. I can’t say the same for the default WordPress post editor, and I honestly don’t know if I’d endeavor to write something this long and detailed in that interface.

Steps I Believe Make Sense

I’d first like to ground this discussion in Andrew Nacin’s recent thoughts on the feature plugin model, as an index of where a key WordPress contributor and development leader currently stands on the issue.

Nacin (from January 7, 2015 Core development Slack meeting):

We need to ensure that core contributors are highly invested in this pathway for development [feature plugins]. We will always need to innovate and think big. But it doesn’t make sense to confine that work to a single release, as then it completely takes over everything we’re trying to work on. The number of times (2-3 years ago) that a release has turned into drop-everything-and-save-the-feature is insane. That shouldn’t happen again. That’s part of what this was trying to solve. In an ideal world, half of our contributors are working on feature plugins, half are not. Or certainly a better ratio than we have now.

It is possible for a project as large as WordPress to continue to move forward without any single person following everything that is happening, or even knowing everything that is happening. This is a Good Thing. Everyone will have a pet thing, or a major thing, they want to work on. That is great. Your own priorities isn’t — and doesn’t need to be — the same as someone else’s priorities. There is plenty of work to go around. Just because there’s a lot of focus on X, doesn’t mean Y is being neglected, or that Y even needs more focus than it is receiving.

No one person can pay attention to everything, or care about everything. That doesn’t mean it isn’t important. Or maybe it isn’t important — but it still doesn’t mean it can’t be done… It’s tough to say we are stretched thin here — we have dozens of highly active contributors, and 300 people each release jumping in.

I’d like to suggest some directions from here, while also saying that I hope my suggestions will be taken with the humility I intend—as well as my deep gratitude toward Matt Mullenweg, Nacin, and all the core developers.

1. Increased Official Support for Feature Plugins

From Nacin: We need to ensure that core contributors are highly invested in this pathway for development… In an ideal world, half of our contributors are working on feature plugins, half are not.

That’s really encouraging to read. If I’m understanding the current situation correctly, what the Front-End Editor needs (and probably what most other languishing feature plugins need) is backup: encouragement, a sense of official buy-in, development help, and, most importantly, an unwillingness to let feature plugins fail for the wrong reasons.

Feature plugins are currently developed in relative isolation, partially to prevent them from sapping resources from other ongoing projects. This is partly sensible, but it risks turning feature plugins into small, isolated projects which sink or swim based not on whether they’re good for WordPress, but on whether their small development teams get snowed under by technical complexity or lose course because of inadequate project management.

The tenacity of a feature’s development team is not a good metric of its usefulness and importance for the WordPress user base. If something’s deemed important enough to go into Core, it should be supported on its way in.

That seems backward to me, and settling for calling them “feature experiments” because there’s a high chance they’ll fail also seems to go in the wrong direction. The tenacity of a feature’s development team is not a good metric of its usefulness and importance for the WordPress user base. If something’s deemed important enough to go into Core, it should be supported on its way in. Either feature plugins are good ideas for Core, or they’re not; we can’t let the Valley of Death decide for us.

In the past, WordPress features, and even WordPress feature plugins specifically, have benefited hugely from a focused infusion of resources, especially by Automattic. The wp-admin redesign, MP6, is the major case in point, and it sailed through the development process in a way that no other feature plugin since has matched.

I think that the good ideas for how the feature plugin development process could be better structured (see here and here) could help streamline and organize feature plugin development and lead to better outcomes. But I also think that feature plugins need support. That could be as simple as a commitment, by the core development team or even Automattic, not to let feature plugins fail for the wrong reasons—reasons related to inexpert project management and developer exhaustion, rather than to the underlying value and viability of the feature in question.

This could mean that to be accepted as a feature plugin implies more support from the core team than at present—and if that potentially implied a more rigorous and “official” application process than the current one, that might make sense. In either case, to present the possibility of acceptance into Core, but not to have a way to help furnish the resources that might be necessary to get a given idea over the hump, seems like a recipe for a lot of abandoned great ideas, and I think the results bear that out.

If you’re going to cross a desert on foot, it’s really helpful simply to know there’s a Jeep with supplies following you. With the Jeep around, you can push yourself to see what you’re capable of, because you know there’s someone to save you from dying. Too many feature plugins are dying; they need a Jeep.

2. Acknowledgment of a Better Post Editing Flow as a Priority

From Nacin: Everyone will have a pet thing, or a major thing, they want to work on. That is great. Your own priorities isn’t — and doesn’t need to be — the same as someone else’s priorities. There is plenty of work to go around. Just because there’s a lot of focus on X, doesn’t mean Y is being neglected, or that Y even needs more focus than it is receiving.

Nacin’s really got my number in one sense: I’m advocating for my own WordPress development priorities—which, according to me, are ultra super important—and requesting that they get more attention, presumably meaning less focus on other issues if required. Everybody is doing that. So how do we make decisions?

Authoring and editing post content is the core feature of WordPress, and it’s not great right now.

All I can say is that, as I’ve tried to argue above, a better post editing experience really is important. Post editing is how less savvy users “use” WordPress; and in both my blogging and client work, it’s the piece of WordPress I touch more often than anything else. Authoring and editing post content is the core feature of WordPress, and it’s not great right now.

And we have a way to make it great. More than any other single feature the software’s history, the Front-End Editor (current bugs and all) has revolutionized my use of WordPress. I think it stands a chance of being the killer WordPress feature for the vast majority of WordPress users. People want to write content to their websites, and front-end JS/Ajax editing is disruptively better than back-end PHP editing.

To the earlier point that technical developers would find a front-end editor of little use because we need to change post metadata: I can’t think of a compelling reason why all types of post meta couldn’t be editable on the front end using Ajax. In fact, the Front-End Editor at one point had an interface for managing custom fields:

How WordPress Can Support Development Priorities

I understand Nacin’s general point that just because other people are working on other things doesn’t mean your thing is being forgotten. However, there are concrete steps that Automattic and the WordPress core team can take when something is a priority, MP6 being an example; and that the Front-End Editor is being allowed to rest in “inactive” state is a clear indication that that type support is not even being considered.

If there are technical issues I don’t know about that make the Front-End Editor a nonstarter, the current stance makes sense. In that case, I think the next big question is what can replace the current post editor. MailChimp-style side-by-side front-end editing might be a candidate:

But if completing the Front-End Editor for Core is merely difficult and not impossible, I absolutely cannot think of a better thing the Core team could allocate resources to.

Answering Objections

I’ve covered a lot of ground here, and I suspect not everyone will have the same perspective. So to encourage helpful discussion, in this section I’m going to offer my perspective on the most immediate objections I’ve seen raised to the Front-End Editor specifically, as well as the general objections that get lobbed at people who ask for things in WordPress.

Wait for WP-API, and You Can Have Your Own

There seems to be an evolving consensus that WP-API will allow for a multiplicity of post editing experiences. As a WP Tavern commenter says: “Think Editor Templates.”

I’m genuinely excited by this, and think it could be an answer to streamlining content creation in WordPress, while allowing for WordPress’s multiplicity of possible uses.

However, I do have some reservations about defaulting back to “Hurry up and wait” for a better editing experience courtesy of WP-API. They include:

Delays

The WP-API project has been significantly delayed, largely because the team is focusing so heavily on getting it right from the start. It’s not clear when WP-API will really land into core; and beyond that, it’s not clear when good WP-API-based editors will come online.

Lack of Focus

If better post editing isn’t a priority now, it’s not clear why a completed WP-API would make it a priority. It’s also not clear that the Front-End Editor is stuck in ways that the WP-API fixes. The Front-End Editor talks fine to the WordPress database; it’s themes and plugins (as well as arbitrary internal bugginess) that it struggles with at the moment.

So even after WP-API launches, better post editing may not be a Core development priority. And that means:

Proliferation of Third-Party Solutions

Third-party solutions are great for an awful lot of things. For example, I think it’s great that we have WooCommerce, rather than an official WordPress e-commerce system bundled with Core.

But relying on third-party solutions to solve the (“core”) problem of a clunky post editing experience has the following problems:

If they’re free, it’s nobody’s job to make sure they work with new versions of WordPress, work on a given theme, continue to grow and improve, etc.

If they cost money, we’re now in the position of paying money for a better post editor, which just seems to go against the magic of WordPress. Furthermore, there’s the risk that, as with many WordPress themes, market forces will push paid solutions to prioritize features arms races over elegance and proper integration with WordPress. I believe the very popular WordPress Visual Composer illustrates this tension: it makes post creation much easier for users (the customers), but at the expense of dumping out a mess of interlocking shortcodes that make life harder for developers.

In either case, we’re relying on users to be proactive and informed about improving their WordPress experience, savvy about how plugins work, able to distinguish between good and bad plugins, etc. Not all WordPress users (who constitute a fourth of the internet, and soon, we hope, a half) are this sophisticated about WordPress, so third-party solutions have limited reach relative to solutions baked into Core.

WP-API’s New Editors May Not Offer Inline Editing

The biggest thing I love about the Front-End Editor is that I’m writing my post content directly onto my webpages, with no secondary “editor” interface to worry about. In other words, I’m writing (and adding images, media, etc.) inline.

That’s a really complex feature to offer, because of all that can go wrong with divergent theme designs and conflicting plugin features. As two examples: I have to close this site’s popup social share bars before the Front-End Editor’s “add image” modal will work; and I can’t use the Front-End Editor to set a post’s title, because our theme wraps the title in a link that my browser follows when I click to edit it.

Combining “post editor” with “post viewer” in a CMS that has hitherto kept the two separate is a fundamentally difficult problem.

These types of bugs exemplify a broader fact: combining “post editor” with “post viewer” in a CMS that has hitherto kept the two separate is a fundamentally difficult problem.

WP-API lets programmers more easily communicate with the database via JSON endpoints. What it doesn’t do is solve most of the complexity described in the previous paragraph.

So without a lot of dedicated problem-solving of the type that the Front-End Editor already needs right now, I imagine that the “editor templates” we get will be, at best, side-by-side with the front-end content:

That’s pretty good, but it’s still split-editing à la MailChimp, and not an inline editing solution like the programs people use to write the vast majority of their digital words: Gmail, Word, or Google Docs.

Other Objections (The Usual Suspects)

Bloat

Will the Front-End Editor bloat up the WordPress Core package?

Most of the size of the current Front-End Editor plugin is in one of its dependencies, a front-end text editor called Aloha Editor. It’s nearly 3 MB in the plugin files, but according to Aloha the minified package is only 142 KB. (Even the “minifed” versions in the plugin files appear to be improperly minified; they still have comments, line breaks, and everything, just shorter function names.) So, as a guess, the Front-End Editor as a core feature could be kept to 300 KB or smaller.

I love keeping WordPress lean, but it’s currently at 17.4 MB unzipped. I don’t think increasing that by 2% to make WordPress a platform with a state-of-the-art post creation interface seems like an extravagance.

“That Sounds Like a Great Plugin, Not a Core Feature”

Fortunately, the Front-End Editor is already a “feature plugin,” slated for inclusion at some point in Core, so enough people have seen the value to grant it that status.

But just to address the argument head-on: Virtually everybody who uses WordPress writes and edits posts and pages. Text content creation and editing is arguably WordPress’s single most important feature, and it’s what WordPress unarguably has in common with its most direct competitors, like Squarespace and Ghost. Making that experience great, but only for WordPress’s savviest users, sounds like self-sabotage to me.

“Sounds Awesome, You Should Do It Yourself”

What the Front-End Editor needs is buy-in, not heroes.

The Front-End Editor already died once because of that mentality.

I would love to give my time to helping develop the plugin into something worthy of Core, and I’d love to help create a community around it; but I’m not a good enough developer or project manager—nor do I have the personal or financial space—to simply will the Front-End Editor to perfection myself.

What the Front-End Editor needs is buy-in, not heroes. The same is true for the other feature plugins that die out because of a lack of backup.

Conclusion

To summarize everything above: It’s pretty clear to me that WordPress’s editing experience can, and must, improve; and the Front-End Editor is the first solution I’ve found that feels right. I think we shouldn’t let the Front-End Editor die, and I’d like to know how many people feel the same.

So more than anything, I’d love to hear how this article struck you. If you’re excited about helping to revive the Front-End Editor; if you know something I don’t about a Doom Bug that invalidates the whole project; if you know something way better (subject to the constraints I mentioned above) that’s currently in the pipeline—I’d like to hear your thoughts.

Maybe we can make a plan, and give front-end editing a second life in WordPress. Thanks for reading!

Correction: The quote beginning “What is essential in this discussion…” about the front-end editor at the top was earlier incorrectly attributed to WordPress founder Matt Mullenweg.