[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