How to deal with LinkRot
Never changing URLs is not the only solution, nor is
LinkRot the horrible thing that is sometimes made out. What one never wants is to have a user get a 404 (page not found). Redirects can be done in a number of ways and are particularly easy in a wiki, by leaving spoor behind. And, of course, search engines have gotten a lot smarter, so unless
Google is prevent from re-searching a site, things should work out OK anyway.
One way to avoid 404s is leaving a spoor-containing topic behind when a topic is moved. The spoor should say something like "This topic was deleted" if a topic is deleted, and "This topic moved to Location" if the topic was moved elsewhere. If spoor is done via a meta-tag rather than changing the topic text, skins can render the spoor even if new content is put into an old, previously moved topics.
Given TWiki's ability to search via the Jump box, it's even easier to handle potential 404s. Turn a 404 into the code that backs the jump box search and either the moved topic or alternative links will result.
See:
--
Contributors: MeredithLesly
Discussion
When renaming/moving a topic is a good idea, merely citing
CoolURIsDontChange or, as is more often the case,
SearchedURIsCantChange is not solving the problem creatively. As described above, wiki engines are particularly suited to handling topic relocation.
--
MeredithLesly
The
TopicRenamedHandler approach is one idea that warrants investigation.
--
MartinCleaver - 19 May 2006
Some use TWiki for an intranet, some use it for an internet purpose. This discussion find itself between to uses of TWiki as well, being a) CMS and b) SCM.
Instead of a 404 ending up in a search, I'd any day prefer to get the "left over stub", with an explanation of what happened to this topic, including why / how was it refactored or marked out of date. Together with complete history directly at hand (diff). This is a traditional SCM approach.
Leaving the stub doesn't mean the content can't live on elsewhere - imho the stub doesn't "rot"; it tells a history of what were and points to what is now.
--
SteffenPoulsen - 19 May 2006
I absolutely agree. 404s aren't cool for any site, whether it's a personal one or a corporate one. Since TWiki has considerable control over this area, via rename/move and whatnot, implementing a smart way to handle what would have been a 404 seems like both a good idea and a solution for some of the problems we've been trying to come to grips with. There are also ways to have webservers send back permanent redirects to other URLs. Some combination of the two of these shouldn't be too hard to implement. I hope.
So where are our core developers in all this? (Some people seem to think I'm one, and I do some work on the core but I'm hardly in the CDot class.)
--
MeredithLesly - 19 May 2006
A stub by itself is just part of the solution. A mechanism to be able to create new topics with the same name as the stubs without losing the trai is needed as well.
As I said someplace (and I think this is
MichaelDaum idea), the only solution that allows for
CoolURIsDontChange while retaining the wikiness is using permalinks.
--
RafaelAlvarez - 19 May 2006
We
definitely need permalinks. Permalinks are not a substitute for meaningful URLs, but they're an important adjunct.
--
MeredithLesly - 19 May 2006
forget about permalinks. For once I followed the advice of
MartinCleaver and took a look at
TopicRenamedHandler. That topic is totally misnamed, as it really shows a solution for all of this.
--
RafaelAlvarez - 19 May 2006
Well, permalinks don't
have to be cryptic. OTOH, unless you're going to not allow the editing of topics that used to exist and that currently point to another page, permalinks still have their place.
--
MeredithLesly - 19 May 2006
note to self: permalinks in the form of healing_link_rot can be used even if the topic is moved and later re-created with the same name. The "re-created" topic would have a permalink healing_link_rot_2
--
RafaelAlvarez - 19 May 2006