Tags:
create new tag
, view all tags

Proposal to allow topics to be renamed

Background

It has to be possible to rename topics in a bookmark- and search-engine-friendly way. 404s are not acceptable, period. But not allowing -- in the sense of policy, not access controls -- people to rename, move, or delete topics is a bad idea. So a user-friendly solution needs to be found.

This does not address the permalink issue, which is, however, closely related.

Requirements

Administrator can set default behaviour for renamed topics, resulting in the following:

  1. Search engine results continue to work.
  2. Links in other websites continue to work.
  3. "Spoor" left pointing to the new topics.

Notes Search engine results are irrelevant to intranets. Search-engine technology may make it pretty much a non-issue for public sites as well.

Links in other websites remains a problem. This, however, probably should be solved via some form of PermaLink.

Spoor should be optional, and not in topic text.

Proposal

When a topic is renamed, create a new topic with the old name that includes a meta tag with the relevant information. The core can then use the meta information to generate a message like This topic has been moved to NewTopicName, where NewTopicName is a link.

A checkbox in the rename/move form allows the user to leave spoor or not. Whether it's checked by default or not is a configuration option, one of:

  • always checked
  • never checked
  • checked if topic is n hours/days old

Use cases

Context Original state Reason for change New state Spoor
Ongoing development of a TWiki application Misnamed or misplaced topic Topic belongs elsewhere and/or under a different name Topic has the right name and is in the right place. None wanted. (This is a problem right now!)
Software project one topic named InstallationGuide New release makes much of the content outdated Three topics: InstallationGuideV3, InstallationGuideV4, InstallationGuides with pointers to specific topics. None needed.
  Two topics: Foo and Bars The two topics belong together. Foo is renamed FooAndBars. Bars is deleted. Unclear what's desirable.

Contributors: MeredithLesly, CrawfordCurrie, ArthurClemens

Discussion

I still believe this is a SCM vs. CMS kind of discussion. If you like SCM you don't rename topics, if you like CMS you are less respectful of it.

If you like CMS you probably don't want your users sniffing around in how your site once looked, if you like SCM you will want them to be able to trace every minor detail of what was changed (and if possible, why).

The proposal suggested here was already implemented in Cairo (as long as a move is done inside a web, see http://twiki.org/cgi-bin/view/Codev/ShouldSmiliesBeDoneViaPlugin for an example).

-- SteffenPoulsen - 22 May 2006

There is access control for those sites that don't want topics renamed. For everyone else, there is a problem to be solved.

Please do see ShouldSmiliesBeDoneViaPlugin for yourself to see the problem.

-- MeredithLesly - 22 May 2006

smile To me the point is pretty well demonstrated as well. As the page was renamed, some history was lost. As it was created again, even more history was lost. If there's energy for making this usecase a bit more beautiful I don't think anybody is going to object.

-- SteffenPoulsen - 22 May 2006

Personally I think that 99% of all renamed topics fall within two categories. Many of you will say I am wrong and that is probably right. But I we can agree that the percentage is high.

  • 50% are renamed within the first hours of their life because the author regretted a bad name or had spelled the words wrong.
  • 49% are moved from web to web (typically a new web) as a part of a site re-org. Typically initiated because there were too many topics in a web that uses search a lot and the speed was dropping too much. Or because the organisation that the TWiki serves changed.

The last 1% are real renames where two topics get merged into a third, a topic changes scope and the name fits badly etc.

I doubt many will ever want to have strange Apache redirects to forward misspelled topics and topics that changed name in the first few hours or days of their life.

I doubt many will want to accept strange redirect rules or redirect topics in a web that you cut down because of performance problems.

So what problem is it we try to solve? How large is this problem in reality? How many 404s do people actually get when linking to TWikis?

I bet most of them are because the TWiki changed domain name or is simply not there anymore.

I am afraid that a hasty implemented feature could be a "lam with 5 legs" type of invention which will slow down TWiki and not really do anything more.

IF a feature was going to be made - then a good implementation could be a general redirect of all 404s to a special search page that offers the user to search the entire TWiki for topics that have the original topic name in their "topic moved" meta data.

If someone renames a topic and then creates a new topic with the same old name I am sure that this user intends to let the other users see the new topic and not the old.

Example. An installation guide for Cairo called InstallationGuide to be renamed to InstallationGuideCairo and a new InstallationGuide topic could be made which is the guide for Dakar.

It is interesting to see the history of the Cairo version in the old doc. Not the new doc. We should not implement silly features that prevent users from doing what is right.

-- KennethLavrsen - 23 May 2006

My take on the requirements, based on a real life example:

Content of the 2 topics Innovation and Trends are merged with new topic InnovationAndTrends.

  • Innovation is renamed to InnovationAndTrends. The default 'renamed' text is displayed.
  • Trends is deleted. When a user tries to visit this topic, s/he will get to see the "This topic does not exist yet" page.

I a better world, we would like to set up a redirect. Either:

  • The topic Trends should not be deleted, but will get a redirect function
  • The topic Trends is deleted, and the system creates a custom "Not found page" with a custom redirect to InnovationAndTrends
  • The topic Trends is deleted, and the system creates a custom "Not found page" with the links as currently displayed on "This topic does not exist yet"
  • The topic Trends is deleted, and the system automatically generates a redirect to the most relevant page

Now for requirement 2:

  • Because Trends is deleted, I can create a new page Trends. Should we point visitors to the old (moved to Trash) version of Trends?

-- ArthurClemens - 23 May 2006

I've modified the main body of the topic to reflect some of the comments above.

-- MeredithLesly - 23 May 2006

Steffen, I have to disagree with the statement, "if you like SCM, you don't rename topics." If you like SCM, you'll leave a trace so that people know what happened to the renamed topic.

-- RafaelAlvarez - 23 May 2006

At the end, leaving behind a topic with a redirect is an form of "cyber-squatting". If I create a topic named InstallationGuideOnDebian but it should have been InstallationGuideOnDebianWithApache, then no one will ever be allowed to create InstallationGuideOnDebian.

I would like to bring a RealWorld(tm) experience from the trenches of programming:

Before the term "Refactoring" was introduced and tools appeared to automate the process, renaming a method/sub/function was a difficult manual operation better to be avoided. This leaded to two phenomena:

  • Sometimes people spent days just defining the name of the method.
  • Sometimes the method name was not descriptive enough.
  • Methods, once created, were never allowed to change.

Or, in other words, a long time spent discussing, often resulting in content that goes stale or is wrongly identified.

Also, before the SCM tools started to support renaming, people said "we can't rename the file because we lose history". But even that problem was solved, and tools like subversion allow to rename/move while preserving the history.

Think about it. We're having troubles trying to solve a problem that has been solved before in another (similar?) domain.

-- RafaelAlvarez - 23 May 2006

And I have to disagree with the statement that a trace is all it takes. When renaming some of the more serious things that happen is that external links to topics diffs are increasingly difficult to find, external links to attachments, both head and earlier versions, are just gone and typically leaves 404s, external links to plugin handlers will no longer work, external link to backlinks lists will display wrong, it's quite easy to speculate a very long list of side effects - it's just not SCM style (as I know it).

But of course it's still a very possible situation that I just don't get very clearly yet what this is all about smile

-- SteffenPoulsen - 23 May 2006

I think we are looking at this the wrong way. A topic name is just a label, and a label can be used to mark one thing, or a set of things.

Think of a single revision of a topic as an "atom" (a fundamental particle that can't be subdivided). An atom can be uniquely identified using an appropriate string (TWiki uses Web/X?rev=). "Web.X" refers to the latest in the set of revisions of topic X, so it's an ambiguous label for that set of revisions. Similarly "Web" is an ambiguous label for an even larger set of topics and their revisions. However there is nothing but narrow-minded thinking dictating that "Web.X" refers to the head of a set of revisions. It could equally refer to a set of topics.

In use case terms; let's say a web page links to .../bin/view/Web/InstallationGuide. When InstallationGuide was first created it was an unambigous label for the latest revision in a set of revisions that share that name. But now we need to break it up, into CairoInstallationGuide and DakarInstallationGuide. So we create those two topics; and we replace the InstallationGuide topic with a "topic set" (I just invented that).

When a user clicks on a link to .../bin/view/Web/InstallationGuide, they are told of the ambiguity and asked to make a choice. e.g.

InstallationGuide is ambiguous; pick a topic from the following set:
  • DakarInstallationGuide: The following installation instructions are for TWiki-4 and later....
  • CairoInstallationGuide: These instructions will guide you through installing TWiki-3....

-- CrawfordCurrie - 23 May 2006

Crawford: excellent use case and description. Use case now included above.

Steffen: I need much more explanation of what you're worried about to be able to respond.

-- MeredithLesly - 23 May 2006

SteffenPoulsen, the way subversion works is by making a link from the "new" name to the last revision of the "old" name that is relevant.

So, if we have !InstallationGuide up to revision 10, then rename it to !DakarInstalationGuide and create again !InstallationGuide, then there should be a link between !DakarInstalationGuide and !InstallationGuide?rev=1.10, and the latest revision of !InstallationGuide should be 11.

-- RafaelAlvarez - 23 May 2006

Crawford's idea is really food for thought.

-- RafaelAlvarez - 23 May 2006

has any of you ever gotten a 404 error from TWiki (since about Bejing)? I havn't. Personally I hate that TWiki puts a URL into my browser cache, even though it does not exist.

-- SvenDowideit - 25 May 2006

Come to think of it, I think that one can't get a 404, vintage not-a-clue. After all, all page serves go through a script, as opposed to being directly asking for a page. So any change in the mechanism merely needs to make sure this remains the case.

Of course, my proposal is not about avoiding 404s, but how to make sure that renaming/moving/merging works better. Perhaps there isn't a need for any change at all, other than the attitude that "renaming is BAD". (Well, there's one change that I'd definitely like to see, as I have to spend way too much time removing the "This topic has moved from" lines.)

-- MeredithLesly - 25 May 2006

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2006-05-25 - MeredithLesly
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.