Add the ability to rename wiki page.

[mrovner@…]

Add Rename page button to bottom of wiki page.

• Edit history and attachments shall be preserved.
• Ask user whether Links to this page shall be updated.

[jr.plusplus@…]

Could also be a feature of the admin tool:

wiki rename WrongPageName RightPageName

[whoareyou@…]

I vote for it'''

Yes I think it is a MUST-TO-HAVE. This a realy basic Wiki-Feature. I am evaluating trac for Software Development management, and just for this kind of missing features we may opt for heavier tools. Without the rename possibilty it is very hard to maintain a nice and coherent structure of the Wiki pages.

Please try to fix it as soon as possible!

[cboos]

I see how I could do it.

This depends on TracCrossReferences for finding all the occurrences of the original name, and then it depends on the refactoring of the Wiki code I'm currently doing (as a side-effect of the InterTrac support) for being able to recompose the source wiki with the page renamed.

[anonymous]

(Adding myself to the CC list.)

[cameron@…]

I am interested in this feature too.

Its a real pain to restructure wiki pages without a feature like this.

I'd prefer it to be a web interface, rather than JUST a trac-admin command, however a exposing it as a trac-admin command is also a good idea.

[cboos]

actually, I've not yet started working on that, so I remove the assignment status

[sethop@…]

This doesn't appear to have a milestone at the moment - I'd like to add my name to the people who'd like to see it happen.

[anonymous]

+1 vote! Indeed, renaming wiki pages is considered basic wiki functionality- This is really the only hole that I see in Trac...

[anonymous]

Yeah, Trac is missing this feature. Now I see the pain when refactoring my wiki pages!

+1 vote!

[anonymous]

Friends, Trac looks very promising, but until you can RENAME a wiki page, it is a non-starter for my teams. This is absolutely basic; it should be a HIGHEST priority addition.

regards, craig larman

[mitsu]

I totally agree --- you should be able to rename a page --- this should be a high priority item. If you guys don't do it I might have to do it myself!

[anonymous]

mitsu: Trac is Open Source, so instead of complaining, why don't you just implement it and share?

[anonymous]

This really needs some attention. It's potentially a deal breaker here. We might have to migrate away from trac because this functionality doesn't exist.

[cboos]

For enhancements tickets, the version is used to keep track of the Trac version in which the feature request originated, as a rough indication of the age of the request. So I reverted this field to its original value.

Note that the wiki parser in milestone:0.11 should provide the necessary infrastructure for enabling seemless renames, so I'm tentatively scheduling the ticket for 0.11.

[Noah Kantrowitz (coderanger) <coderanger@…>]

For a somewhat simplistic implementation, see the WikiRename plugin.

[cboos]

Not sure it can be done for 0.11.

Delay to 1.0 until it becomes clearer how to do it.

[anonymous]

This one has been making me crazy for a long time. It would be great to add a fix even if it only handled 90% of the situations (with a disclaimer in that case)

[anonymous]

Add my vote to this.

... and a some of the nuances involved:

1. A small "Rename Page ..." on the Edit Page.
2. Check to make sure the new page name doesn't already exist
3. Update references in other wiki pages
4. Update references in db tables used by plugins (e.g. TagsPlugin)

That last one is going to be a bit of a problem. Seems like the plugin code should be responsible for maintaining it's own tables... but is there notification/messaging system in the Trac architecture that would allow a plugin to get notified when a page name changes? (Sorry, I'm not a plugin/Trac developer so I don't know what it's guts look like).

[cboos]

See also comment:ticket:4412:8 for how an interface for page rename could look like.

[eblot]

#5193 marked as a duplicate.

[anonymous]

In the mean time you can update the wiki table in the database directly, but this is very error-prone and breaks all cross references, so use at your own risk. Don't forget to backup your files first. :)

  UPDATE wiki SET name = 'NewName' WHERE name = 'OldName'

The database can be opened like this:

  slqite project/db/trac.db

Once again, this is not recommended.

[tsul]

oops

[sethop]

I've been watching this ticket since *2005* ...but it's time to take my name off the cc list because it turns out this is the only place on the intarweb spambots can find my gmail account. Good luck finally wrapping this ticket up chaps! I'd love to offer to help but we is up to our eyeballs building out Interclue right now (4069 svn checkins and climbing....) and it sounds like this is a bug that isn't anything like as simple to fix as one might hope.

[anonymous]

sethop impressed me!

[anonymous]

[OT] Reply to sethop:

I'd love to offer to help but we is up to our eyeballs building out Interclue right now (4069 svn checkins and climbing....)

I just installed Interclue, it's really great! In particular when used on a Trac Timeline, it expands the detailed change comment for tickets ... really smart, congrats!

I've been watching this ticket since *2005* ... Good luck finally wrapping this ticket up chaps! and it sounds like this is a bug that isn't anything like as simple to fix as one might hope.

Yes, unfortunately it's not been a high prio for contributors. I'm nevertheless shifting this to 0.12 to acknowledge the user interest in getting this done.

[nkantrowitz]

While interest is great, this is simply not realistic for 0.12 (or, in fact, anything in the near future). Relation tracking is very non-trivial, and will take time to solve correctly. If all you want is a simple page move button, use the WikiRename plugin.

[broofa]

"Perfect is the enemy of Good Enough"

God, I can't even believe I'm posting this. Apologies in advance if this is troll-bait, but bugs like this are so... so... frustrating!

Moving to 1.0? Please, this should not have to wait that long.

I've read the discussions about plugin dependencies and extras and whatnot. I understand the concerns there, but can I humbly suggest that it's rather ridiculous to hold up a feature that is so essential and in such obvious demand when a "Good Enough" solution exists?

WikiRenamePlugin seems to work well enough, once you apply the patch needed to get it to play nice with the TagsPlugin. (Don't even get me started on why that patch isn't part of the codebase to begin with.)

The problem is not complex design issues, it's not finding people willing to implement a solution. The problem is that people aren't willing to set aside plans for a perfect architecture in order to integrate the solution that already exists. Please, let's just roll WikiRenamePlugin in, add the patch that lets it work for TagsPlugin, and move on. The architecture redesign is already documented under a seperate ticket (right?), so push that out to 1.0 and let's get this fixed ASAP, please.

(P.S. To those of you reaching for your mouse to copy/paste Anonymous's previous comment, "Trac is Open Source, so instead of complaining, why don't you just implement it and share?", please bear in mind that in this case, "implement and share" consists simply of forking the existing WikiRenamePlugin code and not being quite so strict about what patches are/aren't let into it.)

[nkantrowitz]

It is probably worth noting that I am also the author of the WikiRename plugin (and the script it is descended from), and I would never advocate it being merged into the Trac codebase. It is ugly, hackish, and probably unmaintainable in the long run. While it is all nice and good to say "merge it and go", we are the ones that have to pick up the angry bug reports when people find that the feature isn't fully implemented, even if the response is just "we know, working on it". I am not saying I have all the answers, but that this issue is very complex and runs deep into the philosophies of all the developers.

[anonymous]

nkantrowitz, first let me thank you for your contributions to Trac and the WikiRename plugin. Both tools are invaluable to our company and I am far from ungrateful.

Is WikiRenamePlugin really that unmaintainable? It's < 250 lines of code, none of which impact the database schema. You could roll it out in one version and yank it out in the next with no repercussions (other than users complaining about you removing needed functionality.)

'Truth is, I would be less eager to get the wiki rename functionality into the core if there were some way for us "angry users" to help maintain the existing plugin. Unfortunately development on the this "ugly, hackish, unmaintainable" codebase has stagnated for exactly the same reasons of architectural purity. See my IRC chat with CodeRanger for details. (Site may be down, but try the cache here)

As I alluded to previously, for those of us that just want to "get-er-done" and work with the solution in hand the only option is to spin the existing codebase off into a separate project. Which I guess could be done, but that seems a little inefficient and, well... rude. :)

Surely there must be a better way.

[cboos]

Replying to nkantrowitz:

While interest is great, this is simply not realistic for 0.12 (or, in fact, anything in the near future).

Sorry I just realized that I didn't sign comment:58. Actually, I believe that a realistic solution can be done for 0.12 (the way explained in comment:ticket:4412:8). We'll see ;-)

Relation tracking is very non-trivial, and will take time to solve correctly.

That would be a 2.0 thing yes, but it's not mandatory for the rename. You can fix the wrong references by hand, helped in that by the Cross-references once they become available and using the search until then.

[wcravens]

This ticket should probably not be closed. Especially by anonymous without any explanation.

[Eduardo Mercovich]

Hello everybody.

Yes, it is a must. However, it is not easy... in MoinMoin we had much discussion around it and now is implemented as a rename page only. That is, the action renames the page but all other syncronization effort is still manual.

There are more things that just a search & replace. Check MoinMoin "rename" in titles to see a few (some already mentioned in this ticket).

But even if this solutions seems somewhat limited, it works. :-)

Regards...

[uws@…]

TWiki can rename pages pretty well. It asks you which pages referencing the to-be-renamed page should be updated.

[anonymous]

Trying to remove my email from the list. It doesn't seem to work without adding a comment. Sorry, everyone.

[jace]

Another removal. Sorry.

[Zoran Isailovski]

Indeed, this feature is a must! But perhaps it can be achieved in a simpler way:

To begin with, I think, the perceived complexity in the implementation is due to a literal approach to the problem at the conceptual/strategical level. When the problem "How to rename a page" is literally mapped to a solution that renames corresponding database entries, this naturally leads to the follow-up problem to update all links to that page, which then leads to follow-up problems of own ...

Eventually, such an approach has a broad, global impact, as restructuring complex networks allways does, and is far from trivial. Even more, in conjunction with InterTrac and InterWiki, it is not even completely feasible (as other sites are involved).

An equivalent effect (meaning equivalent to the user) is easily achieved by a clone-and-redirect strategy:

To "rename" page P1 to P2:

1. Create a new page P2
2. Copy the content of P1 to P2
3. Delete the content of P1 (but not P1 itself)
4. Redirect P1 to P2
5. Optionally, hide P1 from public view or disable editing it

This way, all links to P1 will remain intact without fixing them throughout the network.

In other words: What you primarily need is not a page rename, but a page redirect.

Page redirects are usually much easier to handle in the software, as it affects individual nodes in the network only. (In MoinMoin, this is done with the #redirect page directive.)

Once there's a redirect mechanism in place, a page-rename is probably easily added as automation of the above steps, making it a convenience rather then a core feature.

At a later point in time, you may add a feature to adjust links in the network to bypass redirected nodes, and then extend the page-rename feature by that bypass functionality.

Until then, it may be helpful to visually mark links to redirected nodes, or even mark pages containing such links (using for ex. a sort of attention box), so the users are given a hint to fix their links.

I hope this helps uncovering a smooth and painless (or at least a not-so-painful) transition path towards resolving the issue.

Regards

-- Zoran Isailovski

PS
I raised the priority to highest to bring this issue into view again.

[cboos]

Thanks for your input on the topic. I'll try to get that done for 0.12, but I prefer to do it first with a "manual" redirect.

Besides the interface for multiple renames already described in #4412, one individual rename operation will look like this:

SrcPage content	version	comment
c1	1
c2	2
Page has been renamed to DstPage	3	renamed to DstPage

and:

DstPage content	version	comment
c2	1	renamed from SrcPage

The rename operation will have to create SrcPage@3 and DstPage@1 in the same transaction.

As said in comment:64, let's defer link rewriting at some later point (1.0 or 2.0) and focus now on the content move. The automatic redirect could also be done in a later stage (as it depends on #976).

[broofa]

re: comment:76 & comment:77 ...

Zoran wrote:

An equivalent effect (meaning equivalent to the user) is easily achieved by a clone-and-redirect strategy

Clone-and-redirect is not equivalent. Certainly not from the user's point of view. It is an operation that users can (and do) do manually fairly easily, so I'm skeptical that this will actually be of much value, and there would seem to be several downsides:

• The page history is lost or at least fragmented across multiple pages (e.g. how would I see the history of a page that has been renamed more than once?)
• The number of pages grows with each rename, which leads to issues about how to manage page bloat. (e.g. the title index will be "polluted" with old page names, unless Trac is somehow smart about pre-clone versions of pages.)
• Most importantly, the old page cannot be reused for new content. You have to keep it around for the redirect link and the pre-rename history. It essentialy becomes a 'tombstone page' that can't be touched. :-(

I believe the core value in a rename feature continues to be in the problem everyone is dancing around - the ability to update references to the page. This is virtually impossible for a user to do manually. Thus, it's where Trac has the most to offer.

While I understand that updating references in content from TagsPlugin/InterTrac/InterWiki may be problematic, I suspect that many (most!) users would be ecstatic to have Trac just make a reasonable effort, even it comes plastered with caveats about how references in these 3rd party tools may not be properly updated.

My $.02.

[cboos]

I understand your concerns, however:

• even if the page history is fragmented, it should be possible to follow the history in a convenient way; i.e. in the example from comment:77, the renamed from SrcPage creation comment for DstPage could actually be a link to the SrcPage history
• granted, the old pages have to stay if one don't want to have stale links
• however, nothing prevents you from reusing the source page for new content, just be sure to keep a reference to the "copied to" page in some visible place, e.g. a Warning box or a "See also: " note, as relevant.

While I'm sure the link updating feature has a lot of value, I don't think it's the only use case: there will always be situations where you want to have more control over the replacement of the links (i.e. when splitting a page in two or more pages, some links will rather keep the original name, some will have to be modified).

Also, regarding the bloat, you have to be aware that if we're doing the link updating, this will create a new version of every page that needs to be modified! Not the least costly variant...

[anonymous]

Replying to broofa:

Clone-and-redirect is not equivalent. Certainly not from the user's point of view ...

...

I believe the core value in a rename feature continues to be in the problem everyone is dancing around - the ability to update references to the page. This is virtually impossible for a user to do manually. Thus, it's where Trac has the most to offer.

---

In theory, you are right. A real rename with automatic reference fixing is the ultimate 100% everyone wants.

On the other hand, it is also true that a quest for those 100% often leaves us with 0%. I've seen many endeavors that never grew out of an exploration phase because of that, and this ticket strongly seems like one of them.

Do we want to live with 0%? Nope! Then we need to consider meaningful intermediate milestones (50%, 75% etc).

If you've read my comment carefully, you should have noticed that I propose a transition path to those 100% that starts (rather then ends) with page redirects.

Besides, the technique I described works fairly well in practice. Communities went a long way with nothing more than that.

Furthermore, none of your issues except the 3rd are of a scale that can't be handled with ease by the software (all of the changes should have local impact), so they can (and should) be integrated in the transition path as well.

Cheers -- Zoran Isailovski

[anonymous]

Replying to cboos:

I understand your concerns, however: - even if the page history is fragmented, it should be possible to follow the history in a convenient way; i.e. in the example from comment:77, the renamed from SrcPage creation comment for DstPage could actually be a link to the SrcPage history

Yes, and if a page is renamed four times over it's history, you have to click through four links to follow that history. Is this acceptable?

- granted, the old pages have to stay if one don't want to have stale links - however, nothing prevents you from reusing the source page for new content, just be sure to keep a reference to the "copied to" page in some visible place, e.g. a Warning box or a "See also: " note, as relevant.

So users are responsible for maintaining the content required to get to previous versions of the page? You have a lot more faith in users than I do. :-P

While I'm sure the link updating feature has a lot of value, I don't think it's the only use case: there will always be situations where you want to have more control over the replacement of the links (i.e. when splitting a page in two or more pages, some links will rather keep the original name, some will have to be modified).

Sure, but those cases are not "renaming", they're "copying" or "cloning" or "branching"... whatever you want to call it. While useful, these are different features.

Also, regarding the bloat, you have to be aware that if we're doing the link updating, this will create a new version of every page that needs to be modified! Not the least costly variant...

Multiple versions of a page don't add to the cognitive load of users in the way that the bloating the number of pages does. As a user, I am blisfully ignorant of how many versions of pages there may be. And as an admin, I've got GBytes of storage, so don't really care either.

---

Replying to Zoran Isailovski:

---- In theory, you are right. A real rename with automatic reference fixing is the ultimate 100% everyone wants. On the other hand, it is also true that a quest for those 100% often leaves us with 0%. I've seen many endeavors that never grew out of an exploration phase because of that, and this ticket strongly seems like one of them. Do we want to live with 0%? Nope! Then we need to consider meaningful intermediate milestones (50%, 75% etc).

You're preaching to the choir, Zoran - see my comment:61 from June of last year.

If you've read my comment carefully, you should have noticed that I propose a transition path to those 100% that starts (rather then ends) with page redirects. Besides, the technique I described works fairly well in practice. Communities went a long way with nothing more than that. Furthermore, none of your issues except the 3rd are of a scale that can't be handled with ease by the software (all of the changes should have local impact), so they can (and should) be integrated in the transition path as well.

My point is that this plan should not be mistaken for a transition path to a renaming feature. It's a different feature that we should just call, "Page Cloning", or "Page Branching".

A "transition path" implies that you end up with a solution to the problem. But your plan doesn't do that - it just pushes the reference updating issue out to some indefinite time in the future. For people that actually want a renaming feature, they're stuck with a half-baked solution that causes more problems than it solves!

[Zoran Isailovski]

Replying to cboos:

As said in comment:64, let's defer link rewriting at some later point (1.0 or 2.0) and focus now on the content move.

I'm absolutely with you!

... but I prefer to do it first with a "manual" redirect.

... oh :(

The automatic redirect could also be done in a later stage (as it depends on #976).

If you would make the automatic content for SrcPage@3 ("renamed to DstPage") configurable, I could change it to something like "[[Redirect(DstPage)]]" and code that redirect macro myself (should be fairly easy, I guess).

[Zoran Isailovski]

Replying to anonymous:

Yes, and if a page is renamed four times over it's history, you have to click through four links to follow that history. Is this acceptable?

Yes, it is! Except maybe for control neurotics who love to comb through page histories all day. :-P

You have a lot more faith in users than I do. :-P

Yeap, that's not surpizing :-P

Multiple versions of a page don't add to the cognitive load of users in the way that the bloating the number of pages does. As a user, I am blisfully ignorant of how many versions of pages there may be. And as an admin, I've got GBytes of storage, so don't really care either.

So, if you don't care, why do you nag about following page history through more then one link then?

You're preaching to the choir, Zoran - see my comment:61 from June of last year.

Oh, you sing? ;-P

And yes, I've seen your comment:61, and wondered why you still insist on 100% while still having 0%.

---

Sure, but those cases are not "renaming", they're "copying" or "cloning" or "branching"... whatever you want to call it. While useful, these are different features.

My point is that this plan should not be mistaken for a transition path to a renaming feature. It's a different feature that we should just call, "Page Cloning", or "Page Branching".

You might have heared that there's a difference between a problem space and a solution space. Those are different features in the solution space, but taken together, they solve the item in the problem space. It is so obvious!

A "transition path" implies that you end up with a solution to the problem. But your plan doesn't do that - it just pushes the reference updating issue out to some indefinite time in the future. For people that actually want a renaming feature, they're stuck with a half-baked solution that causes more problems than it solves!

Either you still don't read carefully, or just don't see the obvious... :-/

Finally, "causes more problems than it solves" is nothing but a sound bite without substance! :-|

[cboos]

Replying to broofa:

if a page is renamed four times over it's history, you have to click through four links to follow that history. Is this acceptable?

I think so, yes, given the very low expected frequency of a page being renamed 4 times... Or do you have an use case in mind which will require frequent renaming of a page?

... those cases are not "renaming", they're "copying" or "cloning" or "branching"... whatever you want to call it. While useful, these are different features.

Agreed. My point is that while we're at it, we can also from there implement cheaply a "rename" feature, although not a perfect one.

Replying to Zoran Isailovski:

---- In theory, you are right. A real rename with automatic reference fixing is the ultimate 100% everyone wants. On the other hand, it is also true that a quest for those 100% often leaves us with 0%.

- see my comment:61 from June of last year.

Well, for the automatic wiki content update and link rewriting, I think we should aim at a 100% correct solution, otherwise there will be more harm than good done. That's one of the goals I want to achieve with the wiki refactoring of 0.12, be able to recreate the original input text from the Wiki DOM. Replacing the links would then just consist of updating the relevant targets in the wiki link nodes before serializing the tree to source. So this task is clearly post-0.12.

For people that actually want a renaming feature, they're stuck with a half-baked solution that causes more problems than it solves!

True, doing the renaming by "abusing" the clone feature will only be an interim measure, but while it has its downsides (leaving too many redirect pages around), I'm not sure it's as bad as you think and it can eventually be fixed at a later stage, by doing a "merge" operation (do the "rename links" for the source and concatenate the history).

Now, that discussion has been already a bit too long for this ticket, so at some point I'll summarize the approach in a TracDev/AdvancedWikiOperations page and follow-up there - sorry for the noise for people only interested in a solution, whatever it is, and thank you broofa and Zoran for the useful input (feel free to comment further on that page later on).

[anonymous]

Trac developers, As a user, the renaming solution that covers the vast majority of problems I encounter is to simply rename the page, breaking all existing links to it.

I previously used moinmoin and as far as I can tell this was their solution.

People occasionally name a page very poorly and decide later to remedy it. It takes all of a matter of seconds to go and update the, typically, single place that links to the poorly named page. I implore you, put in a fix that does nothing more than that.

Let those who *need* a more complex renaming system argue over how it should be implemented. Until then, I'm left wondering why I moved from moinmoin. I guess I just expected trac to have this absolutely basic feature.

Regards, Anonymous User

[kasper.souren@…]

This feature is quite essential.

In MediaWiki OldTitle? is moved to NewTitle? like this.

1. move entire page (and history) to NewTitle?,
2. create new page with OldTitle? that only contains #redirect
   Error: Failed to load processor NewTitle

   No macro or processor named 'NewTitle' found

And since it's not comfy to have 5 subsequent redirects there is a Special page that shows double redirects, e.g. http://en.wikipedia.org/wiki/Special:DoubleRedirects

[cboos]

Replying to kasper.souren@gmail.com:

This feature is quite essential. In MediaWiki OldTitle? is moved to NewTitle? like this. 1. move entire page (and history) to NewTitle?, 1. create new page with OldTitle? that only contains #redirect [[NewTitle]]

Well, I have actually implemented that (i.e. 1.) yesterday evening - so expect an experimental branch this W.E. ;-)

[cboos]

Follow-up to comment:88: The branch is now ready to test, see WikiRename.

[ralf.henschkowski@…]

I tried that branch and got the following error:

Trac detected an internal error:

TemplateNotFound?: Template "wiki_rename.html" not found