create new tag
, view all tags
At present when you rename a topic some history is lost, which doesn't fit well the overall TWiki behaviour of not losing history (e.g. external links into the page break, you go back to find a page that used to be there and can't find it). However, rename has proved very popular. Is it possible to have your cake and eat it?

Well perhaps. I've played with a small addition to the current code base. When a topic is moved the topic.txt goes, but a new file topic.txt is put in it's place. This contain a _pointer to the new topic. Thus if you try to view the old topic you are offered the option of going to the new topic. However, these special topics can be left out of searching and indexes. A bit more coding and this redirection can be included in the history file if the old topic name is subsequently re-used.

There are still issues to think about, such as references to attachments.

What do people think of this?

-- JohnTalintyre - 18 May 2003


I usually do this manually anyway, unless I'm renaming a page within a few hours of creation. Automating this would be wonderful! With respect to including the redirection in the history file, I haven't thought about it much — it would be nice, but my first concern is trying to avoid dead links — if I rename a page I want somebody to find a pointer to the new page name.

-- RandyKramer - 18 May 2003

Anyone else got some thoughts on this?

-- JohnTalintyre - 28 May 2003

You mean other than "yes please!" ? Not much. smile

-- MattWilkie - 29 May 2003

Does the approach described above sound appropriate?

-- JohnTalintyre - 02 Jun 2003

Re: "Does the approach described above sound appropriate?"

In general, yes, but I'll think out loud point by point:

"When a topic is moved the topic.txt goes, but a new file topic.txt is put in it's place. This contain a _pointer to the new topic. Thus if you try to view the old topic you are offered the option of going to the new topic."

Sounds good. My typical pointer (on the old page) is "Moved to <new_topic_name>." Occasionally I use "Merged with <new_topic_name>." (or incorporated in), but then I've clearly done something manually anyway, so the pointer "Moved to <new_topic_name>." seems appropriate. The point being, I don't know if there is a need for the pointer to be user or administrator configurable, although it probably wouldn't hurt.

"However, these special topics can be left out of searching and indexes."

That sounds sweet, and I hadn't noticed that the first time I read through — I assume that would be by a robots directive?

"A bit more coding and this redirection can be included in the history file if the old topic name is subsequently re-used."

The more I think about that, the more I recognize that an organization that requires a complete audit trail might require something like that, and it would be nice. I assume it would be a notation in the old history file that says something like, "(Old) content moved to <new_page_name> on <date_of_move>." Oh, or would it require no work — the history of the old page will now contain the note "Moved to <new_topic_name>."

Oops, I've been missing the point. I guess what you are talking about is taking all the old revisions (of the original page) and either preserving them in the history of the old page, or moving them to include in the history of the new page. Ok, yes, that would be nice for those organizations that require a full audit trail.

Do I care whether the history is maintained on the old page or moved to the new page? Not sure, have to think about it. I guess one key would be to have a pointer in whichever page did not include all the old revisions (history) so that you could find the information. My first thought is the history would be nicer kept with the new page, but I'm not sure why.

If this is done, I wonder if a mechanism could be (easily) developed to let a person semi-automatically do something similar with the history when a page is merged with another page. I guess a key could be to not actually rename the page to accomplish the merge, but preserve the old page, then cut and paste the content from the old page to the new (merged) page (which is probably what I do anyway — I'll have to "watch myself" next time I do that). Then, on the merged page, either in the content or in some (new) metadata, put a note about "...content merged from <old_page_name> on <date>."

"There are still issues to think about, such as references to attachments."

Hmm, not sure what you're thinking of. My first thought is in a page move (rename), the attachments should go with the page, so references (links) to the attachments within the page content need to be changed to point to the new location.

In a page merge (which I know is not the topic of this page, and might always be primarily a manual cut and paste operation) I'd think you'd still want to move the attachments. Do we have a mechanism to do so, or would I (for example) have to download them so I have a local copy, delete them from the original page, then upload them to the new page? If so, it would be nice to have something less cumbersome.

-- RandyKramer - 02 Jun 2003

The approach proposed at the top of this topic would help with CoolURIsDontChange.

-- JohnTalintyre - 08 Jun 2003

Just closing my <s and {s.

-- RandyKramer - 08 Jun 2003

Hello Folks,

Excellent idea!!!

I would love to see a behavoir like this:
Rename does:

  1. moves the topic and attachments to the new location.
  2. creates a copy of the history in the new location
  3. creates a new entry in the history ( new location) mentioning the move
  4. creates a new entry in the history ( old location) mentioning the move keeping the old history
  5. creates a new topic with the old name containing the text and META-Data "Moved to <new_topic> on <date> by <wikiuser>"
    The META-Data entry makes it easy for the search and index topics to find out, that this is just a pointer and may be displayed optional!
  6. makes all (external and internal) links follow the move (as it is now)

There is two situations to be thought of, which are:

  1. What if I want to reverse this . Is this mechanism recursion proof ?
  2. What if I really want to throw this away (move to Trash.)? So when I move this to Trash. , I need to be able to select not to create this "follow me" pointer.

So one answer and two new questions.

Hope it helps!


-- MartinRaabe - 09 Jun 2003

All sounds good.

On the subject of "History" given that John called the Diffs "History" and that "diff" only means something to my old UNIX friends, may I suggest that we RenameDiffsToHistory?

-- MartinCleaver - 09 Jun 2003

I was thinking of history as a more general description. I see diffs more as a way of viewing historic changes, the fact that RCS happens to store history using diffs isn't the only way to do it.

-- JohnTalintyre - 10 Jun 2003

Sorry, I'm not sure you caught what I meant. I was referring to the "Edit | Attach | Ref-By | Printable | Diffs | r1.11 | > | r1.10 | > | r1.9 | More } " bar sitting on the view template. While we are there, does anyone agree that this EditBarShouldBeAPreference?

-- MartinCleaver - 11 Jun 2003

I agree. I have tpoic action as preference in "empty" subskin of SimpleSkin - and thinking about it, I should put it as preference also in SimpleSkin. Thank you for the suggestion!

-- PeterMasiar - 11 Jun 2003

I agree that "History" vs. "Diffs" will be more clear in the "Edit ..." bar.

-- RandyKramer - 12 Jun 2003

I've added this to list at CairoRelease. Code change is pretty small, I'll commit to CVS soon.

-- JohnTalintyre - 07 Sep 2003

Bumping Feature topic marked as Scheduled for CairoRelease that hasn't been modified recently.

-- SamHasler - 20 Apr 2004

John tells me that he has not commited anything for this - bumped to Dakar

-- SvenDowideit - 24 Jun 2004

How about a TopicRenamedHandler, a TopicRequestedNotFoundHandler and a plugin that records and redirects anything that is not found?

-- MartinCleaver - 02 Oct 2004

Currently WebTopicViewTemplate and WebTopicNonWikiTemplate display a " Similar topics in this web (if any):". If the topic has been renamed it will be listed here if it is in the same web (unless it is renamed twice).

One thing we could do straight away would be to add the following search to those two topics.

%SEARCH{ "META.TOPICMOVED.*from\=.*%WEB%.%TOPIC%.*" web="all" nosearch="on" nototal="on" regex="on" format="   * $percntRED%This topic has moved to [[$web.$topic]]$percntENDCOLOR%" }%

-- SamHasler - 03 Oct 2004

Good idea... later they can but put them in the said plugin. M.

-- MartinCleaver - 03 Oct 2004

I've added it. Had to remove the web="all" parameter but page views are still slow:

Would %METASEARCH{...}% be any faster? I'd need a format parameter for it though.

Ooo! looks like JohnTalintyre has already made a patch. See MetaSearch.

-- SamHasler - 03 Oct 2004

Edit | Attach | Watch | Print version | History: r31 < r30 < r29 < r28 < r27 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r31 - 2008-09-02 - RandyKramer
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.