• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

XF 1.5 Enable WYSIWYG / Toolbar (within BB Code Tags)

We are using Vaultwiki with Xenforo,

When editing pages we are given a full WYSIWYG editor but when editing section we are only given a plain test editor.

For usability we really need some sort of editor with a toolbar etc, users just don't like editing using bbcodes etc...

Editing Page

Editing Section

We have contacted the addon author @pegasus for help however it appears that it is not his control to make changes to this:

"Because a section might occur in the middle of active BB-Codes, it is not possible to use WYSIWYG mode for the editor when editing a section.

In vBulletin this is fine, because there is really no difference between WYSIWYG and non-WYSIWYG modes. But in XenForo, when WYSIWYG is disabled, there is no editor toolbar at all.

That is the default behavior of XenForo. If you don't like it, you can ask the XenForo developers to for an improvement request: to still show the editor toolbar when in BB-Code editing mode (so that there are buttons for the BB-Codes)."

Is there anyway we can enable some sort of WYSIWYG within bbcodes.

Unfortunately most users nowadays want a WYSIWYG on wikis and really does make a huge difference,

Thank you for your help


XenForo developer
Staff member
There isn't a way out of the box to get what you want. There might be an add-on.

I'm not sure I understand the author's explanation of the issue and why they can't use the RTE there, but I don't know their system details.
@pegasus are you able to add more to this? It would really improve the Vaultwiki's usability if we could find a solution.

It tried TinyMCE Quattro and its WYSIWYG bbcodes , but that seems to replace the standard editor / buttons. I will try this plugin but it appears just to add BB code tags and will be WYSIWYG.

Thanks for your help


Well-known member
I'm not sure I understand the author's explanation of the issue and why they can't use the RTE there, but I don't know their system details.
In the particular issue we were discussing, let's say for example there is a post that is 25,000 characters long. The end-user only wants to edit the middle 1,000 characters. In our add-on there is a mechanism that will show the user only that 1,000 characters in the editor, and it merges it back when the user saves. In our add-on, we call this "section editing".

However, because the character boundary can be arbitrary, it is possible that the user placed BB-Codes where the opening tag is before the section boundary and the closing tag is within the boundary (or vice verse). If we were to parse the 1,000 characters in this state (such as what the RTE does), then we risk the parser "fixing" these tags or adding other markup around them which will make them invalid when they are merged back. (Yes, this happened in the past, and it gets ugly).

Our workaround for this issue since it happened so often was just to disable RTE-mode while using this "section editor." Therefore, no parsing would take place against the incomplete post. However, in XenForo the toolbar buttons disappear when RTE is turned off.

This doesn't happen on my vBulletin forum - if I'm not in WYSIWYG mode, the toolbar buttons are still there, and they still work. The difference is that the button adds a raw BB-Code tag rather than the HTML-ized version of it. It would be nice if XenForo had the same capability.

The change is simple:
- A user has text highlighted
- A user clicks the toolbar button
- The editor places the opening BB-Code tag at the beginning of the selection and the closing tag at the end of the selection

There are other considerations, such as the option value, but overall it seems like this should be simple to implement, unless the editor does not currently receive the BB-Code tag names. It's just a question of modifying the relevant callbacks for each button to reflect the change.

There are other cases when it becomes necessary to disable RTE. For example, some add-ons might give admins an editor where HTML and BB-Code is allowed in the same place. In this situation, if RTE is turned on, it tends to "hijack" manually entered HTML when the content is saved, trying to convert it to BB-Code even if that is not what the end-user wanted. However, if RTE is turned off, then we run into the same problem where the end-user doesn't have buttons for BB-Code or smilies. You might say that it's not needed if HTML is allowed, but sometimes it's nice to have a shorthand, rather than having to remember the URL for a smilie.
Last edited: