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!

[Christian Boos]

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.

[Christian Boos]

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.

[Christian Boos]

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.

[Christian Boos]

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).

[Christian Boos]

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

[Emmanuel Blot]

#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.

[Noah Kantrowitz]

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.)

[Noah Kantrowitz]

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.

[Christian Boos]

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.

[Christian Boos]

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.

[Christian Boos]

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! :-|

[Christian Boos]

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 NewTitle

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

[Christian Boos]

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,
2. 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. ;-)

[Christian Boos]

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

[Christian Boos]

Ah, sure :-)

Fixed in r6496 and r6497. You can even pick r6498, merged with latest trunk.

[broofa]

Will there be a way to disable this built-in wiki rename feature?

If a site has the TracWikiRename plugin installed there will be two ways to rename a page, Which I expect users will find confusing.

[anonymous]

I guess this is yet-another-vote for a basic renaming capability in Trac. IMHO, the various reasons to not include even a basic renaming feature in Trac simply do not recognized the fact that users vastly prefer an imperfect tool over a tool that does not have key features.

The perfect is the enemy of the good. —Voltaire

[joel@…]

Indeed, a must have feature.

[kamil@…]

I have to throw my vote in here as well. We have a Trac installation with 1000+ wiki pages that's used as our organization's central knowledge base. We've been using WikiRename for some time but there are way too many bugs in related to page hierarchy and attachments to allow us to put it in to general use. Only our administrators can currently rename pages and typically it involves a big cleanup effort of the attachment store on the server if they were in a hierarchy.

I think a feature like this is key for any decently sized wiki install.

[Christian Boos]

Replying to kamil@…:

We've been using WikiRename for some time but there are way too many bugs in related to page hierarchy and attachments to allow us to put it in to general use.

Are you talking about the WikiRename branch or the ​TracHacks:WikiRenamePlugin? If it is the former, then please create tickets here so that I can fix those issues. In my (perhaps limited) testing, renaming pages in a hierarchy works fine with the WikiRename branch, including moving the attachments.

[kamil@…]

I meant ​WikiRenamePlugin. I wasn't aware there is a branch. Sorry for the confusion.

[deisner@…]

I've never written a Wiki, so I don't really know what I'm talking about. Also, the following is probably academic at this point. But it seems to me that using the name of a page as its unique identifier may have been a poor design choice. Instead, each wiki page could have a globally unique id (GUID). The user would see:

Here you can find the DesignDocument.

but internally, hidden from the user, this would be stored as:

Here you can find the [wiki:{3F2504E0-4F89}].

The Trac software would maintain the name of the page ("DesignDocument") as metadata, as well as a table for mapping page names to GUIDs. So, for example, if a user enters a CamelCase string in another page, a quick lookup would replace this with the [wiki:{<GUID>}] representation internally.

With this design, page renames are just a matter of changing metadata, and all the links continue to work. No need to search through the bodies of all the pages and update them whenever a page is renamed.

[ariel@…]

The truth is, while the 'wiki' concept and structure is extremely elegant, it works great for a democratic compendium of information such as wikipedia, but not so well for general information and document management. In more general situations, we need features such as:

• page ownership
• namespace hierarchy
• page permissions
• ability to move/rename pages
• others?

(Why doesn't that list render?)

Here is a solution I have thought about for a while:

As the previous poster suggested, give each page a UID. Then create a dictionary that maps UIDs to meta information. For example:

{
   12345 : {
      'title' : 'Project Overview',
      'location' : /projects/public,
      'permissions' : ['r-','r-','rw'],
      'creation_date' : <time stamp>,
      'tags' : ['tag1', 'tag2', 'another tag'],
      'history' : <some record of diffs or whatever>,
      'outlinks' : <list UIDs this page refers to>,
      'inlinks' : <list of UIDs that refer to this page>,
      }
   }

So that pages can be linked to without knowing UIDs, we would construct a link by using the full location, e.g. [/project/public/'Project Overview' Project Overview]. Just as in a file system of any kind, the full location would be unique.

Then, suppose we want to change the title of a page, for example 'Project Overview' to 'Big Picture'. This would change the full location. Therefore, we would do something like this:

for page in current_page.inlinks:
   page.rewrite_links("/project/public/'Project Overview'", "/project/public/'Big Picture'")

[robert@…]

Sorry for the spam, but apparently I don't have the ability to remove my email from the Cc: list (???)

Can someone do that for me?

[anonymous]

Replying to robert@…:

Sorry for the spam, but apparently I don't have the ability to remove my email from the Cc: list (???)

Can someone do that for me?

Urr… nevermind - looks like that worked. (And, WTF, I have to leave a comment in order to remove myself from Cc: field??? My first attempt, with not comment, was rejected as potential spam. Weird. Sorry for the 2x spam.)

[Christian Boos]

[OT] #1459 quirk

---

Replying to anonymous:

Replying to robert@…:

Sorry for the spam, but apparently I don't have the ability to remove my email from the Cc: list (???)

Can someone do that for me?

Urr… nevermind - looks like that worked. (And, WTF, I have to leave a comment in order to remove myself from Cc: field??? My first attempt, with not comment, was rejected as potential spam. Weird. Sorry for the 2x spam.)

---

When using a real nosy list notification system, we should be able to address this issue.

[ilias@…]

Replying to ariel@…:

The truth is, while the 'wiki' concept and structure is extremely elegant, it

The "priority" was set by the ticket owner (cboos, a trac developer).

You should not have altered the value.

[Christian Boos]

Good point Ilias ;-)

Back to the topic - since I got the confirmation in comment:98 that the trouble with the attachment renames came from the plugin and not the branch (where things should work fine), I'll probably refresh the branch soon and merge it in trunk.

Now for the discussion about UIDs (a.k.a. surrogate ids) in comment:99 and comment:100, I'd suggest that this discussion could be moved to TracDev/Proposals/AdvancedWikiOperations for example, or on the trac-dev MailingList.

[karl@…]

I'm interested in a trac-admin wiki rename option too, so lurking here now.

[shookie@…]

first patch including base functionality and unit tests for it (wiki-rename r7334 and r7335 adapted)

[shookie@…]

This patch differs in a few notable ways from the original code in the changesets:

• no transaction helper function, but handle_ta flags, which also obsoletes the double public and private methods
• there was an attachment_dir method to construct paths, but the current code didn't use anything like it, so I guessed this wasn't really wanted, can still be added, but doesn't remove too much redundancy IMHO
• in the unit tests I have added some asserts for attachment reparenting

Waiting for feedback, before tackling the other changesets.

[shookie@…]

cumulative patch, that adds the web ui and the redirect option (but not 301 redirect)

[shookie@…]

fixed an error case that came up in the functional tests (doing that now, but that is a different patch)

[shookie@…]

functional test for rename operations, on top of the previous patch

[shookie@…]

Ok, those patches represent the implementation of the rename-wiki branch for the current trunk. Now things that need to be done additionally, if the current patches are accepted.

1. dealing with wiki pages, whose names are hardcoded in trac, and that can be renamed, like WikiStart and TitleIndex (are there more?)
2. a 301 redirect option
3. options to let trac scan content pages for links to the to be renamed Page and change those links
4. Batch renaming. Possibly should be only available in trac-admin

[shookie@…]

I was looking for page-names that are hardcoded into trac somewhere, since that will cause problems, once renaming is allowed, although that problem already existed, because deleting was possible.

Those are the pages I found: WikiStart, TitleIndex, TracGuide, TracInstall

TracGuide and TracInstall should pose no problem anymore, once the help system is separated from the wiki (TracDev/Proposals/NewHelp).

But WikiStart and TitleIndex can be deleted or renamed and stay in the wiki. Easiest fix would be to provide a dictionary in the environment, that gets checked at the place where those pages are hardcoded right now, and that gets updated if WikiStart or TitleIndex get renamed and prevents the deletion. Or for TitleIndex the better apporach would be to not include it in the cntxmenu if it is deleted (that's the place where it is hardcoded).

[Christian Boos]

First, thanks for reviving this topic!

The attachment:rename_ui_redirect.2.diff​ has a few issues compared to r7336:

• please keep line length under 80 chars (see TracDev/CodingStyle)
• _render_rename_form, the last 3 lines are wrongly indented, they don't belong to the else clause

Also, any reason you renamed _render_confirm_rename to _render_rename_form? IMO, the original name was better (symmetry with _render_confirm_delete and more specific, as we might add other rename related forms).

Finally, it seems the attachments are not moved after a rename.

Now looking at the first patch attachment:rename_wikipages_base_functionality.diff​:

• same issue with line length
• the reparent_all is called, but not in the same transaction; the rename operation should be "atomic"
• the old_dir in reparent_all is wrong (you forgot to url encode the id) - maybe there was a need for attachment_dir after all :-)

Side note, the test_rename_page should probably be expanded to test the renaming of a page with attachments (and the origin page name should contain a space).

[dispressa@…]

Is InterMapTxt another hardcoded name that needs to be considered?

Replying to shookie@…:

I was looking for page-names that are hardcoded into trac somewhere, since that will cause problems, once renaming is allowed, although that problem already existed, because deleting was possible.

Those are the pages I found: WikiStart, TitleIndex, TracGuide, TracInstall

TracGuide and TracInstall should pose no problem anymore, once the help system is separated from the wiki (TracDev/Proposals/NewHelp).

But WikiStart and TitleIndex can be deleted or renamed and stay in the wiki. Easiest fix would be to provide a dictionary in the environment, that gets checked at the place where those pages are hardcoded right now, and that gets updated if WikiStart or TitleIndex get renamed and prevents the deletion. Or for TitleIndex the better apporach would be to not include it in the cntxmenu if it is deleted (that's the place where it is hardcoded).

[Christian Boos]

Replying to dispressa@…:

Replying to shookie@…:

I was looking for page-names that are hardcoded into trac somewhere, since that will cause problems, once renaming is allowed, although that problem already existed, because deleting was possible.

Is InterMapTxt another hardcoded name that needs to be considered?

Yes, it could be done as a warning (same warning could be shown before a delete).

[Christian Boos]

Depends on #8751.

[jhopping@…]

removing e-mail addy

[shookie@…]

equivalent to the first patch here, but on top of ​http://trac.edgewall.org/attachment/ticket/8751/transaction_rename_base.diff

[shookie@…]

fixed the strange import Attachment error in wiki/model.py, that doesn't show up in unit tests for some reason, but only when starting web server

[shookie@…]

make renames available via web interface, on top of rename_base_functionality.2.diff

[shookie@…]

Functional tests will will follow. Also, the warning for changing hard coded page names.

Also, there should be a standard automated way to clean up temp files in the unit tests, because if they fail, and the files don't get deleted, they mess up the next unit test.

[shookie@…]

the rename functional tests

[shookie@…]

Ok, I thought a bit more how to solve the problem of leaving dangling hardcoded wiki pages with rename or delete, and the cleanest way to solve this once and for all (and for possible future extensions) I think is to introduce an additional db table "system_page" that is just a mapping of sys_id (which is the current page name) to path. And the few places in the code that have hard coded page references check against that. And the delete and rename functions keep it up to date and also issue warning based on that table.

Will be a very small table anyway and be kept fully in cache, so I guess no major performance hit.

[shookie@…]

full rename on top of trunk

[shookie@…]

contains full rename, and implements urlmapping to avoid problems with renaming or deleting standard pages, on top of trunk

[shookie@…]

Some comments on ​rename_with_page_save.diff:

• added a new table urlmap, that holds information on urls that are hardcoded somewhere in the trac code
• this new table is used in several ways:
  • to remove the hardcoded urls and map them where they can cause trouble
  • to check during renames and deletions for them and issue warnings
  • to update the mappings itself in deletions and renames and page creations that refer to those special pages, so that it should be impossible to have deserted hardcoded links unless the admin is fully aware and approves
• the table urlmap can be easily extended, in case new special pages become necessary, it's not restricted to use in the wiki
• quite a few new tests added
• also contains some minor cosmetic fixes in comparison to the previous patch

[Christian Boos]

I should have commented a bit earlier, but I'm not sure I like the idea of an url_map. Ok, special Wiki pages are special, but if someone wants to delete or rename it and has the permission to do it, then let him do it, I don't think it's worth trying to prevent him to do so. If done by mistake, the recovery should be pretty easy to do anyway.

[shookie@…]

Replying to cboos:

I'm not preventing it. I just give warnings. And prevent the bad things that can happen from happening when WikiStart and TitleIndex are suddenly not valid addresses anymore (the other pages are less critical, since they are only used in adminstrative settings).

But WikiStart and TitleIndex are both in the context menu … hardcoded. So if you delete or rename them, you will have dead links on every page unless this is addressed.

And WikiStart is also the default page for the wiki … hardcoded. So if you delete or rename it, you will get 404 on your home page. Certainly not something we want.

This has to be addressed in some way. Whether those mappings are done automatically, as I have done here, or by hand, and whether they are in the config, or in the db, I frankly don't really care. But some kind of mapping has to be done, or those hardcoded pages will keep causing trouble.

What speaks for having it in the db is, that they refer to entries in the db, namely WikiPage names. What speaks for doing it automatically is, that it is trivial to do so, once you have that mapping, and you need that mapping, or you won't even be able to warn the admin on deleting or renaming a hardcoded page.

[shookie@…]

I just want to add, that WikiStart and TitleIndex also are the most likely pages anyone would want to rename, simply because of their prominence, and because you don't choose their initial name in the first place.

As it stands, renaming them is simply not an option, even if renaming is possible, because of the above mentioned problems that arise. Problems an admin can do nothing about, except not renaming those pages.

Renaming any other page was actually already possible, by manipulating the database directly, which is not that hard for an admin. So I'd say ensuring that renaming or deleting those special pages doesn't cause problems is the actual point of this ticket.

[shookie@…]

Well, after thinking abaut the mapping code I don't really like it anymore either. I guess just adding rename_full.diff for now (with a few minor cosmetic changes backported from the following patch, and hardcoded warnings maybe) is sufficient.

And to solve this hardcoded url problem (which also can become an issue in the requesthandler matching methods) , its better to do a more general "url virtualization" to use everywhere, that works without a separate db lookup on every request. Best place for that is the href class I think.

[Christian Boos]

Replying to shookie@…:

… I guess just adding rename_full.diff for now (with a few minor cosmetic changes backported from the following patch, and hardcoded warnings maybe) is sufficient.

Please post such a patch when you have it. This will anyway be one step forward and the door is not closed for further refinements ;-)

But let's now finalize this ticket with, as you said, a stripped down version of rename_full.diff​ without urlmap.

[shookie@…]

Replying to cboos:

But let's now finalize this ticket with, as you said, a stripped down version of rename_full.diff​ without urlmap.

Ok. I won't be home till Sunday evening, and don't really have a development environment suitable for trac here, so I guess the next patch I will upload next Monday.

[shookie@…]

The renaming functionality, with no frills, on top of trunk

[Remy Blank]

I have been cleaning up and fixing the last patch, but it's not complete yet. It should be ready within a few days. Stay tuned.

[Remy Blank]

Refactored and cleaned-up rename_simple.diff​.

[Remy Blank]

The patch above is a cleaned-up, refactored and fixed version of rename_simple.diff​. Review welcome.

Jan, please be careful about the following points:

• Make sure you use spaces and not tabs for indentation. Your patch contains tabs.
• Always make your tests fail first, then fix them. This ensures your tests are actually run. In your patch, the functional test is not registered, and therefore not run at all.

[Remy Blank]

Patch applied in [9362] with a few usability improvements.

[Remy Blank]

Added a command wiki rename to trac-admin in [9363]. The command doesn't provide the possibility to optionally add a redirection page, as the same effect can be achieved with wiki import and a bit of scripting.

This concludes adding basic renaming capability. I suggest we close this ticket, and open a new one for "advanced wiki page renaming" (or wait until someone suggests updating wiki page references on rename, which shouldn't take long ;-).

[Daniel Serodio <dserodio@…>]

That's great news! Thanks for finally implementing this 5 year-old feature request.

[Remy Blank]

Mmh, I feel an urge to close tickets :)

[Remy Blank]

Christian, about [9372], Jan actually had the redirection page text localized, but I removed it for the same reason that you re-added it: because the text could always be fixed if it wasn't appropriate ;-) Only I thought English would be a better starting point.

[Christian Boos]

Replying to rblank:

I thought English would be a better starting point.

For a multilingual Trac, probably. Maybe we can translate the message only when [trac] default_language is set (and then using that language)? See #8117.

So if I would browse a Trac instance for which the default language is German, using French as my preferred language, the redirection page will be generated in German.

[Remy Blank]

Replying to cboos:

For a multilingual Trac, probably. Maybe we can translate the message only when [trac] default_language is set (and then using that language)? See #8117.

Sounds like a good idea, yes.