> 1. The main auth call in my terminology is the one in ewiki_page(). If the
> action has not been changed to "create" by that point we will need a work
> around inside the ewiki_auth() system somewhere.
True, so the best fix, was to introduce the "create" action inside [on
top of] ewiki_auth() then, so only the ["auth_perm"] plugins would
notice the difference between "edit" and "create".
I'd still like to keep that "create" separate from the core, so we
didn't need to duplicate/copy action plugin ["edit"] into ["create"]
with little benefit. All edit/ plugins should still simply create
a page, when it does not exist, like fopen() handles this
automatically (and the caller haven't to care).
> As for modifying the _auth call, please explain how you would do this to
> avoid stumbling over the fact that you may or may not be getting data in
> $data.
The problem is obviously only for all the funny look-ahead _auth()
calls. My simple answer to this was, that one just must accept that
you cannot 100% accurately tell about page accessibility until you
try to access it (with the full and latest $data loaded).
And the "edit"/"create" switching most only would occour for ewiki_auth()
lookahead calls, that actually were called with the second parameter
being "edit". This only happens at one place as far as I know (the
control-line), and we have the full $data available for that case.
>
> The main benefits from adding a create action IMOWRCH are exactly from
> polluting the global scope with it. Some possible uses:
>
> * Making your aedit_template plugin appear and run only on page creation.
> * Allowing my "edit_append" manage plugins (in perm_liveuser) to give the
> original author extra abilities to setup the rights for a page when they
> create a page.
> * Allowing a different editor to be used for creation i.e. choice of upload
> a file, copy a page, start fresh, create a forum...
> * Flagging page creation in the logs.
> * You may want... search as described below.
Making the if_page_already_exists() check once and renaming the global
$action var obviously had a lot of advantages, but there are of course
cons too:
- it was simply more complex then
- there then always needed to be a double-check where currently =="edit"
is tested
(- page plugins may get confused, because they always were to be
"create"d even if they actually handled some data "edit"ing
internally; what again changed with ghost/cache pages)
- more unintuitive and unreliable to not have automatic page creation
- code duplication, and "create" plugins eventually harmful to existing
pages (there then had to be a very strong check against page existence)
- a new "create" action should then be visible to the outside
(?id=create/NewPage), but appears to not give any benefits(?)
- duplication of CSS selectors:
.wiki.edit.ThisPage, .wiki.create.ThisPage { ... }
(though this may be an advantage, if users really cared about "edit"
vs "create" actions)
So I'm very undecided about introduction of a "create" action, and
it still looks unnecessary to me to introduce a purely internal action
name here (except for the _auth stuff). Meanwhile we could however use
a handler/page_init plugin to check the implications (for later hardwiring
of a "create" action).
mario