Prevent topics to link to oneself

Techical discussion on how to prevent topics to link to themself. See for discussion on the matter: InhibitTopicSelfLinking

Some time is spent in the Plugins web on inserting / removing the self-links caused by using WikiWords inside the text that refer to the plugin.

Jakob Ns web usability guidelines states that links to the topic itself are confusing and should be avoided.

This topic is a proposal to prevent linking-to-self automatically.

The WikiWord rendering code could be modified not to link a WikiWord if it points to the rendered topic, so there are no "self-referencing" links in a topic but if the content if included from some other topic or refactored out the link is not lost. Also, the topic creator won't need to worry about escaping the WikiWord so it won't link.

Of course, this behavior must be made cofigurable (sites that want to allow self-linking should be free to do so)

TWiki 4.1 has 2 new Css tags that can be used to prevent the user being shown link to oneself - twikiCurrentWebHomeLink and twikiCurrentTopicLink. This means that self linking can be acheived without requiring a modification of the topic itself, and without hardcoding a non-link into a topic that may be INCLUDed in another topic (where that linking may be desired).

-- Contributors: RafaelAlvarez, SvenDowideit

Discussion

-- RafaelAlvarez - 20 May 2006

Discussions on the merits of this idea will be moved to InhibitTopicSelfLinking

I used these css classes to create the orange background for the selected topic in http://www.ergoport.com.au

Admins or skin designers can define the following type of CSS to disable links to the current topic (in the main topic section)

twikiMain .twikiCurrentTopicLink {
  color: #000; /* same color as the surrounding text */
  text-decoration: none; /* to remove the underline */
  cursor: text; /* to make the cursor stay as a text cursor, not the hand */
}

-- SvenDowideit - 07 Oct 2006

Careful when refactoring. In InhibitTopicSelfLinking I had raised an issue with the feature.

In our Motorola ISO9000 TWikiApplication we link to outselves many times.

We link to earlier versions when the earlier version is the last released and the procedure is under revision.

We link to ourselves with compare or rdiff instead of view to show the changes.

We often place a link to the topic itself - and then have this topic included in another topic. And from this parent topic you can then click the links to the included topics when you want to go to them to edit them.

On the Motion Twiki I also use this feature a lot. My long Motion guide is mostly simple parents that include a number of smaller topics. To go to the smaller topic from the including document you hit the link (often the header of the section) to go to the small topic which is required when you want to edit the small topic.

So if someone now implements a feature that prevents topics to link to themselves it will break quite many of the topics both on my Motion and out Motorola TWiki. And if we (many users independently of each other) have done this heavily I am sure this is as commonly done on other TWiki installations.

So it is important that by default TWiki continues to link to itself.

Adding a feature where you can turn it off is fine with me. And it seems this is the case with this actual proposal. I just want to make sure that noone "improves" it so that suddenly the default is not to link to yourself.

-- KennethLavrsen - 08 Oct 2006

I've argued many times against this feature - which is why I was thrilled to realise this way of defering the rendering decision to css. it means people like you and I can continue to use the wiki as a wiki, and others that insist that Neilson's work applies to wiki's can turn the self links off.

good to see that i'm not the only one that wants topic links to self to work

-- SvenDowideit - 09 Oct 2006

So - shall I commit this?

-- Sven

Sven. From the EdinburghReleaseMeeting2006x10x16 this question came up which prevented a vote.

When this feature is implemented and you are using the CSS that does not link...

• If a TopicA contains a wikiword link to itself it will not link to itself.
• If TopicB now INCLUDES TopicA the link to TopicA should now work and point to TopicA when you view TopicB. Is this the case?

It seemed all were OK with the feature if this is the case. There was an open question what the default should be: enabled or disabled.

KennethLavrsen prefers that default is that topics do link to themselves so things work like they work today.

-- KennethLavrsen - 16 Oct 2006

I do not have a strong opinion on this. I think manually preventing links where needed is just fine. It is OK to include the feature to prevent links to oneself, perhaps better to have it disabled by default.

-- PeterThoeny - 16 Oct 2006

I tried to apply the patch above.

The concern we had is not an issue. The TopicB including TopicA with TopicA containing links to itself shows these links when viewing TopicB.

Looking at the links to the topic itself, what actually happens is that the underline is removed. The self-wikiword is still more gray than the text around it in Firefox. The cursor does not turn into a hand but the word still works as a link which you see as a change of background when you move the mouse on top of the word.

In IE I cannot make the CSS work at all. I have tried to clear the cache. I have added the CSS to a file called by USERCOLORSURL.

So maybe a little tweaking of the CSS is in order but the code seems to work fine. And with the CSS only being a doc item and not implemented by default in PatternSkin we can always fine tune more.

Where would the documentation of this feature be added?

-- KennethLavrsen - 17 Oct 2006

FF ignores the color attribute. IE. ignores all 3. CSS expert needed.

-- KennethLavrsen - 17 Oct 2006

Please note that I'm not intending to commit any css, I am just making it possible through the use of css. My usage, and my reason for implementing it, is to highlight links to the current topic.

Yes, the concern raised in the meeting is not an issue, as the processing is when the Renderer creates links.

The main reason I am against preventing links manually in the topic text, is because you are hardcoding a display setting within the topic data. This means that links that would work when including a topic, are disabled, and thats the kind of thing that we've been trying to prevent in TWiki for years.

eg: if TopicA has natrul links to itself in its text that are manually disabled, when that topic is included in another topic, they are still disabled, even though they would then be useful to the user.

Architecture patterns point to seperating data from presentation. Manually disabling links to self mixes the 2 concerns.

Docco intentions: mention it on TWikiCss

-- SvenDowideit - 17 Oct 2006

It seems to me we had the questions answered and we got the answeres that should remove the concerns raised at the EdinburghReleaseMeeting2006x10x16.

Does anyone have any objections that prevents Sven from checking in the perl code that enables this feature in CSS? By not checking in any CSS the default is business as usual.

-- KennethLavrsen - 25 Oct 2006

CSS naming convention for TWiki CSS is a twiki prefix. So the classes should be named twikiCurrentWebHomeLink and twikiCurrentTopicLink.

-- ArthurClemens - 26 Oct 2006

The links can occur in the topic text, in headers or in broadcast messages. Hard to define a new color for the not links. Alternatively we can use the class name to give them a behaviour, see BehaviourContrib. But that would mean this contrib is enabled on every page.

-- ArthurClemens - 26 Oct 2006

ya, true. mind you, if thats what a client wants, this code change will allow it. I'll commit it, and add the docs, and we can figure out how to exploit it later

commited via Bugs:Item3062

-- SvenDowideit - 27 Oct 2006