doc/todo/Moving_Pages.mdwn

   1 I thought I'd draw attention to a desire of mine for **ikiwiki**.  I'm no power-user, and mostly I do fairly simple stuff with my [wiki](http://kitenet.net/~kyle/family/wiki).
   2
   3 However, I would like the ability (now) to **rename/move/delete** pages.  As part of having a genealogy wiki, I've put name and dates of birth/death as part of the title of each article (so to avoid cases where people have the same name, but are children/cousins/etc of others with that name).  However, some of this information changes.  For instance, I didn't know a date of death and now I do, or I had it wrong originally, or it turns out someone is still alive I didn't know about.  All of these cases leave me with bad article titles.
   4
   5 So, I can go ahead and move the file to a new page with the correct info, orphan that page, provide a link for the new page if desired, and otherwise ignore that page.  But then, it clutters up the wiki and serves no useful purpose.
   6
   7 Anyway to consider implementing **rename/move/delete** ?  I certainly lack the skills to appreciate what this would entail, but feel free to comment if it appears impossible, and then I'll go back to the aforementioned workaround.  I would prefer simple rename, however.
   8
   9 Thanks again to [Joey](http://kitenet.net/~joey) for putting ikiwiki together.  I love the program.
  10
  11 *[Kyle](http://kitenet.net/~kyle/)=*
  12
  13 > Took a bit too long, but [[done]] now. --[[Joey]]
  14
  15 ----
  16
  17 The MediaWiki moving/renaming mechanism is pretty nice.  It's easy to get a list of pages that point to the current page.  When renaming a page it sticks a forwarding page in the original place.  The larger the size of the wiki the more important organization tools become.
  18
  19 I see the need for:
  20
  21 * a new type of file to represent a forwarding page
  22 * a rename tool that can
  23   * move the existing page to the new name
  24   * optionally drop a forwarding page
  25   * optionally rewrite incoming links to the new location
  26
  27 Brad
  28
  29 > This could be implemented through the use of an HTTP redirect to the
  30 > new page, but this has the downside that people may not know they're being
  31 > redirected.
  32 >
  33 > This could also be implemented using a combination of raw inline and meta
  34 > to change the title (add a "redirected from etc." page. This could be done
  35 > with a plugin. A redirect page would be [[!redirect page="newpage"]].
  36 > But then if you click "edit" on this redirect page, you won't be able
  37 > to edit the new page, only the call to redirect.
  38 > --Ethan
  39
  40 -----
  41
  42 I'm going to try to run through a full analysis and design for moving and
  43 deleting pages here. I want to make sure all cases are covered. --[[Joey]]
  44
  45 ## UI
  46
  47 The UI I envision is to add "Rename" and "Delete" buttons to the file edit
  48 page. Both next to the Save button, and also at the bottom of the attachment
  49 management interface.
  50
  51 The attachment(s) to rename or delete would be selected using the check boxes
  52 and then the button applies to all of them. Deleting multiple attachments
  53 in one go is fine; renaming multiple attachments in one go is ambiguous,
  54 and it can just error out if more than one is selected for rename.
  55 (Alternatively, it could allow moving them all to a different subdirectory.)
  56
  57 The Delete buttons lead to a page to confirm the deletion(s).
  58
  59 The Rename buttons lead to a page with a text edit box for editing the
  60 page name. The title of the page is edited, not the actual filename.
  61
  62 There will also be a optional comment field, so a commit message can be
  63 written for the rename/delete.
  64
  65 Note that there's an edge case concerning pages that have a "/" encoded
  66 as part of their title. There's no way for a title edit box to
  67 differentiate between that, and a "/" that is instended to refer to a
  68 subdirectory to move the page to. Consequence is that "/" will always be
  69 treated literally, as a subdir separator; it will not be possible to use
  70 this interface to put an encoded "/" in a page's name.
  71
  72 Once a page is renamed, ikiwiki will return to the page edit interface,
  73 now for the renamed page. Any modifications that the user had made to the
  74 textarea will be preserved.
  75
  76 Similarly, when an attachment is renamed, or deleted, return to the page
  77 edit interface (with the attachments displayed).
  78
  79 When a page is deleted, redirect the user to the toplevel index.
  80
  81 Note that this design, particularly the return to the edit interface after
  82 rename, means that the rename button can *only* be put on the page edit ui.
  83 It won't be possible to put it on the action bar or somewhere else. (It
  84 would be possible to code up a different rename button that doesn't do
  85 that, and use it elsewhere.)
  86
  87 Hmm, unless it saves the edit state and reloads it later, while using a separate
  88 form. Which seems to solve other problems, so I think is the way to go.
  89
  90 ## SubPages
  91
  92 When renaming `foo`, it probably makes sense to also rename
  93 `foo/Discussion`. Should other SubPages in `foo/` also be renamed? I think
  94 it's probably simplest to rename all of its SubPages too.
  95
  96 (For values of "simplest" that don't include the pain of dealing with all
  97 the changed links on subpages.. as well as issues like pagespecs that
  98 continue to match the old subpages, and cannot reasonably be auto-converted
  99 to use the new, etc, etc... So still undecided about this.)
 100
 101 When deleting `foo`, I don't think SubPages should be deleted. The
 102 potential for mistakes and abuse is too large. Deleting Discussion page
 103 might be a useful exception.
 104
 105 TODO: Currently, subpages are not addressed.
 106
 107 ## link fixups
 108
 109 When renaming a page, it's desirable to keep links that point to it
 110 working. Rather than use redirection pages, I think that all pages that
 111 link to it should be modified to fix their links.
 112
 113 The rename plugin can add a "rename" hook, which other plugins can use to
 114 update links &etc. The hook would be passed page content, the old and new
 115 link names, and would modify the content and return it. At least the link
 116 plugin should have such a hook.
 117
 118 After calling the "rename" hook, and rendering the wiki, the rename plugin
 119 can check to see what links remain pointing to the old page. There could
 120 still be some, for example, CamelCase links probably won't be changed; img
 121 plugins and others contain logical links to the file, etc. The user can be
 122 presented with a list of all the pages that still have links to the old
 123 page, and can manually deal with them.
 124
 125 In some cases, a redirection page will be wanted, to keep long-lived urls
 126 working. Since the meta plugin supports creating such pages, and since they
 127 won't always be needed, I think it will be simplest to just leave it up to
 128 the user to create such a redirection page after renaming a page.
 129
 130 ## who can delete/rename what?
 131
 132 The source page must be editable by the user to be deleted/renamed.
 133 When renaming, the dest page must not already exist, and must be creatable
 134 by the user, too.
 135
 136 lWhen deleting/renaming attachments, the `allowed_attachments` PageSpec
 137 is checked too.
 138
 139 ## RCS
 140
 141 Three new functions are added to the RCS interface:
 142
 143 * `rcs_remove(file)`
 144 * `rcs_rename(old, new)`
 145 * `rcs_commit_staged(message, user, ip)`
 146
 147 See [[rcs_updates_needed_for_rename_and_remove]].
 148
 149 ## conflicts
 150
 151 Cases to consider:
 152
 153 * Alice clicks "delete" button for a page; Bob makes a modification;
 154   Alice confirms deletion. Ideally in this case, Alice should get an error
 155   message that there's a conflict.
 156   Update: In my current code, alice's deletion will fail if the file was
 157   moved or deleted in the meantime; if the file was modified since alice
 158   clicked on the delete button, the modifications will be deleted too. I
 159   think this is acceptable.
 160 * Alice opens edit UI for a page; Bob makes a modification; Alice
 161   clicks delete button and confirms deletion. Again here, Alice should get
 162   a conflict error. Note that this means that the rcstoken should be
 163   recorded when the edit UI is first opened, not when the delete button is
 164   hit.
 165   Update: Again here, there's no conflict, but the delete succeeds. Again,
 166   basically acceptible.
 167 * Alice and Bob both try to delete a page at the same time. It's fine for
 168   the second one to get a message that it no longer exists. Or just to
 169   silently fail to delete the deleted page..
 170   Update: It will display an error to the second one that the page doesn't
 171   exist.
 172 * Alice deletes a page; Bob had edit window open for it, and saves
 173   it afterwards. I think that Bob should win in this case; Alice can always
 174   notice the page has been added back, and delete it again.
 175   Update: Bob wins.
 176 * Alice clicks "rename" button for a page; Bob makes a modification;
 177   Alice confirms rename. This case seems easy, it should just rename the
 178   modified page.
 179   Update: it does
 180 * Alice opens edit UI for a page; Bob makes a modification; Alice
 181   clicks rename button and confirms rename. Seems same as previous case.
 182   Update: check
 183 * Alice and Bob both try to rename a page at the same time (to probably
 184   different names). Or one tries to delete, and the other to rename.
 185   I think it's acceptible for the second one to get an error message that
 186   the page no longer exists.
 187   Update: check, that happens
 188 * Alice renames a page; Bob had edit window open for it, and saves
 189   it afterwards, under old name. I think it's acceptible for Bob to succeed
 190   in saving it under the old name in this case, though not ideal.
 191   Update: Behavior is the same as if Alice renamed the page and Bob created
 192   a new page with the old name. Seems acceptable, though could be mildly
 193   confusing to Bob (or Alice).
 194 * Alice starts creating a new page. In the meantime, Bob renames a
 195   different page to that name. Alice should get an error message when
 196   committing; and it should have conflict markers. Ie, this should work the
 197   same as if Bob had edited the new page at the same time as Alice did.
 198   Update: That should happen. Haven't tested this case yet to make sure.
 199 * Bob starts renaming a page. In the meantime, Alice creates a new page
 200   with the name he's renaming it to. Here Bob should get a error message
 201   that he can't rename the page to an existing name. (A conflict resolution
 202   edit would also be ok.)
 203   Update: Bob gets an error message.
 204 * Alice renames (or deletes) a page. In the meantime, Bob is uploading an
 205   attachment to it, and finishes after the rename finishes. Is it
 206   acceptible for the attachment to be saved under the old name?
 207   Update: Meh. It's certianly not ideal; if Bob tries to save the page he
 208   uploaded the attachment to, he'll get a message about it having been
 209   deleted/renamed, and he can try to figure out what to do... :-/
 210 * I don't know if this is a conflict, but it is an important case to consider;
 211   you need to make sure that there are no security holes.  You dont want
 212   someone to be able to rename something to <code>/etc/passwd</code>.
 213   I think it would be enough that you cannot rename to a location outside
 214   of srcdir, you cannot rename to a location that you wouldn't be able
 215   to edit because it is locked, and you cannot rename to an existing page.
 216
 217   > Well, there are a few more cases (like not renaming to a pruned
 218   > filename, and not renaming _from_ a file that is not a known source
 219   > file or is locked), but yes, that's essentially it.
 220   >
 221   > PS, the first thing I do to any
 222   > web form is type /etc/passwd and ../../../../etc/passwd into it. ;-) --[[Joey]]