In Drupal 5.1 and still in 5.2, the URL filter in Core turns dates and numbers into hyperlinks; this is generally unwanted, and the URLs are mostly invalid.

Examples:

(a) Dates
* "25.07.2007 " becomes http://25.07.2007/
* "26.07.2007 " becomes http://26.07.2007/

(b) Numbers
* "200.000.000 " becomes http://200.000.000/
* "1.105.414 " becomes http://1.105.414/

However, this behaviour seems to be somewhat erratic and thus hard to predict.

* "25.07.2007." remains "25.07.2007."
* "26.07.2007." remains "26.07.2007."
* "1.051.113 " remains "1.051.113 ", if it is embedded in Wikitext for "bold" (= "'''".

Please note the spaces in the examples; what I figured out so far is:

* If a string, including two dots, is followed by a space, URL filter interpretes it as an (broken) hyperlink
* A dot closing the string prevents this erraneous behaviour
* Embedding the string in some kind of markup seems to prevent this also, even if the string is followed by a space, followed by some text and not beforde closed by the markup.

Since I couldn't find a similar bug report for the core module, this might be an interaction between the core module and a 3rd party input format. Im using Input format "PEAR Wiki Filter" with following filters/weights:

* Footnotes Textile style (-8)
* Code filter (-6)
* PEAR Wiki Filter (0)
* URL-Filter (2)
* Zeilenumbruchkonverter (10)

If it should be possible to fix this by changing the configuration of the filters, I'd be glad for some advice.

Thanks & regards, -asb

Comments

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Project: Drupal core » PEAR Wiki Filter
Version: 5.2 » 5.x-1.x-dev
Component: filter.module » Code
Category: bug » support

Cannot reproduce on clean Drupal core 5.2 install. Must be some interaction among the various filters.

Re-assigning to PEAR Wiki Filter instead. Please try re-arranging the weights of the filters (maybe running URL filter first?) and/or disabling ones you don't need.

asbdpl’s picture

asbdpl commented

> Cannot reproduce on clean Drupal core 5.2 install. Must be some interaction among the various filters.
> Re-assigning to PEAR Wiki Filter instead. Please try re-arranging the weights of the filters (maybe running URL filter first?)
> and/or disabling ones you don't need.

That's the only order I could get the filters to work reasonable at all. E.g. if I move URL filter at the top (weight of -10), URLs are parsed as follows: <a href="http://www.example.com" title="www.example.com">www.example.com</a>. (That's what appears in the node view, not in edit view).

So the broken links will remain.

Thank you anyway for the quick answer!

Regards, -asb

Anonymous’s picture

Anonymous (not verified) commented

Maybe you should turn off the URL-Filter completely. Using Mediawiki syntax all it takes to transform an URL into a hyperlink is adding square brackets. That's not too much additional work I think and it will maybe solve your problem.

asbdpl’s picture

asbdpl commented

> Maybe you should turn off the URL-Filter completely. Using Mediawiki syntax all it takes to transform an URL into a hyperlink
> is adding square brackets. That's not too much additional work I think and it will maybe solve your problem.

We considered this before, since it would have another nice advantage (we thought): We could better control what links become active hyperlinks and mitigate the problem of comment spam a bit; currently, we deliberately have to strip some parts of the URL away to prevent linking (www.example.com -> example.com).

However, there are two drawbacks; firstly, I'm running five Drupal sites with a total of > 50k nodes, and actually there might be *some* active links we might want/need to keep (at a certain size, websites tend to become a bit confusing, so I'm not absolutely sure about this ;-). Secondly, it didn't seem to work at all. When we disabled the URL filter at one site for testing purposes, the mentioned urlifications (e.g. "200.000.000 " -> http://200.000.000/ still happened, so we switched back to the "proven" setup.

If I consider this now, Im not sure if this simply was the result of Drupals internal caching, or some other side effect I didn't thought of. I'll try it again and report back here in a few days. Damn, how does this cache work anyway... admin/settings/performance says "Caching-Mode: Normal - (recommended, no side effects)", well...

Greetings, -asb

Anonymous’s picture

Anonymous (not verified) commented

Once a piece of text has run through all filters the result is cached in cache_filter until it is modified again to improve performance. You would have to truncate the cache_filter table to see changes in your already filtered and unmodified text when changing the input format that they used.

asbdpl’s picture

asbdpl commented

> You would have to truncate the cache_filter table to see changes in your already filtered and unmodified text
> when changing the input format that they used.

I'm talking about *new* nodes which were created *after* disabling the URL filter in admin/settings/filters.

Greetings, -asb