I’m starting some exploratory research into future editor options for ClassicPress, and I’d value community input before any conclusions are drawn.
I’m not proposing a replacement for the current editor, nor suggesting immediate change. What I’m trying to understand is:
What concrete author-facing problems would need to be solved for a significant editor evolution to be justified at all?
From my own experience as a content creator, the issues that most affect trust in the editor are not visual polish, but content integrity and control — for example:
loss or corruption of formatting between edit and publish
external content slipping into documents unnoticed
ineffective validation and feedback before save/publish
limited support for headers, footers, structured templates
weak versioning (e.g. no way to manage linked documents as a single versioned unit)
I’m also interested in features that don’t need to exist on day one, but would be easier to support long-term if the editor were designed with them in mind (e.g. advanced content manipulation, reminders, mail-merge-like workflows).
One strong personal preference: maximising document space and keeping controls discoverable without scrolling, with clear warnings and guidance before publication rather than after.
With all that in mind:
What are your own editor “deal-breakers” or must-fix failures? What capabilities would make you say “yes, this is worth evolving”?
I’m particularly interested in concrete pain points and acceptance criteria rather than specific implementations.
Personally, I want it to be a textarea. That would make me the happiest.
Objectively now, I am happy with the editor, and I think the jQuery dependency needs to be removed. There have been a few discussions on this, but nothing has been set in stone.
So, if anything, the editor needs to be simplified.
This looks remarkably like the new editor interface that I’ve just started implementing as a new editor UI, mine has fewer buttons currently. Theoretically, I should be able to run both, side by side. But I recognise that style.
In addition, I have just started adding a possible replacement to the TinyMCE core, and this also, should be able to run side by side with the existing stack, and, there should be no issues flipping form one editor to the other, providing that we keep the overall feature set in tune.
But this is just an initial feasibility, the proof of the pudding is in the eating. and right now, my new editor is actually getting it’s core from a CDN, I can read an existing tiny document on an editor hosted in the cloud, which is an alternative option that we can make available. But I do have another project, as I said, to put that core system in ClassicPress, running side by side with Tiny. I personally think this is a mandatory requirement. But I am trying to end up with at least one other in my analysis soup.
When I say I’m adding buttons, they are all optional, of course, and, you can remove buttons, and even the entire menu, with a bit of code.
There is one option that might help. The ability to remive or only use that menu bar. No buttons, or only selected buttons. I’m not sure that’s an option, but I’m going to fork Advanced Editor soon, to change the button system in order to reduced the visible button count without removing the buttons. I could add some more options in regard to those kinds of choices. The new fork will also allow you to create your own buttons too.
And, no need to worry about plugin size, either. I have a plan for that too.
HugeRTE is a fork of TinyMCE - I was in contact with the solo dev keeping it up in the past. It could be a drop in replacement BUT some features are missing and coding them into it and maintaining it would be too much to ask from the core team.
What was discussed is finding a replacement with following features:
Vanilla JS based
WYSIWYG (no block based editors)
ability to handle visual tab + code tab + possibly Markdown + Possibly support for Latex.
possibly it needs to be maintained (meaning no dead projects to take over basically)
just go back to focus on content with a markdown editor. The biggest thing to bridge is insertion of media (and this is probably where there need to be coding for any non tinymce editor).
For bloggers markdown might be easy enough to learn (this is afterall what whatsapp, facebook uses, so it not even too geeky) and agencies probably edit content in word or google docs in whih thy also manage comments and versioning.
But people here probably have their own experiance and it will be nie to have feedback. This is not an either/or option, markdown can live next to tinymce and for pages that require more control over presentation there are always page builders.
markdown is not a predefined markup, it is just a way for users to write semantic content without the need for understanding HTML. It is not a one to one match but can be good enough when visual formatting can be left to the theme.
I am sure you are familiar with it, and the current implementation of tinymce in wordpress actually supports a very limited syntax, but just in case I will link to the standard - Basic Syntax | Markdown Guide . note that there are different dialects, but don’t think you realy have to support more than the basics. biggest challange is probably adding media and links in an easy way to the content
We’ve already got insertion of media worked out. It’s in the Text widget in the nightly version of CP, and one of the drivers for that is so that it’s not dependent on TinyMCE. Sure, there will have to be a few adjustments to accommodate whatever new editor we finally go with, but they should be trivial to accomplish.