So if not Gutenberg then...?

But that is surely just a criticism of this forum software which does seem a bit confusing and clunky.

There are other forum softwares (e.g. Xenforo) that are a lot better (IMO), more intuitive to understand.

As I see it though, the old WP editor was very good. Surely it would have been possible to integrate some blocks into it for those people who wanted blocks, but could be ignored by those who just wanted to write.

For example, inserting an image with a caption is a block as far as I can see. You admit, edit the alignment and size it floats on the page how you want.

Something similar but a text box would be ideal, something like you might at in MS Word or Mac pages for a floating text box.

But this may be what so many people are bashing WP for on the forums, making Gutenberg the cor default not something as an option for those who want it.

The forum text area (which is fine for this type of conversation) was an entry point to the authoring experience setup :slight_smile:.

I believe this is the case too (as an outsider). I can’t believe they replaced Tiny as core editor and have said they are deprecating that. I’m obviously building something that at least will draw comparisons and I’d never force that option on anyone without having Tiny / a baseline editor for fallback among my own user base. Now, if there was like Gutenberg: a WP Production and it was default there… I think there would be less headaches for all :slight_smile:

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

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.

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

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.

:clap: :clap: :clap:

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?


great discussion, thank you for the feedback and reasoning

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 :wink: ) 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.


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…


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.




4 posts were split to a new topic: Accesibility and UX in HAX

I think the future is about properly structured content, like

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.


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


5 posts were split to a new topic: Page builders discussion

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


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.


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



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.

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');


I didn’t know about that. Nice!

1 Like

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


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


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

1 Like