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

Bug #373 URL's with '&' are parsed incorrectly
Submitted: 2003-12-07 22:27 UTC
From: pearbbcodeparser at borfast dot com Assigned: dufuz
Status: Closed Package: HTML_BBCodeParser
PHP Version: Irrelevant OS: Linux (shouldn't really matter)
Roadmaps: (Not assigned)    

 [2003-12-07 22:27 UTC] pearbbcodeparser at borfast dot com
Description: ------------ A BBCode link with a '&' in it will not be correctly transformed into it's HTML equivalent. Reproduce code: --------------- Note that this is not PHP code but "BBCode" used by this package. The following BBCode will not be handled correctly: [url=]linked text[/url] Expected result: ---------------- <a href="">linked text</a> Actual result: -------------- <a>linked text</a>


 [2003-12-07 22:30 UTC] pearbbcodeparser at borfast dot com
Edited the version information (had PHP version before)
 [2003-12-07 22:36 UTC] pearbbcodeparser at borfast dot com
OK, so 'version' is PHP's version after all... sorry, I'm new here ;)
 [2004-01-11 10:25 UTC] sjr at php dot net
I can't seem to reproduce this. Input code: ------------ normal link: [url=]linked text[/url] auto link: Output code: ------------ normal link: <a href=''>linked text</a> auto link: <a href=''></a>
 [2004-01-11 11:57 UTC] pearbbcodeparser at borfast dot com
Could it have something to do with the fact that my system is set to UTF-8? I don't think so but it's the only thing that comes to my mind. Can someone else try to reproduce it and post the results here? Thanks.
 [2004-04-28 05:14 UTC] dufuz
I get everything correct ... though & should be changed to & so please fix that atleast
 [2004-07-11 22:07 UTC] gurugeek
Dear Maintainer, Your package html_bbcodeparser has currently 8 open bugs. We urge you to take the necessary steps to solve the reported issues at your soonest convenience. If the bug issue hasn’t been addressed yet you are kindly asked to take the necessary steps to ensure a prompt resolution of the problem. If you already addressed the reported problem feel free to change the bug status as soon as possible. Regards David Costa PEAR Quality Assurance
 [2005-10-20 21:54 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: * 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
 [2007-06-04 21:41 UTC] dufuz (Helgi Þormar)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.