Does anyone have advice on how to make Omeka Classic updates as easy as possible?
Today I updated from 3.0.2 to 3.0.3. Everything went smoothly, as it has since version 2, but it was still quite a bit of work for very few changes to the actual code.
I generally use a mixture of FTP and SSH, and in future I’ll try to do everything on the command line. But is there an easy way to create a diff file or similar, so that I don’t have to install the whole lot from scratch? A couple of other CMSs I use make updates very easy; one uses a single small PHAR file, and in Piwigo version checking and updating is a one-click operation.
Also, is there a way to find out who’s logged in to the back end when an update is needed? Our group is small, so sending round a notice for scheduled maintenance can feel like overkill. On the other hand I don’t like dumping people, and I’m not sure whether there is a risk of damaging the database if someone happens to be logged in when I do the update.
Can you go through the basic steps of your upgrade process? I know we have our instructions, but just how you approached it?
To some extent the instructions we give there aren’t as efficient as they could be, in the name of hopefully being easier for users of many skill levels to follow. Moving the existing folder, unzipping the new install, and moving back a couple of files/folders is the fastest/simplest way and is a pretty short process.
The risk for having users actively working would typically just be potentially some lost work on the form they’re working on, plus of course finding the site unavailable during the upgrade itself. Simply people being logged in but not actively making a change wouldn’t cause problems though.
It’s possible to do a “patch” type system: we don’t mostly because that has some complications with dealing with multiple versions and so on, though you can use Git to get a patch between your old version and a new one. On the other hand, if you’re comfortable using Git that’s probably the very easiest option in terms of moving between versions: if you check Omeka out using Git, you can use commands like git checkout to move the installation directly to a desired version.
Many thanks for looking at this, John. After checking that plugins are up to date and making a backup, my procedure is:
Upload and unzip the new version to its own folder
Copy over db.ini
Move over all plugins apart from those that already exist in the new folder
Move my custom print.css from admin/themes/default/css
Move the files directory
Rename the new Omeka directory to activate it, and delete the old one
Put like that, I agree it doesn’t seem much work, especially once I get curl or wget working (I tried curl to update a plugin but the resulting zip file wouldn’t unzip). But the procedure for moving only some of the plugins, for instance, is tricky (at least for me) on the command line, and slow via FTP.
Using Git had not occurred to me. I have used it before, but it scares me. Still, it would be a great way to go if I can write myself a checklist of commands. This would be a nice addition to the docs (hint).
Just adding to the conversation: I seem to remember a plugin that would allow for auto-update of plugins, never tried it but, if such a thing was possible, then maybe it could be a useful new feature to be included in Omeka itself.
I’m leery towards add auto-updating features just because they imply telling users to set permissions so Omeka can edit its own files… this is the kind of thing that leads to exploits that are common with some other CMS software.
I hadn’t thought of that, and it made me wonder whether even my Omeka permissions (on Reclaim) were safe. They all seem to be 755 (directories) or 644 (files), which I take it is OK. But I’m confused about permissions in general, and after reading your explanation here I bet many other people get it wrong too.
I mentioned Piwigo as being very easy to update, and many of the files in my installation are 755. Sounds like you’re suggesting that (a) those facts are related and (b) that’s bad. CMS Made Simple (the one that updates via a PHAR file) is on the same server, and all files seem to be 644.
Yeah unfortunately as I wrote there, it really does differ from server to server. Many servers run things so that PHP runs as “your” user, so the second and 3rd numbers of the permissions mode don’t really matter in that sense on those servers.
Having the server able to write all the files of the application, it’s not necessarily “bad,” it’s a tradeoff: the system is easier to update so more people do it, which could increase security. On the other hand it potentially makes it easier for an attacker that exploits a security issue to make that more permanent. To some degree this is just me being conservative.