Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I like the fact that I can create a link with custom title using <#123>custom title syntax, but I'm curious why it uses < and > rather than [ and ] like all of the other linodef tags do. This causes problems when using rich text editors because they'll try to convert <> to HTML entities. I propose making the syntax something like
[#123]custom title[/#], or if that won't work, maybe [#123 custom title] or [#123 title="custom title"] or something like that. Anything to make it more consistent with the other tags and avoid using greater-than/less-than signs with their HTML escaping problems.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | linodef_tagoption_linktext.patch | 14.49 KB | Roi Danton |
| #2 | linodef_tagoption_linktext.patch | 14.11 KB | Roi Danton |
| #1 | linodef-filter.inc_.patch | 13 KB | Roi Danton |
Comments
Comment #1
Roi Danton commentedThen the WYSIWYG editor has a bad HTML tag recognition since no HTML tag begins with #. ;) But nevertheless you're right - Linodef has to heed such cases so it'd be better if it'll use tag options for this instead of <#232>, e.g. [#232,linktext="custom text"] as you propose.
For this I have to change the regex to support spaces (and all other characters except
") in tag option values enclosed by":\[#([0-9a-zA-Z_]+),((?:[0-9a-zA-Z]*(?:="[^"\]\r\n]*")*,*)*) ([^\]\r\n]+)\]. That way you can also link to terms and views with a custom linktext. Currently this regex doesn't work in all cases so this still needs work.Comment #2
Roi Danton commentedReason for the failure of the patch in #1 was that the regex engine has been stressed too much.
The new version is smarter than all the others before. Furthermore with those modifications the regex search for tag comments needs much less performance than before.
However, things to heed now:
"otherwise the following tag options will be treated as tag comment"in your text, e.g. for [#232,tid,linktext="custom text with "direct speech""] the result would be custom text with "direct,and]inside"", but I'll try to solve thatComment #3
tonycpsu commentedHi Roi,
Thanks so much for implementing this. The one problem I'm seeing with the patch is that the link text retains the quotation marks. i.e, if I have a tag like [#123,linktext="foo"], the resulting output is "foo" with the quotes printed. Shouldn't the quotes be stripped from the output?
Otherwise, this looks great to me.
Comment #4
tonycpsu commentedI'm also seeing what looks like a debug print statement at the top of each page. Probably something you're already aware of, but just in case, I thought I'd mention it.
Comment #5
Roi Danton commentedAh thanks, I've forgot to delete the debug line.
Quotation marks are now removed before tag is processed. Advantage: Old tags (translation=en) still works. Disadvantage: In messages it says translation=en even if translation="en" has been entered.
Now you may use the
,inside""area. It won't be possible to use]or"(by design).Comment #6
Roi Danton commentedComment #7
tonycpsu commentedWorks great. Thanks again!
Comment #8
Roi Danton commentedUpgraded help and committed to Drupal 6 branch.
Comment #9
tonycpsu commentedOne minor glitch I just noticed is that it seems to be putting an extra space after the link. For example, the following:
is being output as:
Not the most important thing in the world, but something I noticed and thought might be worth fixing.
Comment #10
Roi Danton commentedThx for reporting! This space was added to every tag (Browsers just ignore several spaces in HTML therefore I hadn't recognized it). Now the space will only be added if an inline message is shown.
Bugfix committed to D6 branch.