Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.2.4

Bug #1979 Whitespaces in attribute are braking it
Submitted: 2004-07-26 01:05 UTC
From: stiwi at lukasonline dot com Assigned: sjr
Status: Closed Package: HTML_BBCodeParser
PHP Version: Irrelevant OS: Linux
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 29 + 40 = ?

 
 [2004-07-26 01:05 UTC] stiwi at lukasonline dot com
Description: ------------ If an attribute of a tag has whitespaces in it, the attribute will be cut off at the first whitespace. Reproduce code: --------------- [font=Comic Sans MS]PEAR rules[/font] Expected result: ---------------- <span style="font-family:Comic Sans MS">PEAR rules</span> Actual result: -------------- <span style="font-family:Comic">PEAR rules</span>

Comments

 [2005-01-27 09:47 UTC] roger at wingetsolutions dot com
Take a look at HTML_Commons::_parseAttributes This method properly handles single quoted or double quoted values or non-quoted single word values. Since HTML_COmmons::_parseAttributes is marked "private", it would be best to copy it or merge it with HTML_BBCodeParser::_buildTag .
 [2005-10-20 21:58 UTC] seth at pricepages dot org
I've fixed this bug and a number of others. Please take a look if you can, because I'd expect there to be new bugs in a rewrite of this size. (I'd call it version 2.0-beta) Link: http://pricepages.org/bbcode/BBCodeParser.zip * Unit tests! * More currently open bugs that have been fixed: 5609 4844 3447 1979 373 2580 3775 * I rewrote the _buildTagArray() function. It had been using half of the execution time in my tests. A TODO: in the comments said "rewrite this function". It is now almost 2x faster than the original function in my informal tests. * I rewrote _validateTagArray() in an effort to make it more useful and faster. Mission accomplished. It would be easier to read, too, but there is quite a bit more going on there. But commenting lines probably equal code lines. * Output should _always_ be XHTML 1.1 compatible. * Per discussion on the Developer list, you can now pass a flag that determines the action on an error or warning during parsing. Actions include: correcting the problem, aborting parsing, ignoring the invalid tag, and deleting the invalid tag. Examples: If you only accept valid input, set both warn and error to 'abort' and parsing will be aborted as soon as a problem is found. If you accept invalid feedback, but want to give the user feedback which tags caused problems, then set both error and warn to 'ignore' and the bad tags will be displayed. If you want to make the output as pretty as possible, then you want to auto correct when you can and delete when you can't. Set the options to delete on error, and correct on warn. (There are twelve combinations to fit various situations.) * I've attempted to maximize BC, but here are the only ways in which BC is broken (to my knowledge): Custom list numbering is now ignored for XHTML 1.1 reasons. I reverted back to single quotes by default. HTML is now automatically escaped to fix a few "bugs" (I believe that Text_Wiki also automatically escapes HTML). Old filters are incompatible with the new filters (the 'allowed' tag variable has been replaced with a more powerful set of variables and they use a different format). ~Seth
 [2006-07-06 18:33 UTC] rather at not dot com (Jafo)
Find: preg_match_all("![\s$oe]([a-z]+)=([^\s$ce]+)(?=[\s$ce])!i", $str, $attributeArray, PREG_SET_ORDER); Change to: preg_match_all("![\s$oe]([a-z]+)=([^$ce]+)(?=[\s$ce])!i", $str, $attributeArray, PREG_SET_ORDER); Seems to have fixed it for me.