[pmwiki-devel] One click installation process...

[Crisses]

On Nov 27, 2006, at 6:31 AM, The Editor wrote:

> Technically, I know it would not be hard to pull together a script
> that scanned all the php files in your cookbook, when you browsed to a
> specific page and then dynamically created a list of checkboxes for
> each php file for enabling/disabling them when browsing to a certain
> page. Plus a submit button that saved the info as a simple text file
> in the wiki.d directory. Sitewide the same module could just read the
> data page, and include all listed recipes.  Shoot, that is something I
> could probably do myself.  Another ZAP module?  : )

I don't see what this has to do with ZAP -- and I don't think it  
should require ZAP if you wish to take this on.  Feel free of course  
to re-use portions of the ZAP module code, but I suggest keeping this  
recipe separate.


While interesting, this seriously complicates the wiki software, and  
violates the principles behind PmWiki.


The problem is that even if you create a system, module admins have  
to USE it for it to work.   That makes it not only a huge undertaking  
for you, but for every module admin that wants to be in on the idea.

Another problem is that there are interdependencies.  These modules  
must be loaded in THIS order, or it won't work:

	cookbook/adodb-connect.php
	cookbook/AuthUserDBase.php
	scripts/authuser.php

How would your script handle inter-module dependencies?


If you decide to try this out, for in-page wiki configs I'd suggest a  
look at http://us3.php.net/manual/en/function.parse-ini-file.php and  
consider an in-page PmWiki markup to start & end the ini-file  
formatting.  The nice thing about that is that module authors could  
use that file format with or without it being in a wiki page -- and  
in terms of making basic configuration of PmWiki more user-friendly  
it's not a bad idea in the first place (see below about 3.x rather  
than 2.x changes!).

> If we wanted to make it a bit more complex we could do it like the
> groupattributes pages, so you could also enable/disable recipes for
> specific groups or even specific pages.  No different.  Personally I
> prefer working through the wiki wherever possible, as it makes making
> changes possible from any location, not just my home PC where I have
> my editing software, ftp, etc.

Certainly, if this were to be done, making it configurable via the  
wiki makes it properly flexible for multiple site admins whom are not  
server admins, portable, etc.  It also makes it somewhat more  
vulnerable if someone doesn't password their configuration pages  
properly.  PmWiki comes pretty vulnerable right out of the box.  I'm  
trying to talk to a site admin someplace whose site is vulnerable  
before the spammers find them, but it's been a couple weeks and they  
haven't responded to me :/  They haven't implemented the Blocklist  
for example, and I don't think they have the URLApprovals on either.   
Their clock is ticking.  As a wiki itself, some people I know who  
tried out pre 1.x or 1.x releases left because of the vulnerabilities  
and refusing to use the blocklist feature -- their refusal to protect  
themselves and the persistence of the A______s who spam us caused too  
many issues. :/

> Since you wouldn't be allowing any write access to any php folders,
> what are the risks with this much at least?

If you make the life of module writers/maintainers more difficult,  
you may lose one of the strengths of PmWiki.  This also causes a  
stark division between recipes -- people who get used to using this  
system may avoid the modules that don't support this install/ 
maintenance feature, creating a list of recipes that DO, and a list  
that DON'T support it.

You also may end up with a group of users who expect everything to  
work from inside the wiki and are resistant to things that work  
differently.

> Is there any opposition to doing this much?

I would rather you spend your time coming up with wonderful examples  
for ZAP. :)  Make this into an official PITS proposal, and see  
whether it gets any votes, and maybe it would be considered as a 3.x  
feature?

Anyone trying to install PmWiki who is willing to ask gets tons of  
help and support, happily and willingly.  I have a feeling that even  
if we attempt to make installation and management "easier" that it's  
going to end up with just as much questions and tons of reworking  
documentation, people changing their recipes, etc.  I want to see a  
stable 2.2 release, and maybe get something like this ON the roadmap,  
or under consideration for 3.x or 4.x, but I'm not itching to add  
this level of complexity or recipe overhaul to 2.x.  That's generally  
not the way people expect software development to work, and this  
sounds like major reworking territory that would indicate a big  
number change, not a minor one.

Crisses

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-devel/attachments/20061127/2211c27e/attachment-0001.html