XF 2.4 Tiptap: A new editor for XenForo

2.4 editor flare.webp
Rich text editors are hard. When you drill down into how they actually work, it's a wonder why there are so many of them, and why developers would willingly spend a significant part of their life working on one. At XenForo we have been through ... counts on fingers ... three different rich text editors in our history, so if we're being generous we can at least attest to what a feat of engineering they are and how difficult they can be to get right -- and all we have to do is implement them.

That's no easy feat either, though. We have an increasing number of features that we need from an editor, we have a layer of conversion from HTML to BB code (and back again), and we have an overall user base of millions of members across all of our customers who all seem intent on breaking our editor in weird and wonderful ways. So picking a new editor is fraught with risk and challenges. Sometimes, even when we pick the right editor, it doesn't always stay that way.

Over recent years we've been keeping a close eye on the developments within the rich text editor space and while there are a few interesting projects, there is only one very clear winner, and that is Tiptap.

What is Tiptap?​

Tiptap is a completely modular, open source and headless editor framework. Headless means that there is no provided user interface. Modular means you can enable only the functionality that you need. It is so modular that, technically, you don't even have to enable paragraphs or text (though that might impede its usefulness). It also has a fantastic extension system that allows us to not only create our own extensions, but also extend existing extensions! (more on that later).

Tiptap, which is itself powered by the amazing ProseMirror toolkit, does not simply attempt to decorate input with arbitrary HTML like most rich text editors. Rather, it has a very strict (but extendable) schema made up of Marks and Nodes. Marks are inline formatting (such as bold and italic) and Nodes are block-level formatting (such as paragraphs, quotes, and code blocks).

Your first look​

Strap in, because there's lots to show you. But first, an artist's representation of how it might look in either light or dark styles:

2.4 editor gradient.webp


The overall look and feel of the editor isn't 100% finalised at this point, but the current iteration, as pictured above, does lean into being familiar. One of the notable changes currently is that we have moved the toolbar to the bottom of the editor, making the controls more accessible, particularly on smartphones.

Want it at the top? No problem, that's a single line of CSS to make that happen.

The toolbar is, as ever, managed entirely through the existing editor button manager in the admin control panel, so the toolbar itself can be made as full-featured or as minimalist as you like.

Great for users and power users alike​

For a lot of things, you might not even need to use the toolbar. The brave amongst you might even choose to disable the toolbar entirely, thanks to the simplicity with which many editor features can be used.

As part of the overall schema that powers Tiptap, "input rules" can be defined by developers for each extension, which, in short, are "Markdown-style" editing:



Power users will not only be able to use Markdown-style syntax to produce content - which is enabled for a significant amount of editor functionality - but they will also be able to see the formatting change in real-time.

What you see is really what you get​

In fact, all core editor functions have a visual representation of their content, whereas they might not have previously. We are putting an end to seeing raw BB code syntax in the editor (unless you type it yourself, which still works):



This level of visual clarity for what your final content will look like extends even to code blocks, which are now fully syntax highlighted in the editor. The syntax highlighting is provided by highlight.js. As a result, we have upgraded our BB code syntax highlighting for code blocks to also use highlight.js going forward. We are including more languages (and more relevant languages) by default, and it remains easy to add additional ones to fit your particular niche.



It truly is a "what you see is what you get" experience, and to underline that even more, wait until you see what happens when you paste an embeddable link (best viewed full screen):



A consistent UI powered by XenForo​

As we mentioned earlier, Tiptap is a completely headless editor, meaning we have built the entirety of the UI that you can see. This is now more consistent and more in line with the default XenForo styling than ever. With our previous editors, there was always a hybrid of different UI pieces: some from the editor itself, others that we bolted on. For example, in our current editor implementation there are three distinct UI components we use - Froala pop-ups (insert link), overlays (insert media) and menus (emoji). With the new editor, everything you see is crafted from default XenForo functionality and styling, ensuring consistency:
CleanShot 2024-12-17 at 16.36.31.gif


By the way, the "Insert image" menu of the editor now supports multiple file uploads, including when dragging and dropping!

An exciting experimental editing experience​

While the new UI for the new editor will be very familiar to most, because we now have full control over what the editor can do, we are also experimenting with more innovative methods for writing content. Let's have a sneak peek now at what that might look like (best viewed full screen):



We haven't yet fully decided what form this new editing experience will take. It might be something that is user-selectable, admin-selectable or something that can be enabled as a hybrid with the toolbar. Your thoughts on this approach are welcome!

Extending the editor​

All of this additional functionality is possible, not only with the strong foundations provided by both ProseMirror and Tiptap, but also through an extremely flexible and well thought out system enabling us to build our own functionality. By virtue of that, add-on developers are going to have a great experience bringing new features to our new editor.

For those of you less focused on development, this might not be quite as interesting. But let's just take a look at an example extension that adds some functionality to the editor:



While this is not (currently) shipping as a built-in feature (we haven't even created an associated BB code to render it in posts), we wanted to share it as an example of how easy and intuitive Tiptap is. Here's the sample Tiptap extension code we wrote that powers the functionality seen in the previous video:

JavaScript:
XF.EditorExtensions.registerExtension(({ Node, InputRule }) =>
{
    const inputRegex = /^!!!(highlight|important|success|warning|error)[\s\n]$/

    return Node.create({
        name: 'blockMessage',

        group: 'block',

        content: 'block+',

        defining: true,

        addAttributes()
        {
            return {
                style: {
                    default: 'highlight',
                    parseHTML: element => element.getAttribute('data-style'),
                    renderHTML: attributes =>
                    {
                        return {
                            'data-style': attributes.style,
                        }
                    },
                }
            }
        },

        parseHTML()
        {
            return [
                {
                    tag: 'div[data-type="block-message"]',
                },
            ]
        },

        renderHTML({ node })
        {
            return [
                'div',
                {
                    'data-style': node.attrs.style ?? 'highlight',
                    'class': 'blockMessage blockMessage--iconic blockMessage--' + (node.attrs.style ?? 'highlight'),
                },
                [
                    'div',
                    {},
                    0,
                ],
            ]
        },

        addInputRules()
        {
            return [
                new InputRule({
                    find: inputRegex,
                    handler: ({ state, range, match }) =>
                    {
                        const { from, to } = range
                        const tr = state.tr

                        const node = this.type.createAndFill({
                            style: match[1]?.trim(),
                        })
                        tr.replaceRangeWith(from, to, node)
                    },
                }),
            ]
        },
    })
})

A full breakdown of exactly how this works is beyond the scope of this post, but feel free to spend some time understanding it and the editor docs. If you have existing editor-based add-ons, the great news is that as long as you have some basic understanding of JavaScript, you should be able to produce your own extensions. We are not implementing any additional frameworks; everything is based on vanilla JavaScript.

One more thing...​

The astute amongst you might have already noticed that new lines work differently in the new editor compared to the current one, and there's a very good reason for that. We are pleased to announce that, finally, we are going to be using paragraph (<p>) tags properly starting with XenForo 2.4.

Hitting enter/return in the new editor now creates a new paragraph (with appropriate spacing). This may take a few moments to get used to, as hitting enter/return will now produce new line spacing equivalent to pressing enter/return twice currently. You can insert a "hard break" (producing a <br /> tag) with Shift + Enter. While this might require a brief adjustment, it is now consistent with how many applications and office suite tools work, so we don't expect it to take long.

The correct use of paragraphs doesn't stop with the editor, as we now correctly render content with paragraphs too!

HTML:
<h2 class="bbHeading">A brand new editor experience!</h2>
<div class="bbImageWrapper " title="Happy Season 9 GIF by The Office">
    <img src="https://media3.giphy.com/media/o75ajIFH0QnQC3nCeD/200.gif" class="bbImage">
</div>
<p>You might <b>recognise</b> the concept from applications such as <a href="https://notion.so" target="_blank">Notion</a>. You can add nodes from anywhere!</p>

<p>You can duplicate nodes. And move them around!</p>

<blockquote>
    <p>I've never had so much fun in an editor!</p>
</blockquote>

We haven't even changed the underlying BB code syntax. This is achieved with a brand new BB code parser which intelligently detects the correct boundaries for paragraphs and is able to distinguish between line breaks and paragraphs.

More coming soon!​

Thank you for joining us on this first look into the new editor we're implementing in XenForo 2.4. We're excited to get this in your hands in 2025. In the meantime we have some additional things for the editor that we're still wiring up:
  • Improvements to the developer experience for implementing custom editor functionality, BB code and custom buttons
  • Making use of the new editor elsewhere in XenForo
  • Further improvements to the UI and UX
  • Finalising the introduction of the experimental experience as an option
This will be the final Have you seen...? thread for 2024 and we will be back in the new year with even more to show you as we approach the final stages of this release.
 
..this is incredible.

The relatively easy way to implement new extensions (!!!), the simpler look with toggleable toolbar, the node system... can't wait! :D
 
I'ld second being able to disable auto-markdown formatting in the editor, at least some way todo it via javascript.
It needs to be an option. Or I'll stick with 2.3. I hate markdown, always have, and have had to deal with this unpredictability too often as a content creator. And I still seem to recall that disabling markdown was not optional on a prior XF version (perhaps when Froala was introduced). Someone created an add-on to disable it, and then it was finally given an option in a minor update later.

Simply put, markdown is a relic of decades ago before WYSIWYG editors and just needs to die.
 
If users want to insert a newline (for whatever reason, it's not really our job to judge that, isn't it?) they IMHO should be able to do so easily - as it was since XenForo 1.0.
That's a good point. If you think about it, a "new line" is the same as those of us who used typewriters long before computers came along. If you want one line break, you hit the carriage return* once. If you want two, you hit it twice. Nothing there was automated; what you typed directly translated into what appeared on paper. Until the ribbon ran out.

That is simple, understandable behavior for anyone who uses a text editor. I am more concerned with unpredicability, as most of our users are computerphobes who just want to communicate clearly and don't know or care about "proper" HTML and marking a block with a <p></p> pair behind the screen. They expect that "typewriter" behavior when replying.

And yet...

I'll admit, the same behavior bothers me in Word™, but only slightly...where a "return" starts a new paragraph. I'll admit that decades later, I sometimes still find myself hitting "return" twice when I'm ready to go on to the next paragraph.

I'm wondering. One solution (which could perhaps work better on mobile) might be to create separate paragraph blocks only after two returns (newlines). That keeps the HTML clean behind the scenes, yet it still allows single newlines for those who need them.

But at least this issue isn't a dealbreaker like markdown...



(*Most youngsters probably don't know what "carriage return" means, what ribbons are, or have ever used a manual typewriter. 😉)
 
Simply put, markdown is a relic of decades ago before WYSIWYG editors and just needs to die.

I'll take a wild guess that you are not a software developer then?

Markdown is very popular amongst developers for creating all sorts of documentation for software projects (Github is full of them)

Not everyone works in a graphical environment and markdown allows for the rapid creation of richly formatted text, without the requirement for a WYSIWYG editor. Indeed, for many people, it is a much faster way of creating rich content than they could ever achieve with a WYSIWYG editor.

I don't have a problem with there being an option to turn it off though - not every community requires this functionality.
 
It's slower for me, and I've written for decades. Ctrl-B or Ctrl-I in a text editor is better than having to type extra characters and worry about encapsulating the text properly. Adding a link to existing text in current editors (whether they're in Word, or even here in Froala) is as simple as typing Ctrl-K and pasting the link into the dialog that opens. If these are taken away from us, 2.3 will be the the newest version I'll offer to users. Or I'll pay someone to create an addon that gets rid of the new text editor in favor of one I choose.

Honestly, as much as I hate WordPress, their classic editor has always had a far more reliable text editor.

If you think about it, the very limited, narrow scope of what developers type in a text box pales to the number of non-developers who actually use the forums I work with, and the Joe Average computerphobes don't care to have to learn something else new.

I don't have a problem with there being an option to turn it off though - not every community requires this functionality.
That's all we're asking. If I ran a forum that did service developers, by all means I'd have it enabled for them. Or better yet, let us set a default on/off for Markdown, and give users the option whether or not to enable it. That's the only way I could see this making sense.
 
I am witholding judgement until I see the new editor. If the Markdown looks like it will get in the way or make things difficult for my users once I see it here or in a beta, then I won't upgrade until things improve or the option to turn it off is available. But I don't see that happening with us. Most of our posts are one or two paragraphs of text and maybe an unfurled link or an embedded image/video. If it does those as easily as the current editor, I am probably good.

I have played with Markdown a bit in the context of looking into changing my notetaking software from MS Notes to Obsidian and it seems fairly manageable in that context but the issues pointed out with it being triggered inadvertently seem to be genuine concerns. So maybe a way to turn it off is merited. Just not sure I will need it until I see the end product.

Do like the idea of paragraph breaks, though. Then again, I practically live in word processors a lot of the time outside work since I write for a hobby.
 
Thumbs up for Obsidian.

I keep dreaming of a xenforo / Obisidian mashup as a knowledge base / inventory management system for our family.

Roughly speaking I want the documents to be created and editable in obsidian but embedded in xenforo threads (each obsidian note has one thread). Xenforo can be for discussing the topics (obsidian notes).

Addendum:
Onenote sucks. Notion and Obsidian are way better.
 
One of the notable changes currently is that we have moved the toolbar to the bottom of the editor, making the controls more accessible, particularly on smartphones.
I really like the idea of having the toolbar at the bottom of the editor. I have tested this by moving it in the current version and one thing is that although it is better on mobiles, there may be an issue when there is a large list in a dropdown then the iOs keyboard is in the way. So could the drop-downs become "dropups?"
 
Markdown is very popular amongst developers for creating all sorts of documentation for software projects (Github is full of them)
Oh, really? I never used it. I am a developer for decades.

But, the editor is not for Software Developers, its for the default user. And do they know markdown? I think not. Do we want to force millions of users to use it? No!

We shouldn't do this.

Ask the users, not the developrs or the admins, what they need.
 
Oh, really? I never used it. I am a developer for decades.

But, the editor is not for Software Developers, its for the default user. And do they know markdown? I think not. Do we want to force millions of users to use it? No!

We shouldn't do this.

Ask the users, not the developrs or the admins, what they need.

Is markdown enabled by default on the current XF versions? Is it something that can be disabled with an option? If so, let's just keep it like that, please. I don't know if I've disabled it on my sites, or not, or if that's even an option, so none of this may affect me.

That said, I agree with the post quoted above! I've never given any thoughts to the use of markdown and I've been frequenting forums since around 2008, maybe sooner. I've been administrating forums since 2012. Still, never used markdown and, frankly, don't care to learn it now. I'm sure none of my users know it, or care about it, either.

Bottom line, I couldn't care less whether it's included or not but if there's a high likelihood that it will cause confusion for my users, and reformat their posts in a way they weren't expecting, causing them to DM me to fix it, I'd say there should definitely be an option to disable it.
 
I thought @Kirby was actually in favor of the new paragraph on every Enter press.
You probably misunderstoof me or I should have been more precise in my comment:
If Enter & Shift-Enter are to be used it should be Enter for new paragraph and Shift-Enter for line break / new line (like in word processors) and not the other way round.

Bur IMHO it might be better to avoid Shift-Enter at all.
Is markdown enabled by default on the current XF versions?
No. It's available since 2.1 but disabled by default (probably for good reason?)

Here is the option description:
If enabled, some Markdown styling will automatically be converted to BB code when saved.
Markdown is a simple method for adding formatting by using common patterns such as changing example into italics.
This can make adding formatting to messages easier, but it can sometimes cause unexpected formatting changes.

Is it something that can be disabled with an option?
It can be disabled in 2.1-2.3, but the comments by @Chris D somewhat suggest that Markdown can't be disabled in 2.4.
 
So there are two slightly related but different things we’re talking about here.

The new editor has some Markdown-like shortcuts which are only applied as you are typing. Not on paste. Not on edit. This at least makes the feature slightly less “dangerous” because, well, what you see is what you get.

The current editor has no support for markdown at all. Meaning if you surround some text with asterisks, you will see asterisks. The aforementioned option controls whether the content attempts to parse and render Markdown syntax to BB code while being saved. This also means if you edit existing content (created before the option was enabled, or particularly old content) and it contains Markdown syntax, simply saving it could effectively change all of the formatting.

With that in mind there is definitely a use case for having two different options or the existing option is repurposed to only target the functionality of the editor and the existing on-save parse/render system being retired.

Feedback on the editor input rules is noted and being considered.
 
Back
Top Bottom