Discourse BBCode


(Sam Saffron) #1

Repo: GitHub - discourse/discourse-bbcode: vBulletin BBCode plugin



The Discourse BBCode plugin pulls in much of the BBCode syntax into Discourse.

Out-of-the-box: Discourse already supports [i], [b], [s], [u], [quote], [url], [email] and [code], this plugin fills in some more of the gaps to provide a more “BBCode” ™ experience.

It supports two types of constructs.

Multiline constructs, which encompass a block. Multiline constructs must never start or end in the middle of a line.

Like this example

Inline constructs that can be embedded in paragraphs [s]like so[/s].

Inline constructs

  • [size=SIZE] : set the size of text

  • [font=FACE]: set the font face for text

  • [color=COLOR]: set the [color=#381]color[/color] of text [/li]

  • [bgcolor=COLOR]: set background color of text

  • [highlight]: Highlight text

  • [small]: Make text very small

  • [aname=NAME]: create an anchor in your document with a name

  • [jumpto=NAME]: jump to anchor created with aname

Block level constructs


* item
* item


[li]this is a list item[/li]


[*] this is an item
[*] this is **an** item

Text alignment

Center some text

Right align some text

Right align some text


:warning: Careful with this plugin, it can easily be used for abuse by hiding text and making text unreadable, BBCode will make your markup less understandable

Adjusting the size and alignment of text in my post
BBcode or HTML to change font color?
vBulletin v4 importer list conversion breaks markup
Formatting toolbar
Do we need to keep support for bbcode [ol] and [li] tags
Formatting toolbar
(Erlend Sogge Heggen) #2

Any particular reason why this one and the BBCode color plugin are kept separate? Couldn’t the color option just be put behind a default-off checkbox?

(Jeff Atwood) #3

We could, and I agree we should, if we add checkbox options to that plugin. Some of our customers want just BBCode color and we are loathe to expose them to all the other BBCode crazy :crazy_face: which is… substantial.


We’ve just migrated 112,000 posts from phpBB to Discourse and we’ve installed the BBCode plugin to deal with things like [size=180]. However, there’s a significant problem, phpBB interpreted that BBCode as "font-size: 180%", whereas the plugin interprets that as <font size="180"> i.e. phpBB is dealing in relative sizes and the plugin in absolute sizes… :crazy_face:

Personally, I think the plugin makes more sense but given all my existing, legacy posts, I’m wondering if there’s an option for the plugin to use relative sizes?


is this plugin still considered official? It doesn’t display the green checkmark.

(Joshua Rosenfeld) #6

Yep, it’s still official. It should be displaying the check mark: discourse/metadata.rb at master · discourse/discourse · GitHub

Ooh, I see. The plugin name is set to BBCode in the plugin.rb file. I’ll fix this.

Edit: This should now be fixed, please update the BBCode plugin.

(Kimberly Boynton) #7

Can you make a list option that doesn’t automatically create bullet points?

(Mittineague) #8

Did you try list-style-type: none but we’re unable to?


Any good reason to require the line breaks for the multi-line constructs? I am running into trouble with this on a migration, this can be solved, of course, but I started to wonder why?

Regular expressions would have no trouble understanding a [/quote] that is not in a line by itself. In fact, that’s how my old forums (Kunena) were doing things.

Also, even outside of migrations, if a user clicks in Discourse to quote someone, and then slightly edits the produced markup and loses the line breaks, he gets broken markup:


and now the user has to figure out why, and it’s not easy. It is far easier for a computer to figure out a different regexp :wink:

Maybe there is a reason for this limitation, that I’m not seeing. Something about nesting perhaps?

(Sam Saffron) #10

The main reason is that the way our parser is designed it would be a nightmare to support mixed block inline


Ok, thanks.

I don’t know exactly when your “parser” is acting, but if it’s only a display thing, would it be appropriate to do some fixing work before, when saving?

Basically, what we do when fixing our migrated posts, could be done by the core code when it’s saving a post, and by the code driving the preview pane: adding a line break where it’s missing.

Again, I don’t know what I am talking about, so possibly this doesn’t make any sense :slight_smile: