X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/38e19d5d9a0676f6f4f86d599dd89640f24e94dc..ea753782b222bf4ba2fb4683b6363afdd9055b64:/doc/todo/Moving_Pages.mdwn diff --git a/doc/todo/Moving_Pages.mdwn b/doc/todo/Moving_Pages.mdwn index baf840af6..387e4fb82 100644 --- a/doc/todo/Moving_Pages.mdwn +++ b/doc/todo/Moving_Pages.mdwn @@ -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. @@ -22,4 +24,199 @@ I see the need for: * optionally drop a forwarding page * optionally rewrite incoming links to the new location -Brad \ No newline at end of file +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: + +* 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 /etc/passwd. + 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. + + > 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]]