#19028 closed defect (bug) (fixed)
make_clickable fails when <a ...> contains \r characters
Reported by: | josepsanzcamp | Owned by: | nacin |
---|---|---|---|
Milestone: | 3.9 | Priority: | normal |
Severity: | minor | Version: | 3.2.1 |
Component: | Formatting | Keywords: | has-patch |
Focuses: | Cc: |
Description
Hi.
I'm using the make_clickable php function in my project SaltOS to add the links feature to the email client and feeds reader.
I detect that when try to make clickable the urls that has the link tag and this tag contains \r characters it fails.
I fixed the problem removing all \r of the <a ...> tag but understand that can be a possible bug.
Thanks in advance.
Attachments (2)
Change History (12)
#2
@
13 years ago
Hi.
I added an example of the problem. Is detected that the problem is the absence of the space between the "<a" and the "href=...": "<a\nhref=...".
Josep.
#3
@
13 years ago
- Keywords has-patch needs-testing added
Added an attachment which simply looks for whitespace between <a and the next attribute rather than specifically a space. Works in the case outlined above, but unsure if it has any other issues?
#4
@
13 years ago
I apply the patch in the line 1386 of the formatting.php (wp v3.2.1) and runs fine. It produce the expected result. For me, the issue is fixed correctly.
Another issue related to the same use: I'm using the make_clickable in my app without wordpress. To do this, I copied the files needed (formatting.php, plugin.php and kses.php) because I want to use the original files provided by the wp project directly by maintenance reasons. I detect too that if I define a function that do the requires_once of the needed files inside the function, too I must to do globals the follow variables: $allowedposttags, $allowedtags, $allowedentitynames. You can think of a solution that don't uses global variables to allow a more easily of code recycling.
Thanks for your great job.
Josep.
#6
@
13 years ago
- Keywords needs-unit-tests added
- Resolution fixed deleted
- Status changed from closed to reopened
Tickets are only closed fixed if a change is actually made to WordPress. The patch above was only a proposal.
Could you post an example of the input, the expected output, and the current output of the function? It'll make it easier to reproduce the exact case you're referring to