[ Closed ] kses compatibility question

cheers.. i missed the bit where it called the kses_hook ;)

i have another question...

let me explain how i m using this lib firstly:

i have a bbcode parser and unparser. To achieve the unparsing i used to embed comments.. eg... [ u]text[ /u] would become during parsing -> <span class="underline">text<--u--></span> .. then i would pass this through kses and then save hte parsed text, then during editing, i would unparse it back to [ u]text[ /u] .. as u can probably see. the comments are there so the unparser can know what this span tag corresponds to..

this worked well for kses as it did no re-ordering of the elements (which is the reason i want to update to this lib instead)..

now i ve worked out a solution to solve this and allow re-ordering to take place. That is to simply do a 2 stage parsing.. stage one would do: text => <spanu>text</spanu> .. then in the lib i would have defined spanu to be a valid inline element.. once the hl was done with it, i would then convert <spanu>text</spanu> -> <span class="underline">text<!--u--><span> .. this offcourse will only be done for tags that are completely defined through the parser and accept no extra attributes ( for security reasons)

the question is: is there a smarter way to do this that can save the 2 part conversion (maybe some changes to hl? - i admit i did attempt that, but not with much success... i reached the point where it did it correctly for some cases, but on others (for malformed input offcourse) it re-ordered it in such a way that eg input-> [ b]sadf[ u]asdf[ /b][ /u] and it would change it to -> [ b]asdf[ u]asdf<!--u-->[ /b]</span>? the reason it didnt get parsed back to [ /u] is because it exects <!--u--></span> which obviously wasnt there)

and my 2nd questions is:
there are a ton of deprecated elements and/or elements that i will simply never use as my bbcode parser will never produce them (center, form, input, applet, button, fieldset etc etc).. is it safe to assume to remove those in order to speed up the libs processing time (smaller arrays, less things to look for - at least for kses the number of elements/attributes i provided really affected the processing time)

the way i call it now is the kses way (where i explicitly define the elements and attributes allowed for those elements - the array is dynamically generated on the parsing so if there is eg no [b] tag i wont include 'strong' => array() at all in the array of allowed_html elements (in kses that made a big difference in processing time - i havent tested it on this lib since my code already did that)

thanks again.

your assumptions are correct in the reasons we need to keep bbcodes. mainly for ease of use and backwards compatibility for the thousands of posts we have.

the reason pre-parsing is done and stored in the db as the parsed text is simply for performance reasons. There are far more views than inserts. there is little point in parsing from bbcode on every request.. for 100 posts per page, taht is 100 parses of possibly fairly large texts, and that is just for 1 member. With 3k online at any given time, you can see why it is benefical to keep it parsed in the db and just output it as it is, with no further checks; even if the parsing stage has to take a big longer when inputting data in.. it simply overall gives a better efficiency.
--------
if i where to store it in bbcode, the first stage u mentioned isnt even necessary... an htmlentities call would secure the input completely (as the bbcodes arent parsed yet, and the bbcodes themselves use [] instead of <>. then on output i would have to parse it to html, and then check the html produced using this lib or kses. I think it is much better to pre-parse it and have a bit more processing time during parsing/unparsing (unparsing is very fast actually with the <!--x--> system i m using since there are no security checks as that is done during parsing, and its just a simple str_replace call as mentioned below).. generally i believe in the idea that u secure while u insert and then just display as is...

a simpler example would be if you had to store a 'name'. it would be much more efficient to htmlentties the name be4 u insert in the db, and then just display it as is, instead of securing it each time u display it
---------
for the strong and em yea... but what about more complex div and span created tags that use classes to define the style..

eg:
[box]text[/box] => <div class="box">text</div>
[bbox]text[/bbox] => <div class="bbox">text</div>

with a simple str_replace there is no way in distinquishing the 2 </div> ., u wouldnt know which one is box and which one bbox.. offcourse my unparsing is simple str_replaces... which is y i put the comments in there... so <div class="box">text<!--box--></div> can easily be translated str_replace(array('<div class="box">','<!--box--></div>'), array('[box]','[/box]')); etc

you could argue that i could just use [/box] for all </div> closes, and get done with this issue alltogether. but that wont look nice for the end user :P

+ the fact that the box/bbox example wasnt a good one..

what if u have floaters.. [left] and [right].. both use div's to accomplish it.. u can float anything u want in them, images, quote boxes, text, urls etc... having [left]asdf[/box] wouldnt make much sense ;)

or a [ code] box... or [center] to center whatever u put inside it.. a similar problem arizes with span tags; size, color, underlined, dropcaps, strike throughs etc... the bbcode i m offering is quite rich. html as input would be very hard for the members, would they need to memorize class names and learn html in order to make a nice looking post?

offcourse you could use JS to create a nice editor that automates all of this. but then what about members that have js disabled?

the custom elements way is the way i had thought of as welll in exactly this manner ;)

thanks for the detailed explanations :D ..

Thanks j8 for the suggestion.

I too have been thinking of implementing a better correction algorithm. Having a stack array can also provide a way to check for admin-specified nesting (e.g., not allowing 'hr' inside 'td') and for better standard compliance (e.g., allowing 'tfoot' only before 'tbody', preventing empty 'table', etc.), though the speed will take some hit.

In your specific case, though, a preview system, that allows users to see what the post would look like, can reduce the need for such a better correction algorithm.