Editor Feedback

[Matt]

Thanks all for the feedback so far. There's lots to think about.

Can I reframe the question a little, though? Taking on board what you've read in this topic from the 26 customers who've replied but not forgetting the thousands of other customers and the potentially millions of end users, what would you do if you had 2 weeks to focus on the editor? Keeping in mind backwards compatibility and existing functionality?

I'll run through some of the points raised so far:

I'm not against adding parsing 'modules' such as mark-down but you do of course exponentially increase the amount of code and maintenance needed. Our CKEditor implementation is directly tied to BBCode downstream so it's not as simple as just adding a new parsing module within CKEditor. You'd also need supporting PHP to post process that.

We don't directly store *all* BBCode as HTML. Previously we stored the posts as BBCode and then parsed it on view (and then cached it). The issue with this is that we ran into trouble trying to parse it on view and parse it back for CKEditor (as what CKEditor needs is slightly different from what a normal post view needs). This introduced quirks and bugs. Worse, when you toggled HTML to BBCode mode it fired off an Ajax process which introduced bugs and quirks in two separate layers (JS > PHP (to convert from HTML to BBCode) > JS). This was especially hard for customers with a need for extended characters (accented characters such as those in the Polish and Russian languages). I got a steady stream of tickets and bug reports from these customers who found issues such as characters going missing or incorrectly becoming encoded. By the time the last release of the 3.3 series was made there was a kludge of methods and functions that converted characters over and back again through the various stages of BBCode parsing. One the post was saved, PHP code made an attempt to convert that HTML to simpler BBCode and store it in the database.

It was clear this was not a method with a healthy future as the code had become horrifically complex and almost impossible to fix with a simple one line change causing ripples throughout the entire parsing code-base that took forever to track down and resolve. Trying to fix a bug was like taking the last few turns in a game of Jenga.

My approach for 3.4 was quite simple: remove BBCode from the IPB PHP code and have it as a plug in for CKEditor. This is exactly what CKEditor is designed to do; replace the source mode with your own function. This means that IP.Board only ever has to deal with HTML from CKEditor because even when you're using the source editor, it's converted back to HTML before its saved. This greatly simplifies what IP.Board has to do and removes the Ajax step when hitting Source mode thus removing a lot of code that was a source of the character set issues we routinely faced.

This means that we don't have to store posts as BBCode anymore. We store them as *mostly* parsed HTML cleaned from CKEditor. Custom BBCode, media tags and emoticons, etc are *not* saved as parsed and still parsed on viewing the post (and then cached). This approach has allowed us to remove thousands of lines of code and all the potential bugs that it could generate.

Now, this change has been painful and I am sorry about that and I agree that we should have focused more on testing. I felt confident the editor was stable after testing it on our company forums for well over three months and having it in QA and beta testing for about a month but unfortunately we didn't thoroughly test all permutations such as HTML mode, etc. Furthermore, backwards compatibility was initially troublesome as the parser had to process posts made with previous versions of IP.Board that were all in BBCode and convert them on the fly. Matching up legacy parsing to the new parsing engine cause some teething issues which have now largely been resolved.

I know it seems that we've taken a backwards step in terms of stability but I am very confident that once the kinks are ironed out, we'll be in a much better position to move forwards. Already the code is much simpler to bug fix allowing me to race through tickets and bug reports much faster. The fixes don't impact other areas generally either now as the code is better written and each component of that code works without being intricately tied to another piece of code (tight coupling).

The JS engine to convert HTML to BBCode is brand new and as such has to face lots of untested mark-up. It's quite a feat to take a HTML document, explode it into an array of nodes and then convert them to BBCode cleanly and then back again. I'm confident we're on top of these issues too.

Things like reverting back to adding in text QUOTE tags when hitting 'quote' I'm less keen to do (not least of all because it will mean rewriting parts of the current parsing engine) so I'd like to hear what you dislike about having quote boxes appear in the editor as styled elements and now we can make that better.

Similarly, CODE is a challenge because we now use <pre> tags so you don't have to maintain <br /> to n conversion and back again. The code box that is added when you click the button is a PRE wrapper that CKEditor understands maintains its own newlines. If you manually type in the CODE tags it doesn't have this knowledge so PHP on the back-end (and the javascript engine to convert to BBCode) needs to make a guess as to where the newlines should be which leads to bugs that you never truly fix but rather push around.

Generally speaking, it's hard for IP.Board to understand what you want when you start manually typing BBCode tags while in the RTE mode. You have to take the HTML CKeditor gives you and parse it twice (once to clean that HTML and again to parse BBCode) which will cause issues and bugs (again, that are just pushed around and never truly fixed).

I hope you understand this post was meant to educate on the challenges and not a flat our rebuttal on the feedback gathered so far.

[Wolfie]

My feedback to you is just have backwards compatibility. I'm a member of a very large vbulletin forum which recently switched to xenforo, a forum software that doesn't have bbcode. The users there are very confused on how to get the editor working. Some users are saying how they're losing interest in the site because they don't understand how to submit content anymore. Yes, it's a transition process, and with your plans it's one that we will all have to force our users to do, but I think you can make the transition smoother. I suggest that you support bbcode input in 4.0. Convert to html on submission and in the editor keep it as html whether it be ckeditor or standard mode. Like Matt and Marcher keep saying, there is no difference between [ b ] and <b>. If a user can type in [ b ], have it get stored as <b> and later they come to edit their post and see <b> or even <strong> I think they will catch on a lot more quickly, and it will be a lot less painful for everyone, than if you were to just go out and say "Ok guys, from now on you have to type in <b> instead of [ b ]".

Indeed. If I submit a post and it converts [?] to <?> (in source mode) then fine. If I need to move it I can, no big deal.

Here's what I'm wondering though. How does someone generate a codebox without typing in a huge chunk or HTML code? How does someone know what to type in? Maybe I'm missing something here, but moving away from bbCode to HTML is, IMO, a bad idea. At least, on a forced level. If bbCode is still supported, even if only on a legacy level, then that works. But expecting someone to know HTML for a codebox or to generate a quote, etc, is a bit ridiculous. There are some who barely understand the idea of using size/url tags, don't expect them to understand something like this...

<a href='urlHere'>
<span style='font-size: 11px'>

So yeah I agree, at the very minimum, support input of legacy code.

There are options and nothing is completely off the table for 4.0, so keep a positive discussion flowing.

Keep bbCode functionality. I seriously don't want to be required to fill in complete HTML tags to include a youtube video in a post.

Every update of IPB = editor was problem (3.1.4 to 3.2.0, 3.2.0 to 3.2.x, 3.2.x to 3.3.x and last 3.3.x to 3.4.x - nearly 2 years). For me that says that development team can not execute their work - change team and let them to experiment next few years ... or send them to extra education, but try to sell finished and working product.

Developing an editor is no easy task. The sheer size of the various IPS products alone is massive. It's no surprise to me that they will use 3rd party products when possible to not only speed up development but be able to devote more development resources to other areas. Yes, there are some issues, but it's not something that can planned, developed and fully bug-free within a day.

1. Cater to normal users who have not a clue of what bbcode or HTML are.
2. Cater to power users who have a firm grasp of bbcode/HTML and might even prefer typing it out plain rather than using a WYISWYG environment.
3. Cater to communities who have different goals and different levels of technical competence.

Nice list, I agree.

[TSP]

Thank you for the feedback thus far and we're especially glad to see your thoughts on BBCode. It is indeed the crutch of the editor quirks and issues and will undoubtedly need to be phased out as we move forward with modernization to take full advantage of CKEditor.

I hope you'll still keep BBCode and a source mode (whether it be html or in bbcode) around.

Mat, it's clear you're a power user and that's great, but unfortunately, you do not represent 95% of IP.Board users who simply want to use a WYSIWYG, click pretty buttons, create their content, make things happen and move on with life.

What about communities where a lot of the users are power users?

[Bob van Leeuwen]

I'm a member of a Dutch Gaming Community, I wrote some tutorials for them how to use IPB. I was talking with the owner of the website, and he asked if I could re-write the tutorial I made before, because member's don't understand the editor at all.

I thing it is just to complet at the moment. They just converted over from SMF, they are used using BBCode, some users don't use the full editor, but the BBCode mode. So just keep BBCode in it. I also still use it some times. I'm all for making the posts saved as HTML, but keep BBCode in. I thing a lot of users still use it.

[AutoItScript]

My forum is programming language based and makes extensive use of code related functionality (hence why I'm always posting code tag bugs :smile: ) 80% of the posts on my forum are code and I need what the user types to be stored and parsed properly.

Code Tags

For the the RTE editor - I've finally got my head around the <pre> design decision. But as long as a user can physically type in [ code ] in the RTE and have it do something then you are just going to get bug after bug logged to the point where the bug tracker will need to scan every entry and auto-reply with the "Don't type code in RTE" template... On my test forum the only way I can think of preventing this has been to make the following modifications:

1. Remove the bbcode tag for [ code ] so that when a user types it in RTE it clearly does nothing - no code formatting appears which is a clear indication to the user that they (and not the forum) is doing something wrong. It still works in STD mode because that is not a real bbcode it's just a signal for CKEditor for use <pre>

2. Modify the rebuildposts functionality so that it goes through existing posts and converts old [ code ] to <pre>

This is fine for my needs and my community, but I doubt other admins will have the stomach for that approach as it has to be done straight after the upgrade and rebuildposts is risky (it currently breaks code entirely in 3.4.1 - http://community.invisionpower.com/resources/bugs.html/_/ip-board/code-tags-from-33-are-double-spaced-in-34-r40163 ) - so even with my modifications I'm still putting off my upgrade,

My members are used to just being able to start typing code. Clicking a button and selecting a language type, and then typing it in a dialog is a bit annoying. Is it possible to add a shortcut key that at least starts the code block in the editor.

Custom BBCode

Not directly editor related, but relevant to anyone fighting with custom bbcode. Take a look at an example post on my forum: http://www.autoitscript.com/forum/topic/146866-best-coding-practices-in-autoit/

I use a custom bbcode of [ autoit ] to use geshi to syntax highlight my language. Default code tags incorrectly highlight it so I gave up on those years ago. I wish there was a prettyprint force plain option, auto detect is awful. If I post a text file why would I want something to guess and randomly highlight it?

In 3.3.x I simply added a custom bbcode, took the input, ran it though my geshi class, and passed back the output. It works great. In 3.4 this is completely broken. The input to the bbcode plugin has been so preprocessed to such an extent that it is missing input that that user typed, or it has been mangled. I spent a few weeks writing functions that allow the custom bbcode functions to work around these issues until it became clear that even when my function outputted html in the right format that there were just too many places in the other source files that had this kind of logic:

1. Do some stripping, purifiying, XSS check, n to BR conversion, < p > wrap, < p > dewrap, etc.

2. Unless it's a <pre> tag, in which case do something else or nothing at all,

Once I got that far and read Matt's comments about wanting to work natively with <pre> I decided that custom bbcodes are no longer usable for what I need and it was too much effort fighting the parsing. I then starting trying to add my language to work as a CKeditor <pre> style.

[Matt]

If you click the CODE button on the editor, you'll notice you can change the language syntax choice. I will add a 'none' in there too so it doesn't try and color the text.

[PeterUK]

--snip--

I know this seems like a huge thing to ask at this stage but why was CKEditor chosen? Did you consider using TinyMCE which does actually have a BBCode mode in its source mode and RTE available for it as well? I've not implemented either but it seems to do pretty much what you have CKEditor doing here but natively:
http://www.tinymce.com/tryit/bbcode.php

[Matt]

Yes, I evaluated both TinyMCE and CKEditor and CKEditor wins hands down. Google around and you'll likely find the same.

That plug-in isn't very well developed. Try using FONT tags for example. CKEditor also has a 'proof of concept' plug-in but it is also under developed which is why I decided to write my own.

[TSP]

There is no way to copy quote and code boxes when in RTE-mode btw, that is one of my issues with it.

Also the fact that a lot of users on our community are very used to using bbcode. Users with thousands of posts that have stayed with us for 10 years for example. Not someone you want to cause a lot of trouble for :)

I'm not overly exited about having to do a lot of testing with editing old posts etc. on test upgrade, I'm just going to assume it will break a lot of our old posts and a lot of new bugs will be discovered.

At this point I'm tempted to upgrade from 3.2.3 to 3.3.4 and not give any more thoughts on 3.4 for now. In 3.3.4 the only real issue I noted with the editor was the lack of buttons in bbcode mode, but that is the same in 3.2. Atleast the editor seems to work a lot better in 3.3.4 compared to both 3.2 and 3.4. The problem being of course that it will make us having to invest more time in doing both upgrades.

[Rimi]

I hope you understand this post was meant to educate on the challenges

FYI you succeeded. I can definitely appreciate how much you've done and how much you have to deal with in regards to the editor and moreso now.

I think the biggest issues with the quote and code boxes have already been stated. Copying and pasting quotes is a big one for me...I don't understand why it doesn't work. In RTE mode everything in this box is HTML. Whenever I copy some html table and paste it into the editor it still displays the table (and obviously breaks down when the post is submitted) so why isn't it displaying the quote box? Other than that though I think you know what we want.

With that said, there will definitely be improvements to the code and quote functions to address concerns such as multi-quoting,

split quotes

, etc.

[mat206]

Matt, I certainly appreciate the challenges but the most crucial thing of a WYSIWYG editor is the actual What-You-See-Is-What-You-Get. When that fails you get a lot of angry community members on your hands. And @blair made a genius point in stating that the real power users of your community are going to generate the most content. They also happen to be the most familiar with all the things you can do with a forum (especially things like bbcode). It is hard to tell users of this calibre to just do something different.. and the second that something different doesn't work you get some harsh complaints and then eventually they just move on (which can kill a community if too many powerusers depart).

What I would really do is find a way to reorganize your approach a little bit. The problem that occurred is when you tried to make bbcode a plugin, because that forces all this nightmare html generation to deal with. It also exponentially increases the amount of potential bugs that are going to crop up.

I will say that I love BBCode, but more because it gives us as site owners a way to provide non-complex markup to do potentially more complex things that require a boatload of esoteric html to render. It needs to be a post-processing filter of sorts, run only to render the *finished* version of the post. Other than that, just never convert bbcode anywhere.. and that means don't convert html into bbcode. That should greatly simplify this problem because the only people who are going to be typing in bbcode are those who want to use it. The final "look" of the post will be exactly as they intend it, and likewise when they go back to edit the post it will have the same familiar look as when they created it. The WYSIWYG crowd can simply use all the visual bells and whistles CKEditor offers.

This also frees you up to provide a plugin approach to the editor. Without bbcode parsing all bbcodes will show up in the post simply as words with brackets around them. What I would want as a developer would be an editor plugin class I can modify that has these features:

• Create an HTML version of the editor I can embed into apps with content already filled in
• Ability to store/retrieve custom editor settings
• Pre/post editing processing so I can filter what goes into my custom editor widget (that can be extended from the default processing)
  • HTML can be processed by the base class method, which should provide an ability to control which html is whitelisted
• Pre display rendering capabilites (so if I want bbcode I can have it)
• An ability to allow my editor to register javascript callbacks that will allow multiquote, quote tags, other content to be inserted into the editor - if I want any other javascript to do customized stuff with the editor that would be up to me. You just worry about providing the coupling javascript code between the IPS Suite and the editor so appropriate callbacks can be registered.

Then you can drop bbcode from the editor, allow others to create editor plugins (like Joomla, Plone, etc) we can put in the marketplace. The approach is simplified since you then worry about just processing CKEditor stuff in your own plugin editor.

As a simple example one could then go an create a generic editor plugin that is simply a textarea. The callbacks respond correctly to quote/multiquote so text does get put in somewhere in the textarea. It displays html as raw html. Bbcodes are displayed as such. Then no matter what happens, so long as the appropriate html tags are whitelisted the output will be exactly like the user expects.

.. and you aren't spending so much time trying to take one more block out of the jenga stack.

.. and we can go about including markdown, bbcode, html, and anything else our heart's desire

[Matt]

mat206, thanks for the input.

The biggest issue with that, though is that if you click "B" in RTE mode, it inserts: <b> tags. So when you click on "Source" it will still show the <b> tags and not the expected tags. I'm not sure that's a complete solution as the end-user has a mix of HTML and BBCode when they toggle.

[Heyhoe]

Saying that though Matt, the only people who press "source" should hopefully understand what is going on....

[mat206]

mat206, thanks for the input.

The biggest issue with that, though is that if you click "B" in RTE mode, it inserts: <b> tags. So when you click on "Source" it will still show the <b> tags and not the expected tags. I'm not sure that's a complete solution as the end-user has a mix of HTML and BBCode when they toggle.

That's fine though because for the end-user it's on purpose. Turn "BBCODE mode" mode in the editor to what every editor does.. a "plaintext" or "raw" editing mode. That way you don't have to suffer through conversion issues within the editor either (perhaps making an exception for the quote tag since it is kind of complicated). I think if you end up starting to mix bbcode with html you can assume they already know what they are doing. So if I start doing button clicks to make things bold, that's really my choice but not an accidental one. I *could* have used a [ b ] tag, but I didn't. The marking up portion of the process is totally up to the user.

Remember, the end-user of the editor is not the end-user of the post. The end user of the post gets a uniform view no matter what. The person doing the editing also gets a consistent experience with the moment they created the post if you don't mangle bbcodes ESPECIALLY in the RTE.

I think it's more confusing to put in a bbcode tag and come back and see it gone and translated into html. It is especially unsettling for programmers on my site because right now they went from just being able to use code blocks to having something broken in the RTE that uses PRE html tags where they have to turn the RTE off to fix.

You need to restack those Jenga blocks a little and simplify this process. You are really on to something with using html purify because you can just let CKEditor do it's thing without worry. You just have to whitelist what html is allowable (ACP configuration of that would be very much appreciated). If you just cut out the bbcode translation stuff until post rendering time it should give you more time to do something else but bang your head on the keyboard fixing all these random bugs that pop up.

[TSP]

The biggest issue with that, though is that if you click "B" in RTE mode, it inserts: <b> tags. So when you click on "Source" it will still show the <b> tags and not the expected tags. I'm not sure that's a complete solution as the end-user has a mix of HTML and BBCode when they toggle.

This is more off topic... but wouldn't it be more correct to use <em> and <strong> rather than <b> and <i>?

[mat206]

This is more off topic... but wouldn't it be more correct to use <em> and <strong> rather than <b> and <i>?

That's what actually happens under the hood. He was just using the bold tag to make a point.

[Matt]

What about if HTML mode was enabled, or BBCode disabled or IP.Content was using the editor, would you still have BBCode show up in source mode mixed in with HTML?

[Weppa333]

And while you're thinking about the 0.1% of people who will use the source mode, there's still no way to upload an image in a post from quick reply.

[Wolfie]

And while you're thinking about the 0.1% of people who will use the source mode, there's still no way to upload an image in a post from quick reply.

The number of people who use source mode is much MUCH greater than 0.1%. That 0.1% belongs to those who want to upload an image from the quick reply box.

[Heyhoe]

I agree that there is more than 0.1% of users using the source mode, but having an upload in quick reply would be very nice. As currently with the way the editor works, its not obvious that it is indeed a "Quick reply" as it loads the full editor.

I still think the quick reply should be like it is on an ipad, a simple text box. and then full reply have all the options.

Currently, I would imagine that most users use "More Reply Options" purely for attaching a file.

[mat206]

What about if HTML mode was enabled, or BBCode disabled or IP.Content was using the editor, would you still have BBCode show up in source mode mixed in with HTML?

Yes, you would *always* allow this actually. There is nothing wrong with that because BBCode can add something HTML doesn't. BBCode is designed to expand to something bigger or more complex (kind of like parse tags do for templates in your template language). HTML mode wouldn't matter as far as bbcode is concerned if you just look at bbcode as a different form of markup. You don't need to filter the output from bbcode since it is sanitized by the bbcode parser itself. That's why I think you'd be fine if you save the bbcode rendering as the last stage of post rendering.

And for IP.Content bbcode's that are in the article were put there by the article writer, so it's not a big deal. If the admin doesn't like bbcode they can always disable bbcode's in the bbcode manager pretty easily.

This also allows you to have bbcode co-exist peacefully with html, because you don't even have to focus on bbcode much at all anymore since you don't bother to process it all for the sake of the editor. You can put time into just focusing on the WYSIWYG side of things. Really the only challenge here is deciding that it's actually not that bad a thing to allow bbcode and WYSIWYG formatted html to exist in the editor together. I think it's easy to get stuck on bbcode just being simple stuff like bold tags, but as an example I have [equation] tags that I provide to members that will transform mathematical equations in LaTeX format to a visual representation.

The post editor should always come back to the same exact text that they originally typed in when they edit the post. This doesn't mess with their ability to edit the post then.

[Wolfie]

I still think the quick reply should be like it is on an ipad, a simple text box. and then full reply have all the options.

Currently, I would imagine that most users use "More Reply Options" purely for attaching a file.

Perhaps something to let the user know the difference, like a little note that mentions it's a feature limited reply mode. I wonder if changing the wording of "More Reply Options" to something like "Full Reply Mode" or something else would encourage people to check out the full editor so they see the extra options.

Yes. There is nothing wrong with that because BBCode can add something HTML doesn't. BBCode is designed to expand to something bigger or more complex (kind of like parse tags do for templates in your template language).

Precisely. I don't see why bbCode is being considered to be at that point where it needs to be phased out. It's an easy to enter shortcut for people who are faster at typing than doing point and then click click click through a few different options, then needing to add some information and possible another click or two after that. I can type [ code ] faster than I can click through the options to get the same function. Also, I can type [ and ] faster than < and >, as that requires one keystroke each versus two. Not only that but if I'm forced to use <strong> then that's an additional five for the opening and then the closing tags.

[Myr]

What about if HTML mode was enabled, or BBCode disabled or IP.Content was using the editor, would you still have BBCode show up in source mode mixed in with HTML?

If we are really moving towards an all HTML world with BBCode as a plugin, would it make sense to change how we thing about "html mode"? Allow HTML for everyone and rely on the htmlpurifier to strip out undesired code. And for power users, create a whitelist of allowed html that can bypass the purifier?

On my site, one of my modules uses a more fully featured CKEditor that requires us to hack up ipsTexteditor.js. Basically, it just triggers a different configuration file when we're in my custom module. It would be nice to be able to control features from the ACP so we didn't have to modify files for our module. The features we add back in are simple enough: Table, HR, and Source. (We paste in a lot of formatted html)

[Kandice]

Precisely. I don't see why bbCode is being considered to be at that point where it needs to be phased out. It's an easy to enter shortcut for people who are faster at typing than doing point and then click click click through a few different options, then needing to add some information and possible another click or two after that. I can type [ code ] faster than I can click through the options to get the same function. Also, I can type [ and ] faster than < and >, as that requires one keystroke each versus two. Not only that but if I'm forced to use <strong> then that's an additional five for the opening and then the closing tags.

This.

I have nothing more to add because of most of the thing already been mention. I know my input wouldn't matter much and you probably think we represent only a small portion of the user based, but I think the user who still manually type the bbcode is a lot more.

When I upgraded to 3.4.1, one of the user on my forum been posting for couple month have no ideas what's going on when all his post does not look the same anymore. Everything parsed incorrectly and HTML inside the code. All Quote text misaligned everywhere. I have to tell him that when you paste a text and quote, you have to hit the Light Switch to be in source mode, same as code. It required hitting it back and fourth and wasn't very user friendly but more of time consuming and confusing to the user. He told me that in his post he type everything because it was faster and easier to do. This go the same for almost every user on my forums because this is what they been doing for years on all forum platform.

How am I gonna explain to everyone about using the Light Switch Source mode and not type out their code? But instead telling them to keep hitting those button whenever they post? Need to say, most of them left the forum because of it. I also tend to edit more post everyday because 90% of the people post this way.

[Dll]

Is this thread starting to miss the point a little? I understand there are many with a more technical knowledge in terms of the workings of the editor and the options surrounding that but the long and short story really has to be that the editor just works.

We know there is a very broad range of user types out there - some are power users, some are completely uncomfortable with any type of technology and many are something in between. Although it's potentially a massively complex thing to achieve, it's a fundamental part of any community so it has to work for all users. What does work mean? In my opinion it needs to:

• Be a true WYSIWYG editor - what the users sees in the editor needs to translate to what their post ends up as. It's not this at the moment, there's still a mix of wysiwyg and code which displays depending on what the user is putting into their post.
• BBCode needs to work out of the box - it's widely used on forum software and more importantly widely used on some major sites with forum embed codes. I see no reason to phase it out other than the complexity of making it work with the editor software currently being used - this isn't how development should work. Phasing something out needs to be based on what users are using and the fact is that BBcode is still widely known and used.
• HTML needs to work out of the box - it's not something a lot of communities use right now, but the additional flexibility, particularly for more technical forums makes it worth having.
• Documentation needs to drastically improve. Any changes will confuse users, many users probably don't understand how the editor works even now, but all this can be solved by offering a much more user friendly and accessible help page for the editor with screenshots, examples, maybe even video.
• Customisation - allow community admins to select which features are available within the editor - they are the ones best placed to understand what their membership will use or not.

The more complex the editor gets, the more important it is that it remains simple for anyone to use which at this time isn't what we have. The editor is quite complicated, doesn't always publish posts in the way that the user expects and has some bugs which end up with code being displayed and functions that people have got used to using not working properly.

I hope this ever more complex plan to re-invent the editor doesn't result in it going through a prolonged phase of broken functionality as there will come a point where users stop posting, and that's where communities will start to struggle.