Since #493074: Back-link to the commit as a comment on the related issue. went live, I've noticed some weird inconsistencies with how the project issue link filter (e.g. #304808: Usability: Add project issue URL filter
) works. For example:
https://drupal.org/node/1365536#comment-8808067
Sometimes the [#x]
part is being ignored (as it should, since all this is wrapped in <pre>
) and sometimes it's being expanded.
Upon closer inspection, the difference is if there's a newline inside the <pre>
or <code>
tag. If there's no newline, we properly ignore this case. If there's a newline, we don't recognize it as escaped text and the filter fires. Behold:
No newline:
[#304808]
With newline:
[#304808] Stuff on a newline
The regexp in question is this:
$regex = '(?:(?<!\w)\[#\d+(?:-[\d\.]+)?(@)?\](?!\w))|<pre>.*?<\/pre>|<code>.*?<\/code>|<a(?:[^>"\']|"[^"]*"|\'[^\']*\')*>.*?<\/a>';
The interesting parts are the | clauses for <pre>
, <code>
and <a>
. We're just doing .*?
in there, which by default does *not* match newlines. So, I think we just want the 's' modifier on the regexp (PCRE_DOTALL) so that '.' consumes anything, including a newline.
Comment | File | Size | Author |
---|---|---|---|
#1 | 2281673-1.project-issue-link-filter-pre-with-newlines.patch | 637 bytes | dww |
Comments
Comment #1
dwwLike so.
Sadly, we have no automated tests for this filter. :/ But local testing seems to work fine. Visual inspection of the regexp reveals that . is only used in the pre, code and a cases, where multi-line matching is what we want.
Any objections?
Thanks,
-Derek
Comment #2
dwwFixed link to the issue that revealed this bug. It's really #493074: Back-link to the commit as a comment on the related issue. not #304808: Usability: Add project issue URL filter.
Comment #4
drummTested and looks good to me.
Comment #5
drummNow deployed. I didn't clear the text formatting cache, so the old filtering will be visible for awhile on older comments.