I think you got the wrong idea. I was asking about the system I'm developing ATM. I'm talking about which rules it must follow.
I know how the current system works. I spent the equivalent of 1/2 a day dedicated studying how it does everything.
Personally, I don't like the
format. I'm developing in a way that we may not need any of that stuff.
I'm trying to make a real tree out of the BBCodes just like the browser makes a tree out of the HTML.
So far so good, I think I got a good solution for the 1st pass.
It gives me just about everything I need to have the complete thing formatted as a tree.
Then, after I have it all in a tree-like structure, I just need to parse inwards to outwards.
That's the step I think it should stop.
Personally, I'd store a serialization of the complete post BBCode tree in the DB. What do you all think?
BBCode reading permissions.
An extension may want to implement the idea that some users are able to view some BBCodes and other users are unable. Think like some forums that only allow members to view the url's posted.
[url][b][url] would produce invalid HTML. It won't break the page though, and off the top of my head I can't think of a combination that would.
In that specific code, in my implementation, that would produce the output:
If you made a mistake in your post and meant:
Then, if the tag is never closed, the output would be:
And so to fix the
[url][b][url] issue, we would simply blacklist [url] from being a descendant of itself. In fact, no tag needs to be a descendant of itself, unless I'm forgetting a plausible scenario in which it is needed.
Each tag will have the direct descendent's blacklist and the full descendent's blacklist. Alternatively, it may have a whitelist. (Blacklist and whitelist are incompatible, you have to choose one of the 2, for each tag).