When using title.module, it becomes very difficult to submit PHP/C/Java code snippets. The title module reformats array subscripts (that use square brackets), stripping the angle brackets and making a (usually non-existent) page title out of the contents.

This patch disables the effect of title.module inside code or pre tags.

CommentFileSizeAuthor
#14 title-2005-01-05-link-v01.patch1.79 KBinducer@news.tiker.net
#9 title.module_1.diff2.24 KBPhilippe
disable-title-filter-in-code-or-pre.patch1.7 KBEric Scouten
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

This is likely not limited to title.module. Perhaps this code belongs in a function in common.inc. The image.module (and its cousins) use similar syntax.

Eric Scouten’s picture

Eric Scouten CreditAttribution: Eric Scouten commented

Actually, it's not so much of an issue with image.module (at least). title.module takes anything inside square brackets and attempts to make a title out of it (and, along the way, it removes the square brackets -- which can really mess up your understanding of the underlying code).

The syntax of image.module --and most other filter modules-- is [image: ... ], which is much less likely to appear in code snippets.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

i see ... yes, this patch does make sense IMO.

Dries’s picture

Dries CreditAttribution: Dries commented

The fix looks slow and clumsy. I'd like to research alternatives first.

JonBob’s picture

JonBob CreditAttribution: JonBob commented

This seems to be fixed in CVS due to the new pre-filtering possibilities. The title module has been removed from core anyway.

Anonymous’s picture

(not verified) CreditAttribution: commented
Philippe’s picture

Philippe CreditAttribution: Philippe commented

This issue is not fixed in CVS. Title filter still interacts badly with the code formatter. Title.module doesn't use any pre-formatting.

BTW, how come Anonymous can close our issues? I think that's not a good thing for the quality and reliability of the issue tracker.

ax’s picture

ax CreditAttribution: ax commented

it's not exactly an anonymous user who closes issues. what you see are cron-initated automatic closures of issues 2 weeks after issues are marked "fixed".

i find this "closed by Anonymous" very confusing as well and filed a feature request to make this process more transparent. feel free to give it a shot :)

Philippe’s picture

Philippe CreditAttribution: Philippe commented
Assigned: Eric Scouten » Philippe
FileSize
title.module_1.diff2.24 KB

I suggest we allow the delimiters to be set by the site administrator. He can then choose between [foobar] or [title:foobar] or <title>foobar</title> or whatever he likes. By allowing the admin to choose, WE are not responsible for breaking any existing pages. The ADMIN will be responsible, and we'll tell him about the risks in the configuration pages. The site admin can also choose the delimiters so that they interfere as little as possible with other filters (applied before or after the title filter).

Here's a first draft of how to do it. Missing issue is that we'll have to escape certain characters form the delimiters before using them in a regular expression. I'm not sure yet how to do that, but I'll figure it out.

Any ideas, comments...?

Stefan Nagtegaal’s picture

Stefan Nagtegaal CreditAttribution: Stefan Nagtegaal commented

Can't duplicate this anymore.. This is probably solved by the new filter.module where we can arrange the order of filtering/
Marking as 'fixed'

Dries’s picture

Dries CreditAttribution: Dries commented
Project: Drupal core » Title
Component: title.module » Code

Moving this to the 'title project'.

I don't think the problem has been fixed though.

ax’s picture

ax CreditAttribution: ax commented
Project: Title » Drupal core
Component: Code » title.module

how can this be fixed when the title filter hasn't changed? you haven't setup a proper input format. try one with only the title filter, and you will get the same bad behaviour as before.

you haven't actually changed the bug-status to 'fixed', so i don't have to change it back :)

ax’s picture

ax CreditAttribution: ax commented
Project: Drupal core » Title
Component: title.module » Code

this is a good example of a race condition :) i started editing this issue, dries changed it in the meantime, and when i submitted it, dries' status changes got lost. guess we need to have a closer look at jeremies locking efforts.

changing the stati back as per dries (why 4.5.0 and not cvs?). hope he doesn't do anything to it in the meantime :)

inducer@news.tiker.net’s picture

inducer@news.tiker.net CreditAttribution: inducer@news.tiker.net commented
FileSize
title-2005-01-05-link-v01.patch1.79 KB

The attached simplistic patch changes the title module to simply process links only if they are written [link:destination|title], instead of for any pair of square brackets. This breaks existing title.module content, so it's probably not the way to go.

Bèr Kessels’s picture

Bèr Kessels CreditAttribution: Bèr Kessels commented

this patch uses the (unofficial) convention in drupal to use [{modulename}:{var}|{var}]

please consider applying this patch. only *after* it is committed, or will get committed, i will make a small update.php to chenge existing link tokens to use the title: prefix

and please do not use the previous [link: since [link: is reserved by weblinks bundle (it is currenlty used in weblinks module)

Bèr Kessels’s picture

Bèr Kessels CreditAttribution: Bèr Kessels commented

this will also fix http://drupal.org/node/4824

ax’s picture

ax CreditAttribution: ax commented
Status: Active » Closed (won't fix)

anyone still using this module? marking WON'T FIX - feel free to change.