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

Doc Bug #11576 Problems with http:// in [img]
Submitted: 2007-07-10 09:32 UTC
From: digitalmagnets Assigned: doconnor
Status: Closed Package: HTML_BBCodeParser (version 1.2.2)
PHP Version: 4.4.5 OS:
Roadmaps: (Not assigned)    
Subscription  


 [2007-07-10 09:32 UTC] digitalmagnets (Digital Magnets)
Description: ------------ This might be due to something in my setup. But since upgrading to 1.2.2 from 1.1, images in the format: [img]http://pear.php.net/image.jpg[/img] Are outputting as: [img="<a href='http://pear.php.net/image.jpg'>http://pear.php.net/image.jpg</a>"] Because the <a href is being included, the images don't work. Can anyone else verify this behaviour?

Comments

 [2007-07-27 00:45 UTC] ying (Ying Wong)
Yes I can confirm this problem. I haven't come up with any solutions to it yet short of not using this PEAR class altogether. I don't suppose you have a fix yet, again short of not using or downgrading.
 [2007-07-27 01:08 UTC] ying (Ying Wong)
Ha. I discovered a quick fix. I noticed it parsed the enclosed image href as a link first, the image filter wouldn't parse it since it's incorrectly formatted. Since it seems to be filtering and parsing for links first, I figure it doesn't hurt to try to reorder the filter line in the BBCodeParser.ini So a quick fix is, place the Images in front of Links in the filters line: Example: ; possible values: a comma seperated list of filters ; comma seperated list of filters to use filters = Basic,Extended,Images,Links,Lists,Email Original: ; possible values: a comma seperated list of filters ; comma seperated list of filters to use filters = Basic,Extended,Links,Images,Lists,Email By doing so, it doesn't break the links but I'm not sure what happens if they're nested within. Perhaps somebody can persuade vBulletin into open-sourcing their BBCode Parser? hehe.
 [2007-09-29 22:10 UTC] tinu87 (Martin Zoller)
The same has been described in Bug #11399, but that one was closed because changing the filter order solves the problem. I still think something needs to be done about this: The URL preparser should leave URLs unchanged if they are the content or an attribute of a tag. Two simple criteria could be checked: * Don't parse URLs in unclosed square brackets [ * Don't parse URLs after an opening tag, e.g. look for !\[([a-zA-Z]+)(.*)\]!
 [2012-01-02 08:05 UTC] doconnor (Daniel O'Connor)
-Status: Open +Status: Closed -Type: Bug +Type: Documentation Problem -Assigned To: +Assigned To: doconnor
Fixed example