[pmwiki-users] Pre-announcing 2.2.0 non-beta release
john.rankin at affinity.co.nz
Tue Jan 20 18:15:36 CST 2009
>Date: Tue, 20 Jan 2009 10:56:00 +0100
>From: Oliver Betz <list_ob at gmx.net>
>Subject: Re: [pmwiki-users] Pre-announcing 2.2.0 non-beta release
>John Rankin wrote:
>>>>> one thing is probably very important: have some way to install major
>>>>> cookbooks from a drop down list or checkbox
>>>>This isn't likely to happen (the drop-down list or checkbox part),
>>>>because we don't want the webserver to have write permission to
>>>>the cookbook/ directory.
>>>I agree with this. I'm basically happy with the current method of
>>A small step could be to distinguish installation from activation.
>>The installer could continue to install everything as before,
>I don't understand "everything as before".
Sorry, I meant the status quo installation process -- i.e. download
a compressed archive and manually copy everything to the destination.
Just as several items in scripts/ are disabled by default, so third
party scripts would be installed, but turned off.
>>activation could be through a PmWiki page in SiteAdmin. When
>What is the problem to access and edit config.php by (S)FTP, SCP etc.?
>It's only a matter of using the right tools. Using Windows, WinSCP and
>Beyond Compare work _very_ well. PsPad, UltraEdit will also do the
>So what you call activation could be simply removing a comment from a
>line in config.php - if config.php already contained a list of "known
PmWiki is progressively moving cpability into wiki pages (e.g. the page
edit form, pagelist formats) and this is just an extension of that logic.
See Pm's comment on the limitations of this approach and Peter's very
interesting response. Don't get me wrong, there is nothing wrong with
editing a config file, just as there is nothing wrong (on a different
scale of complexity) with defining edit form layout in a config file.
>But this still doesn't address the problem of "reliability".
>If PM included calls to third party extensions in the PmWiki
>distribution, this is a kind of recommendation and implies a certain
>level of responsibility for flawless function.
>Therefore the first (before adding "automatic" installation) step
>should be a quality control or rating of PmWiki extensions. This would
>be more beneficial for the unexperienced user than automatic
I agree almost 100% (and my earlier post raised this very issue).
Personally, I'm not a big fan of rating systems as a method of
quality control, for reasons that others have given. I have had
the benefit of some wonderful quality control from Christian
Ridderström and Peter Bowers (among others) on a number of recipes
and the recipes are much better as a result. So while it's harder,
I would prefer a system based on a lightweight and transparent
quality control process. Ratings would be good for other reasons,
of course, but are not necessarily a mark of quality.
>I'm much more concerned (and other should be also) about safety than
>comfort: Will a certain recipe cause annoyances, unavailability, data
>loss, or even open the door for a Black Hat?
>The PmWiki core seems to be _very_ safe and trustworthy - it's widely
>used but I don't know of severe security issues (no noticeable at all
>in the last two years). But I don't know how secure the third party
T 64 4 495 3737
F 64 4 473 7991
john.rankin at affinity.co.nz
More information about the pmwiki-users