It seems to me that something might well be done to better handle binary page better. Notions include:

• handling all flag checks in ewiki_auth
• attempt binary action as prmeptive to handlers
• temporarily use ewiki_auth mangling to remove $data*'content' on binary pages
• eventually (V1.2?) making all pre-action plugins binary safe
• calling binary actions (not download and upload) in line with non binary actions.

milky: What about not handling binary entries inside of ewiki_page(), but instead letting a totally distinct ewiki_binary_handler() do all stuff (which then may eventually chain back to ordinary action plugins). Also important to note here, is that ewiki's capablilites to handle binary data is unique across most CMS and certainly all Wikis - other systems only provide a world-writable upload/ dir or less -- so let's not further complicate things in ewiki_page().

Andy: Do you mean as a handler plugin inside ewiki_page? That would work if we ensured that it was the first handler.

Andy: I'll check the source when I get into work but I think the changes to ewiki_page() would be minimal the way I've layed it out. Changes to plugins would seem to be limited to init and handler plugins. We could handle the binary actions before handlers even but handlers seem to me to be an advanced sort of plugin that we can count on users to be banary-smart about, though we could add a $binary parameter to the handler call for them.

Andy: What say you to moving some of the flag checks into ewiki_auth()?

Andy: I grepped out all the the plugin registrations to make a ListOfPlugins and it looks like there are more handlers than I thought so maybe we could handle binary actions between the main auth call and the handlers?

more implementation notes

milky: We should try to keep the binary and page distinction, expressed in the separation of ewiki_page() and ewiki_binary(). Your current efforts, Andy, however seem to intermix both heavily.

Even if ewiki can handle binary content as part of its database (unlike other wannabe-CMS which only provide a world-writeable incoming/ subdir), it was not intended to do this that heavily. And there will arise some problems if ProtectedMode is introduced into that area.

It was in fact possible to disable the ewiki_binary() and catch "?id=internal://" requests via the new ["binary_handler"][0], but this also means code duplication and workarounds in the end.

Andy: I absolutely need protected mode on binaries even if it means that I have to write a fully separate system to handle it. I saw your note about the http standard not supporting authentication on binaries and will try to keep this code compatible with that, but we have said in the past that not all plugins are inter-compatible and this may be a case of that.