diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/plugins/remove.mdwn | 7 | ||||
| -rw-r--r-- | doc/plugins/rename.mdwn | 7 | ||||
| -rw-r--r-- | doc/plugins/write.mdwn | 3 | ||||
| -rw-r--r-- | doc/todo/Moving_Pages.mdwn | 59 |
4 files changed, 61 insertions, 15 deletions
diff --git a/doc/plugins/remove.mdwn b/doc/plugins/remove.mdwn new file mode 100644 index 000000000..be382e1d8 --- /dev/null +++ b/doc/plugins/remove.mdwn @@ -0,0 +1,7 @@ +[[!template id=plugin name=remove core=0 author="[[Joey]]"]] +[[!tag type/useful]] + +This plugin allows pages or other files to be removed using the web +interface. + +Users can only remove things that they are allowed to edit or upload. diff --git a/doc/plugins/rename.mdwn b/doc/plugins/rename.mdwn new file mode 100644 index 000000000..f5433ca65 --- /dev/null +++ b/doc/plugins/rename.mdwn @@ -0,0 +1,7 @@ +[[!template id=plugin name=rename core=0 author="[[Joey]]"]] +[[!tag type/useful]] + +This plugin allows pages or other files to be renamed using the web +interface. + +Users can only rename things that they are allowed to edit or upload. diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn index 22bd5d114..12bd33662 100644 --- a/doc/plugins/write.mdwn +++ b/doc/plugins/write.mdwn @@ -635,4 +635,5 @@ when imported, populate `$IkiWiki::Setup::raw_setup` with a reference to a hash containing all the config items. By the way, to parse a ikiwiki setup file, a program just needs to -do something like `use IkiWiki::Setup; my %setup=IkiWiki::Setup::load($filename)` +do something like: +`use IkiWiki::Setup; my %setup=IkiWiki::Setup::load($filename)` diff --git a/doc/todo/Moving_Pages.mdwn b/doc/todo/Moving_Pages.mdwn index 7485f06fd..cd19d6b98 100644 --- a/doc/todo/Moving_Pages.mdwn +++ b/doc/todo/Moving_Pages.mdwn @@ -370,8 +370,14 @@ 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. +potential for mistakes and abuse is too large. Deleting Discussion page +might be a useful exception. ## link fixups @@ -379,6 +385,18 @@ 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 @@ -390,21 +408,16 @@ 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. -When deleting/renaming attachments, the `allowed_attachments` PageSpec +lWhen deleting/renaming attachments, the `allowed_attachments` PageSpec is checked too. ## RCS -Two new optional functions are added to the RCS interface: +Three new functions are added to the RCS interface: -* `rcs_delete(file, message, rcstoken, user, ipaddr)` -* `rcs_rename(old, new, message, rcstoken, user, ipaddr)` - -The page move/rename code will check if these are not available, and error -out. - -Similar to `rcs_commit` both of these take a rcstoken, which is generated -by an earlier `rcs_prepedit`. +* `rcs_remove(file)` +* `rcs_rename(old, new)` +* `rcs_commit_staged(message, user, ip)` ## conflicts @@ -413,37 +426,55 @@ Cases that have to be dealt with: * 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. -* 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: 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? |