A new version of XBBCode is out. This one is a bugfix that will finally get the module to work out of the box, so if you've tried it before and couldn't get it to work, give it another chance please.
- The module has been refactored completely; system names now reflect that its submodules are actually part of xbbcode (through names prefixed by "xbbcode_").
It's actually been some time since I began using my own SVN repository for the XBBCode module (described in more detail in earlier posts). It's far more convenient than the combination of Dreamweaver and vim I have been using before.
Also, I have made it publically available, so if you have an SVN client (which you undoubtedly do if you have Linux), you can now get the current version by checking out the repository at this URL:
I wrote of my first scenario two days ago, and of my success in combining the Pear syntax highlighter with my XBBcode module to integrate it in Drupal today.
So this shouldn't come as a surprise, really.
AvernumScript is one hell of a scripting language, and not really in the positive sense: Arbitrary spellings and abbreviations of functions are awful to remember, and the tight limitations (only integer and string types, only while and if-else flow control) aren't good to design for.
With the help of the PEAR Text_Highlighter package, I just extended XBBCode with an interface that used this library. The module is called Highlighter. It scans a directory for generated class files (Text_Highlighter generates PHP classes for specific code types from XML descriptions), includes them, and then provides XBBCode tags for each. I can now use PHP:
BBCode has one drawback: Usually, it doesn't allow for tables.
If it does, you're stuck with endless
which is exactly what BBCode is meant to avoid: It should separate the user from the HTML syntax both for safety and convenience.
If it's not supported at all (usually the case), you have to make do with ASCII-formatted structures like this:
My module is quickly taking shape. Version 0.1.2 fixes several inconsistencies in the infrastructure.
One of the most significant changes is the addition of the "handler" system as an additional layer between the filter and the API hook.
Before, tags were simply gathered from all modules that implemented the hook, and collisions resulted in the latter module overwriting the tag of the earlier one.
Here's the first version of my XBBCode module.
Please note three things:
1. I have never developed a software product ready for deployment.
2. This is not yet intended for production.
3. My blog loads very slowly these days. Guess why.
I have left the "no cache" flag on in the filter to make debugging easier; meanwhile, the filter is kind of inefficient.
Honestly, this is less interesting to you as a tool than as a proof of concept work that will be interesting to look at and improve. However, it is functional.
My exams are done, and I finally have some time to get back to my XBBCode project.
As the last post stated, I am trying to build an extensible BBCode engine that can parse any tag added to it through a web form or through another module. In this way, the engine is supposed to emulate that of Invision Power Board, which also allows custom tags.
I've spent the last few hours developing the first version of a new Drupal module I've wanted for a long time.
It's dubbed XBBCode - short for Extensible BBCode.
The basic functionality of the BBCode module fo Drupal is kind of unsatisfying. Not only does it not allow any customization of how tags are rendered or what tags are recognized at all - it also does no validation on the tags at all. Unclosed BBCode tags will be rendered as broken HTML code as of the last version - which is exactly one thing BBCode is meant to fix.