[pmwiki-users] Hiearchical Groups Proposal.

[Patrick R. Michaud]

On Wed, Oct 18, 2006 at 06:29:47PM +0200, Joachim Durchholz wrote:
> > [...] Displaying a page nearly always involves processing its
> > metadata as well (if only to check permissions), so we aren't really
> > avoiding the need to do some file parsing somewhere.
> 
> Right, I didn't see that.
> 
> > Also, for security reasons we have to encode/decode the contents of
> > the markup text anyway,
> 
> Why that?

Suppose we have a page named "Group.PHP".  Because the file appears
to have a .php extension, if the file is accessible directly via
the webserver then any <?php ... ?> sequences that appear in the file
can be treated as PHP code to be executed.

Adding an extension to the filename doesn't always help -- i.e., some 
webservers are configured with multiviews enabled such that if ".php"
appears anywhere in the filename, the contents are passed through
the PHP processor.

And, of course, it's not just PHP that can pose a problem, there can
also be difficulties with .asp, .shtml, etc.

PmWiki's PageStore circumvents this problem by encoding all '<'
characters as '%3a'.  This works out quite nicely, since we also
want a way to represent newlines in data values, we can just use
%0a, and then a simple (and presumably somewhat fast) call to
urldecode() is all that is needed to decode the values.

> It may be best to keep just the data that's needed for a page view in 
> one file, and everything else in another one.

PmWiki pretty much does this already.  Everything that is needed for
a typical pageview is at the beginning of the file, and all of the 
rest of the details are placed at the end.  Thus PmWiki simply
stops reading and parsing the file when it has all of the data it needs.

> Latencies can be due to unindexed directories, I'd say.
> If that's the case, you should probably move to a server that uses a 
> better file systen ;-)

Having spent so much time and energy (and migration headaches) over
the past two years in moving through successive hosting providers,
now that I've found one that I really like I'm not predisposed to
move again over this particular issue.  There still quite a few
options available to me to try first before making that drastic
a change.  (In particular, it would probably help a lot if PmWiki
stored its pages in per-group directories, instead of the largish
wiki.d/ it has now.)

Pm