So if not Gutenberg then...?

[james]

Hi @btopro, thanks for starting this thread. It’s clear already that different people want very different things out of an editor.

@btopro

A lot of ppl claim to enjoy MD based solutions because of the pure writing form

I like Markdown, personally. Though I think it depends somewhat on what you are trying to do. Most of what I write is text with lists and links.

If I were making more image-heavy landing pages, I’d probably want something that knows how to deal with components or blocks.

@james

we’ll keep TinyMCE as-is. We have no need to replace it and no plans to do so.

Ok, I suppose now is as good a time as any to unpack this quote a bit

We’ll definitely keep TinyMCE for our initial long-term-support release series, v1.x. The goal there is to provide a stable, predictable option for people to build websites on, and what better platform than the classic editor with TinyMCE? This is stable, proven technology that has been used for millions of sites and billions of conent edits.

Which editor ClassicPress uses by default in future versions is up to the committee. We’ve already set the direction for the v2 release series, which is around building a ClassicPress plugin directory and moving some less-used features of the core software out into plugins.

Having our own plugin directory will also allow us to provide and recommend plugins like an alternative editing experience. This would be opt-in by default, and I could definitely see HAX fitting into that kind of role in the ClassicPress ecosystem.

In order to change from TinyMCE to another default editor in a future version of ClassicPress, we’d have to get lots of testing via a plugin, and wide agreement among the community that this is a change we want to make.

So far the way we collect and measure this agreement is via votes on our petitions site, but I’m happy to discuss future plans and HAX in general here too.

@btopro

you extend HAX by extending the web. Custom elements (let’s say tab-list) are built as pure design assets that leverage the Web components specification like an API on the front end.

Thank you for using web components!

I will make some time to try out HAX soon, in the meantime I have a few questions:

• I’ve shared a bit of my perspective here, but what do you think HAX’s role could be in the ClassicPress ecosystem?

• How does the HAX editor behave in terms of backwards and forwards compatibility with TinyMCE? If I make a complicated post in TinyMCE, how does it translate over to the HAX editor? If I make a complicated post in HAX, and then disable it and edit it via TinyMCE, what happens?

• I’ve thought for a while that it could be interesting to leave post_content as rich text using TinyMCE, but start to think of a post as a list of one or more custom fields, of which post_content is just one. This could avoid some of the pitfalls of storing a blob of structured content inside the unstructured not-quite-HTML post_content field, and it could also be a way around many potential backwards compatibility issues. Is storing each component as a custom field a direction that you considered for HAX?

[btopro]

great discussion, thank you for the feedback and reasoning

@james

. It’s clear already that different people want very different things out of an editor.

Absolutely, starting this was more to hash that out then anything else really. While I work in HAX land, my intention wasn’t to suggest “make this your default editor” it was more as you suggest in the plugin ecosystem. If there’s a place for HAX in the ClassicPress ecosystem where we work on HAX to passively support the use-case you suggest (needs to work with Tiny, needs to work with older stuff, needs to work before and after HAX is enabled).

This was intended less of a “ADOPT HAX OR DIE” (that’s the slant for Drupal ) and more that our mindsets of “hey I have a lot of stuff I made before and you can’t break all that compatibility over night without pissing me off” which could help provide a place for ideas to bounce back and forth.

It could also be that when people eventually say “but I kinda want to play with a block editor” that if we can get HAX to a point where people in this community feel it’s a viable enhancement to ClassicPress because it’s philosophically aligned, to do so (organically, not as like some edict).

To your questions (the above is addressing the 1st one)…
The current plugin’s integration requires TinyMCE… as it then jumps in and hollows it out and replaces the body blob of contents of Tiny as the starting point for HAX’s editor. It’s similar integration to how Tiny injects it’s JS and hijacks what otherwise would be a bland textarea input.

I’m not sure how it translates complex post over to HAX, should render, it’s just presenting HTML after all. If the DOM of that tiny area is deeper then 2 levels of hierarchy it won’t break HAX just many conventions in it won’t recognize it to do anything meaningful. HAX is a “block” editor but without rigidly defined BS react blocks. our “Blocks” are normal paragraph tags, divs, iframes, and yes custom elements / web components.

HAX doesn’t have a concept of fields, though if you’ve played with any of the demos you might be referencing the edit form for a video or any other web component. HAX is reading JSON Schema dynamically off of the web component and building a form which is saving the data by writing HTML in the page that matches the properties, attributes, and slotted (inner HTML that’s tagged) areas. By doing this, you can get highly structured content in concept yet in the DOM it’s still a single or handful of tags being placed in the page with properties filled out in the tag. Complex (array / object) data is json encoded and stored w/ the element though we only have a few elements that operate this way and largely don’t recommend it unless it’s absolutely necessary (image gallery, tab list, play list of media as possible examples).

Again, not trying to coopt nor would I want HAX to be the default editor of an ecosystem (I’ve got 6 ecosystems I’m playing in at the same time + 2 of my own platform I’m building that it’ll be the default in). But, given the philosophical alignment we have in our projects if there’s any room for people in this community to try HAX inside of ClassicPress (via plugin) and offer feedback on how we can make it work better with TinyMCE to augment when needed, or provide an alternative perspective, it’s something that I think could help both projects.

My community wants to simplify the transition from old to new world editors instead of just flipping people the bird so feedback in how we can make the more possible is invaluable to us. Also, long term, the Gutenberg question from clients of having website tonight software and “why dont I just use Wix” will keep being a nagging issue and maybe, if it becomes a viable solution to people, HAX can be one of those options without people going back to Gutenberg which will not adopt our vision of the future.

[rotello]

I love medium way of writing ( i hoped Gutemberg was like that when they announced it).
to say the truth also Facebook note editor and Linkedin is Ok…

Manolo

[LinasSimonis]

@viktor

I wouldn’t replace TinyMCE in the core, but making it easier to allow a plugin to replace it if needed could definitely be something worth exploring.

This is how a proper CMS should be buildt. Even having opportunity to install Gutenberg editor, if someone misses that. Freedom (in form of plugins) vs. dictatorship.

[btopro]

@LinasSimonis

Freedom (in form of plugins) vs. dictatorship.

[treb0r]

I think the future is about properly structured content, like https://sanity.io.

The thing that most put me off about Gutenberg (apart from the dictatorial approach), was the use of html comments to delineate the blocks in the DB. This is just crazy, and a nightmare if you wish to consume data from WordPress with another system like Gatsby. Blocks done right, with their own DB tables and all, would be fantastic for WordPress / ClassicPress.

[timkaye]

Absolutely right about the use of HTML comments. Sheer madness!

[LinasSimonis]

We have blocks done right in the form of widgets. I hope, CP will expand functionality of widgets in the future.

[joyously]

I clicked your Codepen link to try HAX, but it warned me that it might not work in my browser. I went ahead anyway, and just saw a white area below the code. I couldn’t see the HTML that it said was there.
So I think you have a ways to go yet. and concerns with browser versions. Not everyone uses the bleeding edge of browsers.

Another thing on the topic of different editors is how difficult it is for the theme to style it to resemble the front end. TinyMCE in core is pretty easy because it uses iframe. Gutenberg is a nightmare because all the UI controls are mixed in with the user content, and the specificity of the CSS is very different from front end to back end.

TinyMCE also has a simple interface to extend the toolbar. Themes can add a filter to the config to add “formats” for users to apply. That’s one PHP function and the theme’s custom classes can be added to any content.

[johnstrasser]

I mentioned in another post (roadmap idea) my thoughts that everything should be a plugin. Including the editor. The base editor is just a plain text-area where you type (or paste) code. No formatting at all. Then if you want tinyMCE that’s a plugin you add. You want a page builder, you add that. And even that plain text area would itself be a plugin.

This way I can have my clients use Libre-Office or some other clean html desktop client where I’ve given them a template with predefined styles and they can just copy-paste it in. Even this editor here in the forum has more formatting than I would have as the “default”.

Just my $0.02

JS

[ozfiddler]

I seem to recall Joomla was like this. It came with a few basic editors, but you could also choose “no editor” and you would get the plain text area that you describe, no toolbar. If I was the only one working on the site, I’d often use this option and simply type in the html.

[anon71687268]

Just to mention, the visual editor can be removed with a one-liner in a site-specific utility plugin or the functions.php file. This removes the Visual and Text tabs above the editor and leaves just a few rudimentary buttons.

add_filter('user_can_richedit', '__return_false');

[ozfiddler]

I didn’t know about that. Nice!

[treb0r]

@anon71687268

Just to mention, the visual editor can be removed with a one-liner in a site-specific utility plugin or the functions.php file. This removes the Visual and Text tabs above the editor and leaves just a few rudimentary buttons.

add_filter('user_can_richedit', '__return_false');

That’s new to me too. I’ve only been using WordPress for 10 years.

[ElisabettaCarrara]

Just slightly OT, but not quite.
I appreciate @anon71687268 approach (one line of code to rule them all).
IMHO it’s the easiest option and the less dangerous.

[timkaye]

Yes, filters rule! One of my favorite features of WP/CP.

[anon71742606]

This question has been mulling in my head for a few days too.
It doesn’t really seem to have a definitive answer yet.

There are valid competitive considerations why WP decided to go ahead with GB.
It is fine to say that GB is not the answer (for numerous valid reasons), but eventually (around v3) there will need to be some alternative solution.

@LinasSimonis

We have blocks done right in the form of widgets. I hope, CP will expand functionality of widgets in the future.

I am a fan of widgets, but I also realize that they can’t solve all problems.

Something like Elementor can be used to deal with creating columns and such.
Columns and getting text to display correctly inline next to images was a major headache for me when I started using WP (years ago).
But how long will such solutions be maintained if a large number of people are adopting GB?

The other possible solution for me, is that themes will need to become a lot more flexible and creative with widget areas than they currently are.
But this would require buy-in from theme authors.

Blockquote

[joyously]

@anon71742606

The other possible solution for me, is that themes will need to become a lot more flexible and creative with widget areas than they currently are.
But this would require buy-in from theme authors.

Themes are more for unifying the pages of a site, not for individual content on each page.
But, I agree that widgets and shortcodes are the blocks that already exist that work well. I put my endorsement of that into the theme Twenty8teen (Twenty8teen – WordPress theme | WordPress.org) which allows a lot of flexibility in layouts by using widgets for everything. I even made it easy to apply the theme’s classes to the content by using the editor’s Formats button. (Only works on Classic block in GB.) But themes should not be involved with the content since the theme can be switched at any time.

For the actual content area, users that don’t know HTML or CSS have a few options of plugins that supply a modified interface. I doubt it would be that difficult to enhance the existing editor. Several plugin authors have done it already.