As documented in write, the current
renamepage hook is
heavily oriented towards updating links in pages' content: it is run
once per page linking to the renamed page.
That's fine, but it can't be used to trigger more general actions on page rename. E.g. it won't be run at all if the page being renamed is an orphan one.
This is a real issue for thedevelopment: what I'm about to achieve is:
- when a master page is renamed, the plugin takes notice of it (using
renamehook), and later renames the translation pages accordingly (in the
- when a master page is deleted, the plugin deletes its translations
With the current
renamepage hook behavior, combining these two goals
has an annoying drawback: a plugin can't notice an orphan master page
has been renamed, so instead of renaming (and preserving) its
translations, it considers the oldpage as deleted, and deletes its
translations. Game over.
It may seem like a corner case, but I want to be very careful when
deleting files automatically in
srcdir, which is not always under
As a sad workaround, I can still disable any deletion in
when it is not under version control. But I think ikiwiki deserves
renamepage hook that would be run once per rename
My proposal is thus:
- keep the documented
renamepagehook as it is
- use something inspired by the trick
hookis passed an optional "global" parameter, set to a true value, the declared
renamepagehook is run once per rename operation, and is passed named parameters:
I'm of course volunteering to implement this, or anything related that would solve my problem. Hmmm? --intrigeri
I think it would be better to have a different hook that is called for renames, since the two hook actions are very different (unlike the preprocess hook, which does a very similar thing in scan mode).
Just calling it
renameseems like a reasonable name, by analogy with the
It might make sense to rename
renamelinkto make it clearer what it does. (I'm not very worried about this breaking things, at this point.) --Joey
pobranch, I renamed
renamelink, and created a
renamehook that is passed a reference to
As Joey highlights it on, it's too late to merge such a change, as the 3.x plugin API is released and should not be broken. I will thus keep the existing
renamepageas it is, and call
renamethe global hook I need. --intrigeri
I think I see a problem in the rename hook. The hook is called before the plugin adds any subpages to the set of pages to rename. So, if the user choses to rename subpages, po will not notice they are moving, and will not move their po files.
Perhaps the hooks should be moved to come after subpages are added. This would, though, mean that if the hook somehow decides to add entirely other pages to the list, their subpages would not be automatically added.
I also have some qualms about the design of the hook. In particular, passing the mutable array reference probably makes it impossible to use from external plugins. Instead it could return any additional rename hashes it wants to add. Or, if the ability to modify existing hashes is desired, it could return the full set of hashes.
I fixed the last part, i.e. a rename hook function now returns the full set of hashes. As I also converted it to take named parameters, such a function still is passed a reference to the original array, though, because one can't build a hash containing an array of hashes as a value, without passing this array as a reference.
I'm not entirely sure about your first concern. Calling the hook before or after the subpages addition both have their own problems.
What about running the hook before and after the subpages addition, with an additional
whennamed parameter, so that a given hook function can choose to act only before or after, or both?
Have you thought about making the hook be run once per file that is selected to be renamed? This would even handle the case where two plugins use the hook; plugin A would see when plugin B adds a new file to be renamed. And the subpage renaming stuff could probably be moved into the rename hook too. --Joey
I've implemented this nice solution in my po branch, please review. I'm slowly coming back to do the last bits needed to get my po and meta branch merged. --intrigeri