[pmwiki-users] Easier configuration (was: Pm's whereabouts, 2.2 status)

[Patrick R. Michaud]

On Mon, Nov 12, 2007 at 04:22:21AM -0500, Mike Shanley wrote:
> All of the people on my farm use PmWiki for their own sites. The most an 
> outsider can do is make comments. Most of what they've asked me for and 
> I've looked for are easier ways to configure EVERYTHING!
> 
> Obviously, there is a limit to how far this can go and even IF it should 
> go that far with PmWiki (which very triumphantly caters to programmers 
> in a lot of ways).
> 
> Maybe there could be an intermediate level of customization allowed 
> within Site.Preferences (which to me is currently useless). Moving it to 
> SiteAdmin also makes a lot of sense, btw. If this page's definition 
> lists were allowed to define variables PRE-config.php (for safety, so 
> you could still hard code the important stuff), it would really do a 
> lot. Allowing people to, as an extended option, to replace config.php 
> would be marvelous.

This has been suggested in the past, but generally I've rejected it
as being too unsafe and potentially difficult to maintain.
There was a longish discussion about this in a PITS entry, but
for some reason I'm unable to find it at the moment.  So, I'll
recap my previous arguments here, and then also indicate that
I'm reconsidering the whole thing.  :-)

If we simply allow a wiki page to have the same format as the
config.php file -- i.e., executable PHP code -- then I fear we
run a huge security risk, because anyone who gained access to
the page would be able to execute arbitrary PHP scripts on the
server.  That would not be a good thing.

So, that means that any wiki-based configuration page would need
to have some form of special processing in order to keep it safe
(and friendly to administrators), and that adds a fair amount
of programming and processing overhead that in the past I've 
preferred to avoid altogether.  Perhaps if we're just setting
limited sets of variables we're in good shape, but an administrator
will probably also want to include various recipes, which
means the tool (or the administrator) needs to be aware of
the order in which recipes should be loaded.

There's also the issue that troubleshooting may become a bit more
complex because we have to be aware of any interactions between
the wiki-based configuration tool and whatever may have been
placed in the true local/config.php file, as well as any per-group
or per-page customizations.  In other words, since I doubt we can 
get _all_ of the configuration into the wiki-based tool, we (and
admins) will generally have to deal with hybrid configurations of
some sort, which may make things more complicated in the long run.

So, for the reasons I've just given, I've generally been against
a wiki-based configuration tool for PmWiki, although I've certainly
invited others to prototype one.

Yet with all of the above, as I've been thinking the last couple
of days about creating some video tutorials for new administrators,
I was suddenly struck by how cumbersome the edit-the-config.php file
approach can be for some.  I've always done my configuration directly
on the server, but for people who don't edit files on the server
I see it would be a bit of a pain.  So, with that I'm a bit more 
open to the idea of a web-based configuration utility for PmWiki, 
but only just a little bit.  My concerns above still exist.

> The same thing would apply to the template and the CSS file. Adding two 
> more /optional /SiteAdmin pages that were always cropped and cached as 
> css and html files would not add any extra time to serving pages, but 
> would go above and beyond in making a customizable wiki.

Most of the skin templates are now being bundled with skin.php
files, and for that I again end up with the concerns about having
PHP code embedded in wiki pages.  As for CSS files -- a cookbook
solution for this already exists somewhat -- see 
http://www.pmwiki.org/wiki/Cookbook/CSSInWikiPages .

But ultimately I don't think that PmWiki is intended to fill the
niche of "file editor" -- there are already plenty of web-based
tools that provide these sorts of capabilities a lot more securely
and robustly than PmWiki is likely to do.

> These things could not really be done with recipes because they happen 
> outside the area of influence OF recipes. But at the same time, they 
> would be very easy to implement. 

I disagree with both of these points -- a recipe can generally do
anything the core can do, and given the security and maintenance
considerations (as well as the fact that nobody has taken me up
on the invitation to create one), I don't think they'd be 
"very easy to implement".

> As for them being part of the core, my 
> argument stems from the fact the tasks they address are directly related 
> to every single user of PmWiki.

Yes, but long experience has told me that the audience of PmWiki
administrators is actually segmented into about fix or six
different groups, each of which tending to have different needs
and expectations from the others.  

However, as I mentioned above, at present I *am* a bit more
open to the idea than I have been in the past, so if there are
any cool ideas about how to overcome the security issues without
too much work, now would be an excellent time to bring them forward.

> And thanks to Patrick SO MUCH for making SUCH a great wiki engine!

You're welcome, and thanks for the excellent suggestions!  :-)

Pm