[pmwiki-users] PmWiki work directory, re-revisited
Patrick R. Michaud
pmichaud at pobox.com
Sun Feb 4 11:26:23 CST 2007
On Sun, Feb 04, 2007 at 12:09:00PM -0500, The Editor wrote:
> On 2/4/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> >What we have now is essentially:
> >
> > "pmwiki-core"/
> > pmwiki.php
> > scripts/
> > wikilib.d/
> > cookbook/
> > local/
> > farmconfig.php
> > pub/
> > guiedit/
> > skins/
> >
> > "field"/
> > index.php
> > writable/
> > wiki.d/
> > temp/
> > uploads/
> > local/ # optional per-field config
> > cookbook/ # optional per-field cookbook
> > pub/ # optional per-field css/skins/other
> >
> >To me, this looks fairly close to what you've written above --
> >where are the major differences?
>
> Actually nothing significant. This addresses my needs just fine.
> Looks great! Of course, shouldn't uploads be writable?
Yes, uploads are writable, but unlike wiki.d/ and temp/ the
files in uploads/ need to be directly available to the webserver.
And we also probably don't want "writable" to be appearing in
the upload urls, as in
.../pmwiki/writable/uploads/Group/somefile.zip
There's a strong tendency to want to make _everything_ fit into
neat inviolate categories, such as "writable versus unwritable",
"field versus farm", "core versus custom", "directly accessible
versus private", etc.
But the truth is that there's no one dimension that can neatly
cover everything. Here's a basic overview:
pmwiki.php farm public read-only core
farmconfig.php farm private read-only local
scripts/ farm private read-only core
wikilib.d/ farm [1] read-only core
local/ field private read-only local
wiki.d/ field private read-write local
temp.d/ field private read-write local
uploads/ field public read-write local
pub/guiedit farm public read-only core
pub/css field public read-only local
pub/skins [2] public read-only local
cookbook/ [2] private read-only local
[1] It doesn't matter if wikilib.d/ is public or private.
[2] Skins and cookbook recipes can be per-field or farm-wide.
Anything listed "public" needs to have a reasonable url
and an easy way for PmWiki to figure out the correct url
or for an administrator to set it. (In general this is
quite difficult already)
Anything listed "private" ought to be protected from direct
webserver access somehow.
As you can see, we have things that are read-write and public
(uploads/) and other things that are read-write and private
(wiki.d/, temp.d/). Because urls are exposed to visitors,
and because mapping urls to filesystem names is a source
of great confusion to new administrators, I think the
"public versus private" distinction has to trump whether
something is writable by the webserver.
Pm
More information about the pmwiki-users
mailing list