]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/Moving_Pages.mdwn
Merge commit 'origin/master'
[git.ikiwiki.info.git] / doc / todo / Moving_Pages.mdwn
index 1952840dbd2bf872991117aad55f4b7e3541230b..387e4fb82be1b7388cedaf630ee3047c87d6be2c 100644 (file)
@@ -10,6 +10,8 @@ Thanks again to [Joey](http://kitenet.net/~joey) for putting ikiwiki together.
 
 *[Kyle](http://kitenet.net/~kyle/)=*
 
+> Took a bit too long, but [[done]] now. --[[Joey]]
+
 ----
 
 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,10 +20,203 @@ I see the need for:
 
 * a new type of file to represent a forwarding page
 * a rename tool that can
-* * move the existing page to the new name
-* * optionally drop a forwarding page
-* * optionally rewrite incoming links to the new location
+  * move the existing page to the new name
+  * optionally drop a forwarding page
+  * optionally rewrite incoming links to the new location
+
+Brad
+
+> This could be implemented through the use of an HTTP redirect to the 
+> new page, but this has the downside that people may not know they're being 
+> redirected.
+>
+> This could also be implemented using a combination of raw inline and meta
+> to change the title (add a "redirected from etc." page. This could be done
+> with a plugin. A redirect page would be [[!redirect page="newpage"]].
+> But then if you click "edit" on this redirect page, you won't be able
+> to edit the new page, only the call to redirect.
+> --Ethan
+
+-----
+
+I'm going to try to run through a full analysis and design for moving and
+deleting pages here. I want to make sure all cases are covered. --[[Joey]]
+
+## UI
+
+The UI I envision is to add "Rename" and "Delete" buttons to the file edit
+page. Both next to the Save button, and also at the bottom of the attachment
+management interface.
+
+The attachment(s) to rename or delete would be selected using the check boxes
+and then the button applies to all of them. Deleting multiple attachments
+in one go is fine; renaming multiple attachments in one go is ambiguous,
+and it can just error out if more than one is selected for rename.
+(Alternatively, it could allow moving them all to a different subdirectory.)
+
+The Delete buttons lead to a page to confirm the deletion(s).
+
+The Rename buttons lead to a page with a text edit box for editing the
+page name. The title of the page is edited, not the actual filename.
+
+There will also be a optional comment field, so a commit message can be
+written for the rename/delete.
+
+Note that there's an edge case concerning pages that have a "/" encoded
+as part of their title. There's no way for a title edit box to
+differentiate between that, and a "/" that is instended to refer to a
+subdirectory to move the page to. Consequence is that "/" will always be
+treated literally, as a subdir separator; it will not be possible to use
+this interface to put an encoded "/" in a page's name.
+
+Once a page is renamed, ikiwiki will return to the page edit interface,
+now for the renamed page. Any modifications that the user had made to the
+textarea will be preserved.
+
+Similarly, when an attachment is renamed, or deleted, return to the page
+edit interface (with the attachments displayed).
+
+When a page is deleted, redirect the user to the toplevel index.
+
+Note that this design, particularly the return to the edit interface after
+rename, means that the rename button can *only* be put on the page edit ui.
+It won't be possible to put it on the action bar or somewhere else. (It
+would be possible to code up a different rename button that doesn't do
+that, and use it elsewhere.)
+
+Hmm, unless it saves the edit state and reloads it later, while using a separate
+form. Which seems to solve other problems, so I think is the way to go.
+
+## SubPages
+
+When renaming `foo`, it probably makes sense to also rename
+`foo/Discussion`. Should other SubPages in `foo/` also be renamed? I think
+it's probably simplest to rename all of its SubPages too.
+
+(For values of "simplest" that don't include the pain of dealing with all
+the changed links on subpages.. as well as issues like pagespecs that
+continue to match the old subpages, and cannot reasonably be auto-converted
+to use the new, etc, etc... So still undecided about this.)
+
+When deleting `foo`, I don't think SubPages should be deleted. The
+potential for mistakes and abuse is too large. Deleting Discussion page
+might be a useful exception.
+
+TODO: Currently, subpages are not addressed.
+
+## link fixups
+
+When renaming a page, it's desirable to keep links that point to it
+working. Rather than use redirection pages, I think that all pages that
+link to it should be modified to fix their links.
+
+The rename plugin can add a "rename" hook, which other plugins can use to
+update links &etc. The hook would be passed page content, the old and new
+link names, and would modify the content and return it. At least the link
+plugin should have such a hook.
+
+After calling the "rename" hook, and rendering the wiki, the rename plugin
+can check to see what links remain pointing to the old page. There could
+still be some, for example, CamelCase links probably won't be changed; img
+plugins and others contain logical links to the file, etc. The user can be
+presented with a list of all the pages that still have links to the old
+page, and can manually deal with them.
+
+In some cases, a redirection page will be wanted, to keep long-lived urls
+working. Since the meta plugin supports creating such pages, and since they
+won't always be needed, I think it will be simplest to just leave it up to
+the user to create such a redirection page after renaming a page.
+
+## who can delete/rename what?
+
+The source page must be editable by the user to be deleted/renamed.
+When renaming, the dest page must not already exist, and must be creatable
+by the user, too.
+
+lWhen deleting/renaming attachments, the `allowed_attachments` PageSpec
+is checked too.
+
+## RCS
+
+Three new functions are added to the RCS interface:
+
+* `rcs_remove(file)`
+* `rcs_rename(old, new)`
+* `rcs_commit_staged(message, user, ip)`
+
+See [[rcs_updates_needed_for_rename_and_remove]].
+
+## conflicts
+
+Cases to consider:
 
-(hrm, side note, does markdown not support nested bulleted lists?)
+* Alice clicks "delete" button for a page; Bob makes a modification;
+  Alice confirms deletion. Ideally in this case, Alice should get an error
+  message that there's a conflict.
+  Update: In my current code, alice's deletion will fail if the file was
+  moved or deleted in the meantime; if the file was modified since alice
+  clicked on the delete button, the modifications will be deleted too. I
+  think this is acceptable.
+* Alice opens edit UI for a page; Bob makes a modification; Alice
+  clicks delete button and confirms deletion. Again here, Alice should get
+  a conflict error. Note that this means that the rcstoken should be
+  recorded when the edit UI is first opened, not when the delete button is
+  hit.
+  Update: Again here, there's no conflict, but the delete succeeds. Again,
+  basically acceptible.
+* Alice and Bob both try to delete a page at the same time. It's fine for
+  the second one to get a message that it no longer exists. Or just to
+  silently fail to delete the deleted page..
+  Update: It will display an error to the second one that the page doesn't
+  exist.
+* Alice deletes a page; Bob had edit window open for it, and saves
+  it afterwards. I think that Bob should win in this case; Alice can always
+  notice the page has been added back, and delete it again.
+  Update: Bob wins.
+* Alice clicks "rename" button for a page; Bob makes a modification;
+  Alice confirms rename. This case seems easy, it should just rename the
+  modified page.
+  Update: it does
+* Alice opens edit UI for a page; Bob makes a modification; Alice
+  clicks rename button and confirms rename. Seems same as previous case.
+  Update: check
+* Alice and Bob both try to rename a page at the same time (to probably
+  different names). Or one tries to delete, and the other to rename. 
+  I think it's acceptible for the second one to get an error message that
+  the page no longer exists.
+  Update: check, that happens
+* Alice renames a page; Bob had edit window open for it, and saves
+  it afterwards, under old name. I think it's acceptible for Bob to succeed
+  in saving it under the old name in this case, though not ideal.
+  Update: Behavior is the same as if Alice renamed the page and Bob created
+  a new page with the old name. Seems acceptable, though could be mildly
+  confusing to Bob (or Alice).
+* Alice starts creating a new page. In the meantime, Bob renames a
+  different page to that name. Alice should get an error message when
+  committing; and it should have conflict markers. Ie, this should work the
+  same as if Bob had edited the new page at the same time as Alice did.
+  Update: That should happen. Haven't tested this case yet to make sure.
+* Bob starts renaming a page. In the meantime, Alice creates a new page
+  with the name he's renaming it to. Here Bob should get a error message
+  that he can't rename the page to an existing name. (A conflict resolution
+  edit would also be ok.)
+  Update: Bob gets an error message.
+* Alice renames (or deletes) a page. In the meantime, Bob is uploading an
+  attachment to it, and finishes after the rename finishes. Is it
+  acceptible for the attachment to be saved under the old name?
+  Update: Meh. It's certianly not ideal; if Bob tries to save the page he
+  uploaded the attachment to, he'll get a message about it having been
+  deleted/renamed, and he can try to figure out what to do... :-/
+* I don't know if this is a conflict, but it is an important case to consider;
+  you need to make sure that there are no security holes.  You dont want
+  someone to be able to rename something to <code>/etc/passwd</code>.
+  I think it would be enough that you cannot rename to a location outside
+  of srcdir, you cannot rename to a location that you wouldn't be able
+  to edit because it is locked, and you cannot rename to an existing page.
 
-Brad
\ No newline at end of file
+  > Well, there are a few more cases (like not renaming to a pruned
+  > filename, and not renaming _from_ a file that is not a known source
+  > file or is locked), but yes, that's essentially it.
+  > 
+  > PS, the first thing I do to any
+  > web form is type /etc/passwd and ../../../../etc/passwd into it. ;-) --[[Joey]]