• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

I am getting a number of comments from users about the syntax of links. For example, we could tell users to use the following [[.. ..]]:

  • Writing an external link: [[http://www.google.co.uk Google UK]] Yes / Done
  • One would assume an internal link would be: [[Main.WebHome Home Page]] No
  • And assume [[mailto:feedback@twiki.org Send us feedback!]] Yes / Done

On the other hand, we could tell users to use this syntax [[..][..]]:

  • Writing an external link: [[http://www.google.co.uk][Google UK]] Yes / Done
  • One would assume an internal link would be: [[Main.WebHome][Home Page]] Yes / Done
  • And assume [[mailto:feedback@twiki.org][Send us feedback!]] No

This is very confusing for normal users. In fact, it was a user who suggested I post this as a bug! Trying to explain this to others can also be difficult, as there is no consistancy.

The best fix I can see would be to allow mailto links to use the [[..][..]] syntax. Obviously the other option would be for internal links to use [[.. ..]], which would be easier to type (TWiki:Codev.EasierExternalLinking, TWiki:Codev.EasierLinking), but probably harder for new users.

I think this is a fairly big problem, especially for new users, and was suprised I couldn't find some one else reporting this problem either here or in Codev. I never really used Cairo but I have been told that it was possible to use the [[..][..]] then, so I really think it should be put back.

-- TWiki:Main.AndrewJones86 - 28 Sept 2006

I believe the syntax [[http://www.google.co.uk Google UK]] has been deprecated. Is this still documented?

But, yes it would be nice to be able to write [[mailto:feedback@twiki.org][Send us feedback!]]. It would also be nice to pass parameters in the [[][]] syntax, like [[WebHome?q=abs][Home]].


Huh? But you can - Send Us Feedback!

The [[http://link nasty syntax]] is still supported, but I think not documented.

Discarded pending clarification of the problem.


Ok taking a look at the problem again, if we use [[mailto:feedback@twiki.org][Send us feedback]], it does work. If we use [[mailto:feedback@twiki.org][Send Us Feedback]] (inital capitals) we get random <nop> tags showing before the words with inital capitals, which is why everyone is saying it does not work and are using the nasty syntax, which does. Having said that, its fine on twiki.org, so it must be something that happened in our upgrade. Will spend some more time searching twiki.org and see if I can find something or ask in support as its really annoying people... Cheers for responding and apologies for the confusion I caused!


I can confirm the bug. In 4.0.4-4 the [[mailto:feedback@twiki.org][Send Us Feedback]] is rendered as Send <nop>Mail <nop>Now - the email link however is correct.

So this has been resolved since 4.0.4-4. If someone can identify what fixed it I can add it to 4.0.5 - while we wait for 4.1 to be released.


The only change I'm aware of in this area is the fix to stop it scanning down the web tree when hierarchical webs are enabled. Does the problem still exist if you disable hierarchical webs?

Otherwise, I just don't know; I don't recall any other change that might have had this impact.


I tried to disable hierarchical webs in 4.0.4-4 and that did not cure the problem. If you can give me a few hint about in which source files the rendering of the mailto link it happening I can try and do a binary search on the SVN checkins that relates to these files and fine the exact SVN revision that cured the problem. That will take some time but does not require expert perl skills to do - ie. a job for me.

It could be interesting to learn what it is so we do not introduce the bug again. So if you can add the 1 or 2 .pm files that does the rendering then I will try and do that in the weekend. Do not spend time on it yourself Crawford - since it is already resolved in 4.1


The way to ensure the bug is not reintroduced is to add it to the test set. To demonstrate how to do this, I added a formatting unit testcase that takes in a one of the existing unloved tests from the TestCases web (which no one seems interested in running any more frown ).


You closed the bug. Where is the fix for the Patch04x00 branch? A testcase is a very good thing and thank you for that, but it does not fix the reporters problem and 4.1 is not just about to be released.

I have been doing a binary search. And I know now that it was Crawford that fixed the bug. But I have not yet found the exact code line.

The fix came in when the new configure was merged in. The link bug was present in SVN 11435 and it was fixed in 11438.

I also know that if I take revision 11438 and put the lib/TWiki.pm, lib/TWiki.cfg and lib/TWiki/Config.pm from 11435 in it (thus not using TWiki.spec) - the bug comes back. I will keep on searching so I can merge in a small fix on Patch04x00. But because the change is so major - it is not easy to nail down.

The most likely place the bug was fixed was in the transfer of config settings from TWiki.cfg to TWiki.spec. I have not yet found what it is. I suspect the change of quotes used.


I tried to take the 11438 version of TWiki.pm and only replacing these two lines.

Round line 143

    #use TWiki::Configure::Load;    # read configuration files
    use TWiki::Config;    # read configuration files

Round line 266

#    TWiki::Configure::Load::readConfig();

so this shows that there are no other changes in TWiki.pm that influence the bug again indicating as I said above that the difference in most likely between old TWiki.cfg and TWiki.spec. Next must be to look at the way the files are loaded. (lib/TWiki/Config.pm vs new lib/Configure/Load.pm)

I keep on digging. I also want to learn why this happens to ensure no other features are influenced by the change in a negative way.


By brute force type debugging I have found that the that is placed in front of the capital word comes from lib/TWiki/Render.pm line approx 680

          $text =~ s/(?<=[\s\(])($TWiki::regex{wikiWordRegex}|[$TWiki::regex{upperAlpha}])/<nop>$1/go;

Now trying to find out why.


Added some debugging code round the above code line. Both in 11435 and 11438 the line inserts the . But 11438 removes it again. Now chasing where it gets removed. I also checked that the regexes are the same and they are.


I hope it is OK that I think loud in this bug report. I report each finding I make case someone comes by and think "I know what it is!".

OK. In Render.pm round line 1133 I added a debug print.

    $text =~ s/\[\[([^\]\n]+)\](\[([^\]\n]+)\])?\]/$this->_handleSquareBracketedLink($theWeb,$theTopic,$3,$1)/ge;
    print STDERR "$text\n";

The test topic I use has a mailto link with my email address and the link text "Hello Muck". (Yeah it used to be an F).

When I run this on 11435 the text I get says

<a href="mailto&#58;kenneth&#64;lavrsen&#46;dk">Hello&#32;&#60;nop&#62;Muck</a>

in 11438 i says

<a href="mailto:kenneth@lavrsen.dk">Hello <nop>Muck</a>

So naturally the next step was to look at the actual HTML sources.

in 11435 I get

<a href="mailto&#58;kenneth&#64;lavrsen&#46;dk">Hello&#32;&#60;nop&#62;Muck</a>

and in 11438 I get

<a href="mailto:kenneth@lavrsen.dk">Hello Muck</a>

So IN REALITY. In 11435 the email antispam encoding works and causes a bug to be triggered. And in 11438 the antispam encoding is not working and does not trigger the bug.

So it is as I feared. This bug is not fixed! It is masked by a new bug!!


Yes we have a new bug. Even normal mailto links are not encoded after 11438.

The place where the email address is supposed to be encoded is in Render.pm in the function _externalLink.

There is a line..

    if( $TWiki::cfg{AntiSpam}{HideUserDetails} ) {

and for some reason $TWiki::cfg{AntiSpam}{HideUserDetails} has no value.

I have checked that in TWiki.spec we have

$TWiki::cfg{AntiSpam}{HideUserDetails} = $TRUE;

and it is NOT defined in LocalSite.cfg.


Merged fix to Patch04x00 branch. Waiting for release.

This bug item contain fixes both for 4.0.5 (if ever released) and 4.1!


The fix is not correct yet. It allows plain text that contains an email address to leak through into the topic (though the href is handled correctly). It needs more work, so switching it back to Actioning.


Finished the fix.


Merging fixed fix into Patch04x00 (for release 4.0.5)


Summary Inconsistent mailto link syntax confuse users
ReportedBy TWiki:Main.AndrewJones86
Codebase 4.0.4, ~twiki4
SVN Range

AppliesTo Engine

Priority Normal
CurrentState Closed

Checkins 11619 11625 11626 11641 11644 11653
TargetRelease minor
Edit | Attach | Watch | Print version | History: r23 < r22 < r21 < r20 < r19 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r23 - 2006-11-14 - KennethLavrsen
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback