Forums

My parser.php file is a complete re-write from scratch and has very little resemblance to the original. You'll want to study each file separately on their own (a diff between them will look like pure gobblety-gook!). Also, pay close attention to the new bbcd_source.php and bbcd_readme.txt files. These contain the key to understanding how the BBCode-to-HTML translations are done from an administration point of view.

Be aware that understanding how the parser works under the hood requires a pretty deep knowledge of regular expressions. The parser applies a rather complex recursive regex in a recursive manner, and processes nested tags from the outside-in. Note also that this technique goes completely against what most computer scientists would recommend, i.e. "Don't use regex to parse BBCode". They may be right, but I absolutely love working with regex and thoroughly enjoyed putting this thing together. Its works pretty darn good too.

Sheez, now you guys have gone and pointed my old OCD brain back into this thing... D'oh!

Sorry, but no. Its been a while since I've used GIT and you guys have messed with the branching since I last did a COMMIT so it would take me quite a while just to figure out how to do it without harming anything.

The ALT attribute always needs to be there to be displayed when the graphic is not available. In previous versions of Flux/Pun, the URL of the image was placed in the ALT attribute. However, this is not very descriptive, so the latest version of Flux allows an attribute to be specified with the IMG BBcode tag, which is then placed in the ALT attribute of the HTML IMG tag.

When specified, my new parser also adds this to the TITLE attribute, so that this "message" is displayed as a tooltip when the user hovers the mouse over an image. This enables the creator of the post to add additional expressive metadata (i.e. deliver richer content) to the reader of the message.

I don't think that duplicating this data in both attributes makes it any less accessible. Why do you think so?

Ok those (quite serious) bugs are fixed. All error messages are now passed through htmlspecialchars() before post.ph and edit.php see them so that that sort of exploit is now closed off.

Thanks again. (I really appreciate a fresh set of (highly qualified) eyes taking a cold, hard look at this code.)

And lack of variety is nice too, for people who are minimalists. This is one of the nice features of the new parser design; you can easily disable (or completely remove) any BBCodes you don't want.

p.s. I am back working on this. But, unfortunately, there are some higher priority jobs that i need to complete first. In the meantime, I would really like it if people could play around with it, try to break it, and give some more critical feedback: positive or negative.

No, this parser is an all-or-nothing proposition. I'd turn it into a mod if there were enough interest.

My new parser does this.

Ajax can be good thing, but only if properly implemented (which is almost never done correctly). For one thing, the site should be designed to work correctly if Javascript is turned OFF. Like correctly implemented CSS, (where a website should work correctly even if the style sheets are turned off), a web site should also work perfectly if Javascript is turned off. Correct implementation of Ajax provides progressive enhancement and degrades gracefully. A term was coined by Jeremy Keith to describe this correct implementation: he calls it: "HIJAX".

I highly recommend Bulletprof Ajax by Jeremy Keith.

I'm all for adding Ajax to Flux, but only if it is done right (i.e. Hijax).

My new parser does this. There is an option in the admin parser panel to turn this option on and off (defaults to ON).

To keep it simple, I implemented only the minimum tags required to make a valid table (TABLE, TR and TD).

However, this little TABLE exercise did allow a light bulb to go off over my head. I never liked the way any of the parsers handle LIST tags as a special case. To easily allow adding any new BBCode, the parser should be as generalized as possible with as little tag-specific code as possible. When adding the TABLE tags, I realized that there is a better way. All these HTML elements (UL, OL, TABLE, TR, THEAD, TBODY, etc) share a common attribute - all of them can only contain specific elements and must not contain any other text content. I also realized that it will be a relatively simple matter to add another property to the $bbcd to specify if the tag is allowed to contain text (in addition to the allowed_tags which is already implemented). This will allow replacing the LIST-specific code with generic code that will work for all these tags. This will allow easily adding such tags (THEAD, TBODY etc.) without having to hack inside the parser code.

So here's a big thanks out to popeur for turning on the lights!

p.s. You guys really need to check out the new parser! Sign up with the test/documentation forum and try to break it.

See: New 2011 FluxBB Parser

You'll need to wait until I release the new parser as a Mod. Or you can download the code and modify it yourself.

You can read about how to create a new BBCode for the new parser here