[pmwiki-users] PmWiki work directory, re-revisited

Patrick R. Michaud pmichaud at pobox.com
Fri Feb 2 18:16:10 CST 2007

Back in December I brought up a thread [1] regarding a dedicated 
"work directory" for PmWiki scripts.  There were many useful
suggestions and comments... and then I left for vacation and
was too distracted with holidays.  :-)

[1] http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/36932

So, to restart the topic again, the goal is to have another writable
directory where PmWiki can store temporary working and cache files.
There were two leading approaches -- one is to simply create a
work.d/ directory at the same level as pmwiki.php and wiki.d/ ,
while the other is to have a single "top-level writable directory" 
which then holds wiki.d/, work.d/, and possibly other directories
under it.

There are some nice advantages to having a single top-level
writable directory.  For one, it means never changing 
permissions on the pmwiki/ directory itself -- one simply
sets permissions on this data directory.  It also means that
the top-level writable directory can be part of the distribution,
and clearly labeled as such.  Lastly, it means we need only
one .htaccess file to protect the contents of the writable

The structure would be something like:

      pmwiki.php        # main PmWiki script
      cookbook/         # directory for cookbook scripts
      data.d/           # top-level writable directory
        wiki.d/         # page file storage
        work.d/         # temporary/work files
      docs/             # basic documentation
      local/            # local customizations

There are some downsides of course.  The biggest issue is
dealing with sites that have the old layout -- I'll address
this a bit more in a bit.  For sites that are running with
PHP "safe_mode" enabled, this would mean installing PmWiki
requires manually creating and setting write permissions
for at least two directories (data.d/wiki.d and data.d/work.d/)
instead of just one.  It also means that someone wanting to
relocate the writable tree to a different place would have to
set multiple variables.  (I don't know if this ends up being
more or less work than currently required.)

As far as handling the change for existing sites, we could
take a number of different approaches:

1.  Require system administrators to migrate wiki.d/ into
the data.d/ directory when upgrading to 2.2.0(-beta).  
This is actually not all that onerous -- it simply requires 
moving wiki.d/ into the data.d/ directory, or if that's
not feasible then copying wiki.d/ into the data.d/ directory 
and setting permissions.

2.  Allow existing sites to continue to use wiki.d/ at the
PmWiki level, and use data.d/work.d/ for work files.  The
software would automatically use wiki.d/ at the root if
it exists and there's not a data.d/wiki.d/ directory.

3.  Try to come up with a way to have PmWiki quickly move 
the contents of wiki.d/ into data.d/ (perhaps via a special
action run by the administrator).

4.  Other?

Any thoughts or suggestions regarding these ideas/proposals,
especially with respect to what might be best or easiest
for new and existing sites?



More information about the pmwiki-users mailing list