[development] RFC: letting modules phone home to check for new releases

Bèr Kessels ber at webschuur.com
Wed Nov 22 10:41:13 UTC 2006


And again...

Op woensdag 22 november 2006 03:56, schreef Darren Oh:
> Think about it. This is the process recommended in the manual:
>
> 1. Select the module you want to install or upgrade.
> 2. Download the module to your computer.
> 3. Unpack the module.
> 4. Start your FTP client.
> 5. Connect to your site.
> 6. Switch to the correct directory (whatever that is).
> 7. Upload the module directory to your site.
> 8. Enable the module (if installing) or run update.php (if upgrading).
>
> Steps 2 through 8 would become one step. Automatic installation or  
> automatic upgrade seemed clear enough to me. What would you call it

... we forget that a great lot of Drupas sites are, could be, or should be 
installed with TOOLS. 

As in: bryghts own tools, capistrano, ssh scripts, ispconfig installers, plesk 
API implementations etceteras. 

In that case the *properly designed* install and upgrade *framework* would 
allow webGUI tools like: 
 1. Select the module you want to install or upgrade.
 2. Install the module in your site.
 3. Enable the module (if installing).
Or like
 1. Type a domainname (example.com)
 2. Select what type of site you want (from a list of install profiles and/or 
other CMSes)
 3. Log in, into your newly installed and preconfigured site

Such a webgui CAN (but should not, IMO) live inside your very own Drupal site. 
It can also be ran from within plesk, or ispconfig. Or on the CLI by one 
sysadmin with too much time.

So, I again, plead for a framework. An API. A well thought out foundation. An 
architecture. 
Not a GUI installer that needs FTP and SSH access and that requires you to 
open up (rather) insecure permissions on certain files. Not an 
in-site-upgrade system that forces you to run with the most insecure 
permissions on teh intarweb. 
No. 
A framework. 

Then the Good Folks Who Develop Cool stuff can build install GUIs on top of 
that. Or a capistrano recipe. Or we can give the redistributors a good 
alternative to develop on top of, instead of bashing the hell out of them on 
digg and drupal.org for distributing "old" Drupal versions.

Bèr
-- 

Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: 
sympal.nl


More information about the development mailing list