Wiki Rename

The base feature has now landed on trunk for 0.12, see r9362 and r9363.

Among the various possibilities for performing a rename, this implementation aims at simplicity. The page name is modified "in-place", i.e. the object identity is mutated and as such, the whole history is kept and becomes associated to the renamed wiki page.

• Status: initial version, should work reasonably well.
• View the changes: log:sandbox/wiki-rename
• Test the branch, e.g.:

  % svn co http://svn.edgewall.org/repos/trac/sandbox/wiki-rename
  % cd wiki-rename
  % python setup.py develop
  % python trac/web/standalone.py -p 8000 <your-test-environment>
  

You need to be a WIKI_ADMIN in order to be able to rename a page (or at the very least, have the new WIKI_RENAME permission).

How it works

Example: renaming WikiStart to ProjectHome

• before the rename:

pagename	text	comment
WikiStart	version1	comment1
WikiStart	version2	comment2
WikiStart	version3	comment3

• after the rename:

pagename	text	comment
ProjectHome	version1	comment1
ProjectHome	version2	comment2
ProjectHome	version3	comment3

the WikiStart page will be (optionally) recreated with a redirection to the new page:

pagename	text	comment
WikiStart	See ProjectHome	Renamed WikiStart to ProjectHome

Note that this is very similar to how ​moving a page in MediaWiki works.

Overview of the changes

• added new WikiPage.rename and Attachment.reparent_all methods
• added new wiki_rename.html template and the corresponding handler methods, WikiModule._render_confirm_rename and WikiModule._do_rename methods

Discussion

Feel free to provide feedback.

• Would be nice to have a ​HTTP 301 redirect from the old wiki page to the new one, to keep searchengine rankings etc.
  • Right, real redirect is on the TODO list (#976)

• Another TODO optionally rename sub-pages as well, and more generally, have the possibility to do batch renames

• Another TODO would be nice to have an entry in the history of the page including the name, date and optional comment of the rename event.

• Another TODO also rename all links to renamed pages on all other pages and create for this a new version for all affected pages
  • Cabbiepete: This sounds like an excellent idea currently re-organising the wiki structure is quite painful.

• More robust error handling: what happens if a reparent fails mid-way (e.g. permission issue for one attachment)? The whole transaction is rolled back, but some attachment files could have been moved already. Should we try to move them back? Should we warn the user about what already got moved? After fixing the permission issue, a new rename should work, which might not be the case if the attachment table and the files are not in sync.
  • We have the same issue when deleting pages. Actually, any time a filesystem change must be atomic with a DB change. I thought about adding some kind of "post-commit task list" where e.g. the attachment reparenting method registers a callable with the transaction to be executed after a successful commit. So the transaction would complete, and only then would all the items in the list be called to execute FS operations.
    • but what if that post-commit action fails, then? We'd have again a inconsistent state… Maybe we need a pre-commit and a post-commit callback, so a "safer" reparent could work that way:
      1. pre-commit: copy all the attachments to the new location in the FS
      2. only if 1. succeeds, perform the DB operation
      3. always perform the post-commit, passing the status of the previous steps as arguments. If 1. has succeeded, we can try to remove the files at their old location. If this last step fails, bad luck but at least the DB and FS are consistent, the FS can eventually be cleaned manually afterwards.
      In fact, rather than just the success status, we can pass some "state" object from one step to the next.

---

See also: #1106, TracDev/Proposals/AdvancedWikiOperations