A case for the front-end editor

On WP Shout, Fred Meyer makes an impassioned case for the front-end editor, and why he believes it deserves a renewed effort as a WordPress feature plugin and eventual WordPress core inclusion.

It’s a really thoughtful post, and at well over 5,000 words, it’s an investment to read. But I think it’s a good post to read in its entirety if you can make the time.

In short, Fred makes two major points:

1. The editing experience is the core function of WordPress and deserves tremendous focus and attention. And the front-end editor should be a priority.
2. The feature as plugin model has flaws that need addressing, namely encouragement and man-power from a core level.

I think Fred makes some great points, and some things he says ring truer than I wish they did.

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 and official 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 avery 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.

This is definitely the way of many core initiatives. And I think Fred’s point that sometimes core importance and resources are not equally aligned is a good one. Even feature plugins where there is significant buy-in and well-noted importance — like with the REST API — it’s still a relatively small team making herculean efforts to drive home a feature.

He makes an excellent analogy in regard to support that’s necessary for a small team to thrive:

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. 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.

Generally, I agree with Fred. I think the editing experience is one of the greatest challenges ahead for WordPress. Other platforms will continue to improve editing, and the next major step WordPress makes to enhance editing will be a very important step.

At the same time, I think the feature as plugin model is inherently a good setup, and a vast improvement to the previous feature release model.

Defense of features as plugins

One thing the feature plugins we’ve seen so far have shown us is that a complex new WordPress feature is not simple. The quote Fred gives of Andrew Nacin in a Slack meeting is exaclty what I agree with:

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.

Features as plugins may take two releases, or they may take ten. But in their current form their development can be isolated and iteration can be made before they go “all in” to WordPress core, potentially derailing a WordPress release cycle and the normal bug-fixing and small feature development that is so important.

I believe that features as plugins being outside the regular core development cycle is partly why I can’t name as many parts of WordPress we’re actively avoiding as I used to be able to. Remember how long revamping media was avoided?

With feature plugins, we don’t have to hold our breath during a release cycle while Koop buries himself in JavaScript for months, which then hardly anyone understands until someone — like Scott Taylor — dives in to refactor things or build another feature on top of it.

Features as plugins give code time to mature, for developers to review it, and for site owners to test it. It’s been good for the WordPress project, despite some flaws.

Anyway. Draw your own conclusions. Like I said, Fred’s post is great, and I’m glad he wrote it; and especially in regard to the front-end editor I think his argument is compelling. My point is simply that I won’t call features as plugins a failure just because we have some kinks.