• A recent change ArthurClemens made for TWikibug:Item5335 has resulted in the default signature (the one made available for cut and paste) being reformatted as a square-bracketed link. The reason is so that it still links when NOAUTOLINK is enabled. However many sites don't use this setting.
• For a long time we have mirrored registrations on the Bugs server from TWiki,.org, and as a result the default signtaure has always pointed to the wrong place
• I recently encountered a case where the default signature was not adequate for the application, and had to change the format
• The whole "copy-paste" approach to signing contributions is ugly and clunky to use

All this tends to suggest that the concept of copy-pasting a hard-coded signature format isn't working too well for TWiki. Proposals for fixing this include:

1. Use Mediawiki's ~~~ format to insert signatures
2. Make the signature format configurable in a template/TWiki variable
3. Make the signature format switchable depending on the NOAUTOLINK setting
4. remove the Signatures completely, and use something like ContributorsPlugin, reducing clutter, and providing a History like UI when needed.
5. migrate to use %DISPLAYNAME% (for REVINFO, login Hello, Signature etc.) which is created using a configure option, and can be over-ridden in custom usermappers

-- Contributors: CrawfordCurrie, SvenDowideit, KennethLavrsen, ArthurClemens, HaraldJoerg - 24 Apr 2008

Discussion

The signature format is sort of configurable in a template: I have made the same change in my corporate skin of my own installation some months ago (but not in SVN). There's a block named sig for that. From the experience in my installation I'd say an attempt to make the signature format switchable depending on the NOAUTOLINK setting is no good idea. Our topics start without NOAUTOLINK. In most cases NOAUTOLINK is added later in the discussion, by someone (e.g. myself) who finds it easier to add it than to escape all unwanted links from copy/pasted texts. But whatever syntax is chosen to enter the signature when editing: If the author doesn't enter his name explicitly, then TWiki needs to do it during save, which means an extra processing step over the text (some plugins have such a step).

-- HaraldJoerg - 24 Apr 2008

Hm, doesn't ~~~ conflict with the notation used by GluePlugin. And do we even need signatures all over as the info who did what is in the history and even can be extracted by e.g. ContributorsPlugin? Otherwise I support that there must be something less geeky and that it has to work with NOAUTOLINK turned on. (BTW: There are other functions/topics that don't work properly with NOAUTOLINK on, but that's another bug).

-- FranzJosefGigler - 24 Apr 2008

"sort of configurable" is not configurable for most people, who would (rightly) be terrified to edit a template. Yes, it could be done in a plugin. Yes, ~~~ conflicts with GluePlugin. Yes, plugins can be installed as alternatives. We are talking about simplified configuration of out-of-the-box TWiki here.

-- CrawfordCurrie - 02 May 2008

This sort of thing has been bugging all my users with non-default usermappers too. The assumption that there are always user topics is wrong - some of the TWiki's I have been involved with specifically want non-linked references to users. Others have external url's that those user names should be linked to.

I guess that the rendering of wikinames, and specifically linked WIKINAMEs needs to be re-done with configuration options and a code interface that allows the usermapper to over-ride it.

eg - the Hello PeterPiper link, the signature, and other things should migrate to use %DISPLAYNAME% or something - which in configure defaults to something like

[[%USERWEB%.%WIKINAME%][%WIKINAME%]] for simple twiki's, 
[[TWiki:%USERWEB%.%WIKINAME%][%WIKINAME%]] on our Bugs system, 
[[%META{url}%][%WIKINAME%]] or 
[[http://some.corporate/user/info/system/%LOGINNAME%][%WIKINAME%]] or even 
<noautolink>%WIKINAME%</noautolink>

-- SvenDowideit - 04 May 2008

If DISPLAYNAME is set, would this expand to let's say [[TWiki:%USERWEB%.%WIKINAME%][%WIKINAME%]] in the signature?

-- ArthurClemens - 05 May 2008

it would have to yes - using same mechanism as the variable expansion in topic creation i'm guessing.

-- SvenDowideit - 05 May 2008

In the signature the DISPLAYNAME would have to be the the expanded static value. ie. back to the current simple approach.

The DISPLAYNAME idea is good.

Some more brainstorming (more storm than brain). Can we avoid yet another config parameter and let the value of DISPLAYNAME depend on NOAUTOLINK? (not the in-topic noautolink tags - only the Twikivar NOAUTOLINK value).

A cool thing would be if DISPLAYNAME only expands to the link value if the topic exists in the Main web. We already today have some checking for this existance since we show the ?-mark create topic link when it does not exist. Making a IF for exist topic would cost too much performance. Problem is that the time we render for Wikinames happens after we would expand the value of WIKINAME. So we may still have a performance hit. Such feature is not worth the performance hit.

The purpose would be to avoid Main.c12179 type values for DISPLAYNAME. Using the square bracket values has the problem that it creates a link that you would otherwise not get.

Example

• Without brackets: Main.c12179
• With brackets: c12179

The problem occurs when you have a TWiki with both registered and unregistered users. The registered users are shown with their Wikiname. The unregistered are shown with their login ID. The Main.login format is not pretty at all but at least we avoid the ?-mark link that people cannot keep their hands off causing and endless creation of topics in Main with no good content. The ideal is to show the login ID without Main. prefix when the person is not registered and the Wikiname prefixed by Main. when the person is registered.

And then the NOAUTOLINK dimension comes and adds the desire force links to Main topics which complicates things.

A DISPLAYNAME solution should wise but I would prefer that is handles the login ID problem AND I would like a good default so you do not need to define it in configure and can add it to TWikiPreferences if you are a super duper admin type with unique ideas.

-- KennethLavrsen - 05 May 2008

No, we can't avoid the cfg setting - there are more than just with and without square brackets as options, depending on the TWiki setup.

I listed 4 different use cases that I've had to hack TWiki to do for different situations - and there are many other variations, some of which require code support in a usermapper, others, like yours requiring some fancy IF work

-- SvenDowideit - 06 May 2008