Well, a new editor that don’t care much about backwards compatibility can be very appealing to some. I myself don’t like it that the old editor is stripping out the paragraph tags. If the new editor can support “proper” HTML, as I see many online editors do, even Blogger, that’s a strong selling point.
I support WYSIWYG editing, but personally, I prefer WYSIWYM (What you see is what you mean), and so I write in Markdown whenever possible, which produces HTML that I can then copy and paste.
I don’t particularly love this either, but you are all going to be amazed at the amount of stuff that breaks if you disable this behavior.
This feature (called wpautop internally) has its origins in the textarea-based editor in early versions of WP, when people wanted to be able to use line breaks to make new paragraphs without having to type <p> every time. It has stayed around since then, and it is still useful when editing in text mode or in the Quick Draft box for example.
I probably wouldn’t have built it this way, but it needs to continue to be the default behavior, due to the literally thousands of plugins that depend on it working this way.
Disabling this behavior is currently possible, but only for custom site builds with a high level of technical knowledge and tight control over all plugin and theme code that is installed onto the site.
I’m not going to argue in favor of 100% full backwards compatibility because for a change of this size, that’s essentially impossible.
Still, it’s important to keep in mind that if we “break everything because we think we can do better” … that is basically the same mistake WP made with the block editor.
To me this means that the basics and the important features need to keep working the same or in a very similar way, and that old content needs to be able to be imported and edited seamlessly and correctly (possibly except for some rare and well-understood edge cases).
There’s only one plugin and one theme that interface with the editor and support ClassicPress. Since we’re no longer recommending WP plugins, it seems fine (to me) if a WP plugin breaks on CP if it’s not specifically supporting CP. I would argue that this is the perfect time to break everything (because “everything” in this context is extremely limited.)
There’s big differences here. People actually want the new Tiny editor, and we’re actually doing it for the good of the project and the users rather than for the good of egos and investors.
I think spending time trying to make this backwards compatible is one of the instances where we are just going to spinning our wheels for months with no progress being made. Which, in all honesty, is already happening after we moved this into a research repo. We have always said for 95% of the big projects we have started at CP that we should be pressing forward not debating everything into the ground, so let’s do that here.
This is a research repo plugin, let’s use it as such. Experiment, break things, whatever necessary.
When and if we start to look at actually pulling this into core then sure we can have these other discussions.
Agree, my comments were made thinking about integration of this project into core. In the meantime the research plugin is a great way for people to test this out and continue working on it.
A bit of an aside, but I don’t think we’re ready to make this recommendation – and I’m not sure when we would be ready to do so, either, given that we still support migrating WP sites to CP.
WP plugins that are compatible with 4.9 should continue to work perfectly fine with CP. The majority of WP plugins fall into this category (even though probably not the majority of the most popular WP plugins), and there are a lot of really useful things in the WP plugins repo that we can’t match yet.
There currently are many issues on the research plugin repo. I am willing to put effort in the issues that really matter under my mentioned point of view. So I suggest to make this distinction (what is “back-compat waste-time” and what is “really-necessary”). This distinction can be done by adding the corresponding label to the GitHub issue, and we can discuss together what falls into what category.
For example:
FullScreen issue would be “really-necessary” (I already found a solution for this one, did not PR yet but I left a description on the GH issue if someone wants to test it)
Multi lines thing would be “really-necessary” to not abandon old content. But in this case it could also be fixed with a TinyMigrate plugin that actually adds the paragraphs and updates the posts content in the database, instead of “hacking” the tiny editor itself. Somehting like a plugin that applies wpautop to all contents and persists it. So wpautop can then be destroyed.
Beaver Builder support would fall IMO into “back-compat waste-time”, since it means to keep hacking things that will carry on technical complexity. This is one of those things where the user should choose between CP 1.x + Beaver or switch to CP 2.
… and so on.
Making this distinction in issues is crucial to keep focus on what matters. Or it will just be a growing list of issues that will become unmanageable and “spinning our wheels for months with no progress” will become a reality.
Also, if the community grows in the future, the “back-compat waste-time” issues could also be worked on to potentially add v5 editor to CP 1.x.
Dont worry about Beaver Builder, when it gets added to the core codebase we’ll add support for it our end if its possible, if it isnt the editor in Beaver Builder already falls back to a basic editor.
I think the main thing for us to do is provide a way to downgrade to v4 temporarily. So users have time to bring stuff up to date. Similar to what WordPress does with Gutenberg.
Introduce it in the initial version, say 2.0.0. Add a warning about the filter going away in 2.5.0, and then remove it in 3.0.0. Including information that users can continue using version 1.x since it’s an LTS version.
Is something like this reasonable from core development, plugin development, and user perspectives?
The phase of “downgrading to v4 temporarily” and “bringing stuff up to date” should happen primarily while TinyMCE v5 is still released as a plugin.
We might also need the filter to drop back to the old editor later on, but getting as much of the work done as possible using a plugin is a less disruptive path for users.
Instead of a temporary filter, it could be more like the Enable jQuery Migrate Helper plugin does. It catches the JS errors, explains the problem in the admin, and loads the previous version so the site can still work. That way, the extra files are not in core, you don’t have to deprecate a temporary filter, and the user is in control of when the switch to the new version happens (when all plugins are fixed).
Just wanted to mention that work on backward compatibility (and the editor, generally) is proceeding and progress is being made. We’ve got open issues for all the existing (v4) TinyMCE plugins to help ensure that nothing critical is missed. In the meantime, quite a few people have been submitting issues, providing helpful contextual information, and even a substantial pull request has come in. A big thanks to all who have been putting in the time and work on this!
Agreed. And, to clarify, it doesn’t look like wpautop is going anywhere; doing away with it would create a monumental amount of work for end-users. We don’t want our fancy new editor to be the next Gutenberg, after all.
