Updating modules and themes in Drupal 7
The problem: Updates in Drupal require FTP / SSH and a bit of know how
When the average Drupal site owner without ssh, cvs and other geek gadgets wants to update modules on or themes on their Drupal site, they currently have to do the following:
- Go update status and see the mod is out of date
- Take the site offline
- Make a backup (if they can)
- Know where to find the module on d.o., download the tarball
- Unzip the tarball
- Remove the current directory
- Use FTP to upload the new directory
- Run update.php
We’re trying to provide a way that users can get the same user friendliness of a package manager like Synaptic. Where updates and new installs are just a few clicks, no geek gadget belt.
I’ve entered the D7 ux fray, specifically focusing my generous amount of Acquia community time on getting a project called the Plugin Manager spruced up and into core.
For more background on the effort, see: Plugin Manager in Core (part 1).
The solution: make Drupal update like everything else.
Here is the issue:
Plugin Manager Part 2 : The update status UI
I’ve been working out some wireframes of how the process might look, and I wanted to share them with the planet to see what people thought of them. So without further ado:
Kommentare
As someone who slogs through
As someone who slogs through the 8 steps for every upgrade, a more streamlined upgrade process would be wonderful. I'm looking forward to using this.
If you have access to the
If you have access to the command line, you can also use Drush to do all that for you.
http://www.developmentseed.org/blog/2009/jun/09/build ing-drupal-faster-d...
The command is just :
drush updateWhich will look like this :
ht tp://www.developmentseed.org/sites/default/files/drush.png
Sure, we've all got our
Sure, we've all got our methods, but the point of this is to provide something for people who don't know how to use such tools. So that every new Drupal users can quickly and easily update their modules and themes, without ever hitting FTP or the command line.
Also, we're working on secure ways to download the packages using openSSL or gnupg or whatever will work cross platform and be secure. Check out the link mentioned to learn more about the effort, would love your input on how to accomplish this big usability improvement.
Thanks!
Jacob
Go for it!
Go for it!
This would be just great --
This would be just great -- a relatively simple way to perform updates. Funny, but I was just on the phone this AM with Alex Lindahl of Acquia about my interest in handling this sort of thing on my own, as a site owner (rather than paying for external support to do this, as I'm doing now). Though it seems like it's not that complicated, it's also a process that's subject to glitches -- meaning it's not something you really want to do if you don't feel like you can backtrack...
I don't want to suggest that the scope of this be extended unnecessarily, but I would just like to point out a few key pieces here:
1. If there's any way to hook this into a module/tool for backups, that would be great.
2. One key piece, on the backup front, is ensuring the backups actually work and can be used to restore a site. How does one do that? For the non-geek, that's a pretty tall order -- testing out a backup of a Drupal site to make sure the site can be restored.
"1. If there's any way to
"1. If there's any way to hook this into a module/tool for backups, that would be great.'
There is the Backup and Migrate module, although it is likely to stay in contrib, we could allow it to hook into this process and provide a quick backup link there.
Restoring is another dicey topic. The only way to safely do this in Drupal now, is to take the site offline, backup the code and DB. Then a restore will be safe, otherwise, anyones' guess. There is no separation of "user contributed content" and "the backend system" which means, you cannot roll one back without affecting the other.
-J
For this to work the way you
For this to work the way you describe it, wouldn't you have to set your module and theme directories as writable by the web server itself? Wouldn't that make Drupal more vulnerable to attack, especially on a shared host?
Right now, I believe that only the settings file is writable by the server - an attacker could overwrite or erase settings, but that's about it. With the modules or themes writable by the server, it could allow an attacker to inject PHP code into currently installed modules and/or themes.
If done skillfully (or, more likely, when someone skillfully writes a script for the kiddiez), the site owner and visitors would not see any change to the site, but the malicious code would run on every page load - for example, having the site send out a few spam messages, or pulling the plain-text password from the login form.
Don't know if you heard about it, but VAserv was hacked hard this weekend. I had a VPS that was among the casualties there, so maybe I'm a little more sensitive to these issues right now, but I'd like security to be (remain?) a priority in the D7 design process.
Hi Kirk, Please click
Hi Kirk,
Please click through the 2nd round wireframes, or go visit this issue at d.o. We're actually a little hyper paranoid about security. People will have to provide their ssh/ftp creds when installing and we won't store the password.
Also, we will be signing packages on d.o. to ensure no MiM attacks.
I wrote most of the underlying API layer here: http://drupal.org/node/395472
So you can see how that works.
Best,
Jacob
Hi Jacob - thanks for the
Hi Jacob - thanks for the pointer, I overlooked those links. So it'll be a push from d.o via (s)ftp then? That's an interesting approach - seems to negate my concerns quite well. Should be interesting to see how the final product works.
Not exactly. 1. The local
Not exactly.
1. The local Drupal site downloads the file from d.o
2. It confirms that the md5 sum of the file matches that published by d.o (to reduce potential for dns poisoning - this happens automatically via ajax, ideally)
3. Ask for ssh/ftp credentials every time, so someone with knowledge of ftp/ssh has to do the action
4. The local Drupal site opens an FTP/SSH connection back to itself and does the install. This allows all code files to remain "read only" to the webserver and yet be replaced by the server acting as the user specified in the FTP/SSH.
See http://drupal.org/proj ect/plugin_manager for more details.
It's always been my
It's always been my understanding that if this was not implemented via a system like Drush, it was not getting into core. This still seems good to me, plus it's a big win for drupal hosting focused companies, and still maintains a higher standard of security (as I understand it).
That said, you should take a look at how Aegir displays these sorts of details, it's a great inspiration to draw from.
Eclipse
Very good idea, and I second
Very good idea, and I second the linking or integration with Backup and Migrate, evenif it is just recommending that or a similar module and letting someone invoke it from page 2 in your wireframe. I think this would otherwise be a hurdle for many. Thanks so much for taking this one, it will make many people's lives easier.
My workflow is shorter than
My workflow is shorter than what you describe via SSH: copy link from update status, 'wget $path, and 'tar zxvf' but doing this on the back end for many modules at once would be a good thing.
What would make it even more interesting would be to expose community features such as 'X bugs filed since release' or 'X bugs related to release filed'. Or have some sort of a ranking for module reliability.
Of course, the problem is that the community works differently on different modules. For CCK, Views, Panels, the bug counts are staggering but yet they are reliable, widely used and people just report more bugs. But for smaller modules, I always wait a few days and check the issue queue before updating.
Of course, Joomla has had a similar system for a while (at least direct upload if not sync with repository) and it plays havoc with permissions on shared hosting: you may end up with directories only a root can delete.