223 lines
11 KiB
Markdown
223 lines
11 KiB
Markdown
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).
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Thanks again to [Joey](http://kitenet.net/~joey) for putting ikiwiki together. I love the program.
|
|
|
|
*[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.
|
|
|
|
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
|
|
|
|
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 <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.
|
|
|
|
> 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]]
|