Thanks to you both for your replies!
In fact I use my own auth plugin (https://www.dokuwiki.org/auth:cafu_phpbb3
) which does no cleaning of the username at all: I was not aware of any cleaning requirements when I wrote the plugin. In fact, it seems to me like upper-case letters in usernames (as opposed to IDs) are possible and allowed in DokuWiki?
As I did not create the .../wiki/data/media/epub/Carsten[/m] directory myself, I guess that the epub plugin took the upper-case username from the auth plugin, and used it to create the directory [m].../wiki/data/media/epub/Carsten
So I believe that Michitux is right, in that the epub plugin should call cleanID(). :-D ;-)
Myron, I understand how using the username as a component in the path helps with reducing collisions, but I was wondering if the normal page locking of DokuWiki could be used for this purpose instead?
Please let me explain this:
Recently I was asked by a user of my DokuWiki instance if there was an offline edition of the Wiki contents for download.
Of course there wasn't, and so I searched and eventually found your epub plugin, which I value very much.
When I read the plugin Intro page, I understood how I can define a book via a book definition page in the epub
namespace, and that ACL rights are co-used to control who can trigger the actual built of a book.
But honestly, the fact that every user is allowed to create every book at every time seems very confusing to me.
Please don't get me wrong, this is not meant as criticism (in fact I'm very grateful for the effort you've invested into the plugin!), but what I would have "expected" the plugin to do is something much simpler:
When the epub:mybook
definition page is saved (requiring as usual the proper ACL rights), show as a result on the rendered page a simple "Download" button. Any user who has read access to that page would be able to click the "Download" button and be provided with the generated epub file.
Of course, the "Download" button would not re-generate the .epub[/m] file from scratch every time it is clicked, but return a pre-made copy (this is what the "Start" button currently does). The cached copy could automatically be created (only) when the [m]epub:mybook
definition page is saved, co-using the regular DokuWiki page lock for its purposes. (This would get rid of the needs for collision prevention through timestamps or hashes in the filename.)
Alternatively, more comfortably but also more complicated, the cached copy could automatically be re-made whenever the epub:mybook[/m] definition page has changed, or any of the referenced content pages has changed. I don't know if such re-generations could re-use the DokuWiki page lock as well, as we're not at "Save page" time in this case. (At least not of the [m]epub:mybook
definition page, but of a (possibly) referenced content page...)
In summary, with either of these methods, users would only ever see a "Download" button that always and automatically returns (the latest edition of) the book.
What do you think? ;-)