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

[The Editor]

See notes to Crisses and Patrick below:

CRISSES:

On 11/27/06, Crisses <crisses at kinhost.org> wrote:
> 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.

I was just thinking it would be easy to do in ZAP.  Just a slight
change to the logging function which I need to do anyway for people
wanting to use it to modify .ht files.  And then a little function for
doing the includes...

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

Actually it should simplify installation a bit.  It makes nothing
harder, and would makes some recipes simpler.

> 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.

If we do it as I've suggested, a recipe author wouldn't have to make
any changes. The script just scans the files in the cookbook, and
enables any you want enabled. That's all most recipes require anyway.
Actually, it might simplify controlling which groups/pages a recipe
can function in by storing all that info in one file...

> 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?

Ah yes, good point.  I suppose a solution could be found, but then it
stops being a simple solution...  And becomes a complex solution.
There's also the question of certain *scripts* one might want to
enable/disable this way--which is a different directory, and only
specific scripts that function this way.  But that's easy enough to
incorporate.

> 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!).

Nice! Very helpful.  But I'm leaning against tackling config stuff, at
least at first... It would be useful for recipes with several
variables that need to be set.

> 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.

As noted above, recipe writers wouldn't have to do anything.  And as
D'Faure said, recipes should be written so they install already with
default values set.  And those who want config pages for their recipes
can do so themselves without expecting the installer to set them up
for them.

> 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.

Yes, but to be honest, that's kind of a goal of zap.  I've been able
to delete all my config files except the main one.  And I have far
greater power now.  I'm the voice of the one who WANTS as much as can
be done reasonably, via the web interface.

> 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?

I'll do the PITS entry, and perhaps give it a try in ZAP itself.  ZAP
already has 4 modules and I envision at least two more in time.  I
could experiment with a proof of concept ZAPconfig module which by
itself installs and controls the other ZAP modules as and where
needed.  Getting a demo to work with ZAP may perhaps make it more
attractive to other users.  Plus it would be fun to try.  As if I had
nothing else to do.

Also, thanks for the encouragement to do more ZAP stuff.  That's still
priority. And I'm still taking requests for snippets!

> 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.

Depends on if we can make it work simply and securely... I'm thinking
no changes to recipes or documentation needed unless perhaps a note
saying (auto installable or not).

> 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.

Oh I'm in no hurry.  Actually, I was just thinking out loud to see
what others might think.  And to be an advocate from the guy who
turned away from PmWiki.  As usual there are huge gaps in my knowledge
of programming, some have been filled in thanks to the list's help..


PATRICK:

On 11/27/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> Any module-management system has to be simple for
> both site administrators and module writers to use, otherwise we
> lose a big strength.

Agreed.  I'd like to make it work with most recipes as they are, even
if our auto install script is quite limited.

> Plus, consider all of the recipes and configuration options that
> exist in the cookbook that *don't* involve downloading a script
> of some sort, or that are configuring more than a simple "on-off"
> item.  For example, how would one use a web-based configuration
> interface to define custom markup rules, or to set new values of
> $SearchPatterns?

No intention of dealing with them.  I thought a long time ago it would
be better to separate the cookbook into downloadable modules and
configuration hacks.  Still lean that way, but regardless, the
auto-install feature would only be for downloadable scripts.

Of course, Crisses idea of making markups definable was totally
awesome.  I can envision extending an installer to have one page for
favorite markups (perhaps controlling groups/pages where enabled), and
another for favorite recipes. Of course, most markups could be put
into a php file easy enough and enabled that way...

> I totally agree here -- I fear that by having two or more methods
> of site configuration we just increase
>  - the number of questions arising from differences between the
>    two methods,
>  - problems and issues arising from recipes not supporting module
>    management properly, or from unexpected interactions between
>    modules,
>  - requests to add specialized configuration options to the web-based
>    configuration tool
>      - I can easily see that this could eventually become a form
>        or sequence of forms with literally hundreds of options
>        (look at the number of Cookbook recipes, for a start)
>      - Then it's a problem of "where do I find the option to
>        configure my site to do XYZ"?
>  - new administrators being led down dead-ends trying to achieve
>    results with the web-configurator that can only be done using
>    a config.php modification.

Well, setting up configuration options was only an after-thought and
should probably be best handled by the recipe writer if there are
configuration settings needed, not some single module installer.  As
D'Faure suggested. At the very best we could have a default link to a
config and/or help page if those pages are defined in the recipe.
Nothing if they are not defined.  Again, the idea is to make recipe's
installable as they are--just put them in the default directory. And
click enable.

As far as multitudes of questions, it should be nothing more than a
recipe stating it cannot be installed this way, and to use the normal
install method (the only problem I see being dependencies).  Or to do
the reverse, indicate which recipes can be auto installed, and require
a specific variable to be set before the installer will enable it.
This does however require recipe writers to add a short line to their
code....

I'll start with ZAP and see if I can't get it to work.  Proof of
concept...  Thanks for the input!

Cheers,
Caveman