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 looks scarily similar to how the Gutenberg editor in WordPress works. I got used to Gutenberg when I was running a WordPress site, but I am not looking forward to teaching my older users how to use TipTap. Hell, one of them is barely looking forward to learning how to use thread prefixes when I restructure my forum index next week. He's gonna flip his lid when I tell everyone XF is getting a whole new editor.
Don't tell him, or at least don't frame it that way. And certainly don't say anything until you've seen it for yourself (i.e. after they roll it out here). Personally, I won't say anything until I have a beta running in my dev so I know exactly what I am getting. That said, what have heard so far is that they are using Tiptop as a codebase but that their implementation will look rather like what we have now. So unless that changes, you can just say that the editor has been changed to make it better and easier for Xenforo to support but that the basic experience remains the same. I do get the concern. Sometimes just the look being a bit different throws people off. However, my sense is that Xenforo's goal is keep things as much the same as possible while leaving room to enhance the editor using the new code base.
 
from what i have read around here... nothing much is changing except the markdown is rendered as it is typed (devs are considering making it optional) and many more elements would appear in rendered form than as bbcode (like code box). toolbar looks pretty similar to how it is right now. and it would function similarly to how it is right now. power users get more ability to format posts and see them rendered without lifting their fingers off the keyboard. regulars users who mostly just use text and images and links would probably notice nothing different. except that links might also appear as rendered unfurled boxes in editor mode which does not happen right now.
 
On mobile talk to text is a great innovation that resolves many typing concerns.
I have yet to really get accustomed to using that, though I have tried the text-to-speech in GBoard a couple times. Would be nice for writing first drafts of my stories, I think, but me constantly talking aloud to my device or computer might annoy the other resident of my home. :p
 
Thank you for the exciting announcement about integrating the Tiptap editor into XenForo for posts, threads, and more. The preview of the interface and available options looks impressive.

As an advocate for accessibility, I kindly request that you ensure accessibility features are not overlooked in the development of this new editor. A fully accessible experience would greatly benefit all users, including those who rely on assistive technologies.

Thank you for your efforts, and I look forward to seeing the positive impact this update will bring to the XenForo community.
 
As an advocate for accessibility, I kindly request that you ensure accessibility features are not overlooked in the development of this new editor. A fully accessible experience would greatly benefit all users, including those who rely on assistive technologies.
Yeah, this. Even if there aren't a lot of specific accessibility features we can turn on day one, making sure there are no roadblocks for those who rely on the accessibility features of their PCs and devices is a must. I don't require them myself (yet) but some of my members do.
 
Yeah, this. Even if there aren't a lot of specific accessibility features we can turn on day one, making sure there are no roadblocks for those who rely on the accessibility features of their PCs and devices is a must. I don't require them myself (yet) but some of my members do.
Thank you for highlighting the importance of accessibility. I used to run a forum using XenForo 2, specifically tailored for blind users. Unfortunately, I couldn't make it successful because it lacked many accessibility features, both in navigating threads and forums and in writing posts.

I didn't have enough time to customize and fix things I considered basic necessities, so I eventually switched to another platform that offered better accessibility support.

Recently, I've made many adjustments to improve accessibility significantly. However, I can't tell my members that I plan to repeat my previous experiment. 😊😊

It's worth noting that XenForo 1 had excellent accessibility support compared to its successor.
 
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):
Will this allow you to use it in other elements and own add-ons without any problems, as is now the case with froala and the inclusion of inline buttons there?
 
Last edited:
Thank you for highlighting the importance of accessibility. I used to run a forum using XenForo 2, specifically tailored for blind users. Unfortunately, I couldn't make it successful because it lacked many accessibility features, both in navigating threads and forums and in writing posts.

I didn't have enough time to customize and fix things I considered basic necessities, so I eventually switched to another platform that offered better accessibility support.

Recently, I've made many adjustments to improve accessibility significantly. However, I can't tell my members that I plan to repeat my previous experiment. 😊😊

It's worth noting that XenForo 1 had excellent accessibility support compared to its successor.
Sadly, XenForo is the best for accessibility I have found (I have managed a private community for my blind stepdad for about 15 years now), and still requires a lot of work. If I were to have been charging based off of old rates I charged when I ran Xenique, purely on the style end it would be around $6000 or more, and that does not include custom add-ons and integrations or scripts for JAWS.

It's why that community still runs on 1.x, because the amount of work to upgrade and re-do everything for 2.x or 3.x would be a huge undertaking.

I've also looked at IPB, Burning Board, Discourse and Flarum for the community and it is arguably more difficult to reach the same level of accessibility with the ease of maintaining it (browser updates can often break some things we have had to do to make it more accessible).

If I do end up updating to 2.3 or 3.0, I can send you a copy of most of the work I have done, I just likely will not provide any support due to time commitments.
 
Sadly, XenForo is the best for accessibility I have found (I have managed a private community for my blind stepdad for about 15 years now), and still requires a lot of work. If I were to have been charging based off of old rates I charged when I ran Xenique, purely on the style end it would be around $6000 or more, and that does not include custom add-ons and integrations or scripts for JAWS.

It's why that community still runs on 1.x, because the amount of work to upgrade and re-do everything for 2.x or 3.x would be a huge undertaking.

I've also looked at IPB, Burning Board, Discourse and Flarum for the community and it is arguably more difficult to reach the same level of accessibility with the ease of maintaining it (browser updates can often break some things we have had to do to make it more accessible).

If I do end up updating to 2.3 or 3.0, I can send you a copy of most of the work I have done, I just likely will not provide any support due to time commitments.
Thank you for sharing your experience.

Regardless of the custom add-ons, JAWS scripts, or NVDA add-ons, the majority of the adjustments XenForo needs are style-related. These include navigating threads, accessing search, reading posts, and more. Most of these adjustments can be made without compromising the visual interface.

So the question is: instead of us, as users of accessibility tools, having to develop add-ons, monitor and update the styles, or modify every theme we purchase, why doesn’t the XenForo team include these features?

  • Are they unaware of these needs?
  • Do they lack the time to implement them?
  • Or is accessibility not a significant priority for them?

As for other forum and CMS systems, most require significant modifications to be accessible for users of screen readers and other assistive tools.

From my experience, WordPress and Drupal are the only ones that take accessibility seriously, which is why they’re often the top recommendations for creating accessible forums.

Interestingly, some large communities are forced to use very old systems, like AudioGames forums. They still rely on an outdated and vulnerable script like PunBB, which is full of issues. Although I don’t actively participate in that forum, I’ve witnessed several cases of spam and malicious posts due to simple scripts anyone could write.

I hope XenForo can take steps to prioritize accessibility and lead by example in the forum software space.
 
I’m slightly confused what has given people the impression that we don’t take accessibility seriously. At least two voices in this thread saying they’ve needed to do a lot to make XF more accessible, and yet, I don’t think we have that many outstanding bug reports about accessibility, if any. Please highlight them if I’m wrong.

Ultimately we can only make changes if we are aware of the issues. Do that and get an answer before going out and making your own changes.
 
I also believe that XF2 took steps forward for accessibility rather than steps backwards compared to XF1. I believe we may have had feedback shortly after release or during beta for 2.0.0 which we acted upon. But I don’t see why bug reports or feedback to the contrary wouldn’t be as forthcoming as any other feedback or bug report. Highly confused by some of the comments surrounding this to be honest.

If there’s something specific that we’ve missed that we are aware about I am happy to review those things if you can point me in that direction.
 
Thank you for sharing your experience.

Regardless of the custom add-ons, JAWS scripts, or NVDA add-ons, the majority of the adjustments XenForo needs are style-related. These include navigating threads, accessing search, reading posts, and more. Most of these adjustments can be made without compromising the visual interface.

So the question is: instead of us, as users of accessibility tools, having to develop add-ons, monitor and update the styles, or modify every theme we purchase, why doesn’t the XenForo team include these features?

  • Are they unaware of these needs?
  • Do they lack the time to implement them?
  • Or is accessibility not a significant priority for them?

As for other forum and CMS systems, most require significant modifications to be accessible for users of screen readers and other assistive tools.

From my experience, WordPress and Drupal are the only ones that take accessibility seriously, which is why they’re often the top recommendations for creating accessible forums.

Interestingly, some large communities are forced to use very old systems, like AudioGames forums. They still rely on an outdated and vulnerable script like PunBB, which is full of issues. Although I don’t actively participate in that forum, I’ve witnessed several cases of spam and malicious posts due to simple scripts anyone could write.

I hope XenForo can take steps to prioritize accessibility and lead by example in the forum software space.
I think you're mistaking the amount of work and customization I have done into the community I manage to mean XF does not take accessibility seriously, which they do. The amount of work I have put into that community is more than I would expect any development team to put in, and is because I have built that community from the ground up with over a decade of feedback, suggestions and requests from members.

That site is almost a fork of XenForo, with the amount of customization that has gone into it which is why it is still on XF1.x because not every change or adjustment was documented (mostly those in the beginning before I moved everything to template modifications and its own custom style framework based off of my old framework).

There is a difference of building with accessibility in mind, and then purpose building something solely for people who are blind, low vision, and have various forms of mobility issues (which is what a lot of the add-ons are for). It is a private community and I have basically built it specifically to the various disabilities of the people in that community, which is not something that companies can really do.

Without a focus group or feedback, XenForo can only really go by recommendations by WCAG or other accessibility guidelines, which they already do.
 
I’m slightly confused what has given people the impression that we don’t take accessibility seriously. At least two voices in this thread saying they’ve needed to do a lot to make XF more accessible, and yet, I don’t think we have that many outstanding bug reports about accessibility, if any. Please highlight them if I’m wrong.

Ultimately we can only make changes if we are aware of the issues. Do that and get an answer before going out and making your own changes.

Most of the changes I did or made are either not applicable to 2.x or are so specific to certain disabled people that they would be counterproductive to everyone else. Most of the community is completely blind, and not low vision, so much of the functionality was gutted to streamline specifically for navigation (I believe I brought up improvements to navigation within the first few years of XF existing). I also replaced every font size to REM prior to XenForo completely moving over to it (back when I had the ranty suggestion about it).

Custom scripts are for compatibility with specific browsers and JAWS or for different input fields. Several add-ons that enable several different navigation styles for people with different mobility issues.

As I said, most of what I have done is not something most companies would ever do, and are basically accessibility layers on top of XenForo. Even if I were to release what I have done I can say from experience that communities focusing on accessibility are likely going to have to fine tune things specifically to their community and it is not something that everyone can do, or even has the time or willingness to do.
 
I also believe that XF2 took steps forward for accessibility rather than steps backwards compared to XF1. I believe we may have had feedback shortly after release or during beta for 2.0.0 which we acted upon. But I don’t see why bug reports or feedback to the contrary wouldn’t be as forthcoming as any other feedback or bug report. Highly confused by some of the comments surrounding this to be honest.

If there’s something specific that we’ve missed that we are aware about I am happy to review those things if you can point me in that direction.
Thank you, Chris D, for your openness to reviewing accessibility-related feedback and issues.

Beyond custom modifications, there are a few key areas where implementing changes could greatly enhance accessibility. I can point out these areas and explain the adjustments I’ve made to better suit the needs of screen reader users and accessibility-focused communities.

I just need to know the best place to propose these improvements and provide detailed feedback. Should I post them as suggestions on your community forum or report them as issues in a specific section?

Thank you again for your willingness to address these concerns.
 
I think you're mistaking the amount of work and customization I have done into the community I manage to mean XF does not take accessibility seriously, which they do. The amount of work I have put into that community is more than I would expect any development team to put in, and is because I have built that community from the ground up with over a decade of feedback, suggestions and requests from members.

That site is almost a fork of XenForo, with the amount of customization that has gone into it which is why it is still on XF1.x because not every change or adjustment was documented (mostly those in the beginning before I moved everything to template modifications and its own custom style framework based off of my old framework).

There is a difference of building with accessibility in mind, and then purpose building something solely for people who are blind, low vision, and have various forms of mobility issues (which is what a lot of the add-ons are for). It is a private community and I have basically built it specifically to the various disabilities of the people in that community, which is not something that companies can really do.

Without a focus group or feedback, XenForo can only really go by recommendations by WCAG or other accessibility guidelines, which they already do.
I completely understand the amount of work you’ve put into creating a fully accessible community for blind users—it’s truly commendable.

What I’m aiming for, however, is for blind users to be able to use the same XenForo as everyone else, without facing accessibility barriers.

There are simple adjustments to styles that XenForo developers could implement to significantly improve accessibility for screen reader users. While this wouldn’t ensure full accessibility for all disabilities, it would eliminate the need for custom add-ons to address basic features that should ideally be built into XenForo from the start.

By addressing these small yet impactful improvements, XenForo could become far more inclusive for everyone.
 
... At least two voices in this thread saying they’ve needed to do a lot to make XF more accessible, and yet, I don’t think we have that many outstanding bug reports about accessibility, if any. Please highlight them if I’m wrong. ...

Not a bug report, but a suggestion/request FWIW:

 
I also believe that XF2 took steps forward for accessibility rather than steps backwards compared to XF1.
I agree, especially with on of my pet peeves, ie user editable alt attributes was a good addition, but IMO could do with improvement in implementation (e.g. force or prompt users to edit them as appropriate)

I don’t think we have that many outstanding bug reports about accessibility, if any.

But I don’t see why bug reports or feedback
Maybe they aren't considered as bugs so much as features that aren't (yet) there? I just added some feedback re: how it could be easier for admins to find and replace alt tags:

 
Back
Top Bottom