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

[marc]

The Editor said...
> On 11/26/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> > On Sun, Nov 26, 2006 at 11:52:43AM -0500, The Editor wrote:
> > > Someone just posted a suggestion for a one click module installation
> > > feature.  After a bit of thought, it occurred to me something like
> > > this might be reasonably doable...  Thought I would post some ideas
> > > and see if there was any feedback.
> >
> > For security reasons, it's almost a non-starter.  Consider:

Just wanted to chime in and agree with Pm on this idea. (Not that he 
needs my support ;-)) 

> > > First, for a one click module installation feature, we'd need to 1)
> > > have a way to automatically download the recipe (so we don't have to
> > > include them all automatically with the basic download).
> >
> > Ick.  This means that the directory containing recipes (i.e.,
> > executable code) has to be writable by the webserver.  Bad.

Yup, and where is that directory? I use more than one, and I'm sure I'm 
not alone.

Then, say, the  auto-install fiddles with config files; who's to say 
which file should be amended? For example, I use farmlocal.css, so that 
local.css is for the main wiki only. Any auto-install would need to 
figure out all these things, then ask sensible questions about where it 
should put things. Ick!

> > Personally, I think the automatic download of scripts is in general
> > a bad idea -- indeed, this is why PmWiki doesn't have something
> > like an "?action=upgrade" feature to automatically upgrade the PmWiki
> > software.

<shudder>
 
> > So, at best we could provide a web interface for configuring
> > recipes, but no matter how good the interface is, we'll always be
> > limited to only handling a subset of the available options and
> > features.  There would always be some things that could only
> > be done directly in .php configuration files.  And just as a person
> > with two clocks is never certain of the time, an admin with two or
> > more configuration interfaces has to worry about how the settings
> > in one interface are interacting with the settings of the other.
> >
> > (PITS #00394 has some similar discussion on this topic.)

I think that anyone who has managed a couple of 'traditional' CMSs would 
know the pain of this. Once more, thanks to the evolution of version 
control tools, life is easier, but when the host doesn't support such 
tools, then the problem is still there.

> When I was doing Drupal, it was a nightmare getting things installed,
> upgraded, etc., mostly because it was database driven.

Odd, I've never found that the db gets in the way when I use Drupal.

> Many modules I never could get to work.

Drupal is certainly not as plug and play as it first appears. I think 
that you need as much product-specific knowledge to use it as you do 
with PmWiki.

> However, it did have a nice module
> *interface*.  After you downloaded a module and unzipped it to your
> module folder (I forget the details), you had to go to a certain web
> page (like Site.Modules) to enable it.  This page (I presume) scanned
> the modules folder, listed all the possible modules, and put
> checkboxes beside them for enabling/disabling.  Plus, if there were
> configuration options, there was something like a link to a setup page
> where those options could be set.  And perhaps help pages.

I find this aspect of Drupal seriously flawed. The interface must be 
learned - it is no way intuitive - because it replies heavily on the 
admin understanding the 'structure' of Drupal. And all the flicking to 
and fro between web-pages can drive a passive individual nuts.

I like Drupal a lot - at least, the ideas behind it - but I would much 
prefer to admin it via config files - or a much better though out 
interface - than what it currently has.
 
> What about an approach like this?  The user would still download the
> recipe and upload to his server manually.  Then there would have to be
> some kind of writable modules list (perhaps like a .htconfig file or
> something) that simply listed enabled modules--which PmWiki would read
> and do the includes for.  Any configuration variables for the recipe
> could somehow, perhaps, be stored in this file, or left to the config
> files as usual.  I actually suspect most recipes only require setting
> config variables when you are changing from default behavior.

The way I do things is to split (farm)config.php into three files - the 
regular stuff, recipes and markup; so I have farmconfig.php, 
farmrecipes.php and farmmarkup.php - I then add extra recipes via each 
field's local/config.php. It would be fairly simple to build an 
interface that allowed recipes to activated/deactivated in this, or 
similar, setup. Not that I think this is a good idea, however.

> Anyway, this way no php pages/folders would be writable and we could
> make enabling most recipes possible without a user having to get their
> hands dirty.  And we might even be able make configuring recipes
> possible directly from the wiki.

You could do this via text vars. Again, this is not a recommendation ;-)

> Recipes that didn't install this way
> could of course continue to be installed as usual.
  
> > P.S.:  Since writing PITS #00394 I have toyed with the idea of
> > coming up with a form-based configuration system for some of
> > the more common PmWiki and recipe settings -- i.e., an admin
> > would simply do
> >
> >    include_once('cookbook/formconfig.php');
> >
> > and then use the form for lots of basic configuration settings,
> > which could then be augmented or overridden by other statements
> > in the config.php file.  But things still get complex when we
> > start thinking about per-group or per-page customizations --
> > where do those get stored?  Ultimately I get the feeling that we're
> > just increasing the complexity rather than reducing complexity
> > or simplifying it.

I agree. It's an appealing idea, but, based on experience from Joomla, 
Drupal, Typo3, et al, I've yet to see such an interface that makes 
things easier in the long run.
 
> If this could be done for PmWiki as a whole (a nice idea), something
> similar could be done for individual recipes, I presume.  I'm not sure
> what the answer is to getting customizations tied to local groups or
> pages.  But my inclination at this point is, getting recipe
> configuration variables to work could come down the road.  Right now,
> getting them to install a bit easier might be a nice first step.

Perhaps a better approach might be to first identify and quantify the 
problems, rather than defining a solution.

-- 
Best,
Marc