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:
- The editing experience is the core function of WordPress and deserves tremendous focus and attention. And the front-end editor should be a priority.
- 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.
