[2.0] Auto upgrade manager [developer needed]

[garvinhicking]

discussion and volunteers here

[yellowled]

I merely suggested this because it came up in preparation of the s9y InfoCamp podcast, Grischa commented on it there, and somebody mentioned it on twitter -- and I had no idea why we don't have it already. So if there is a good argument against it ...

YL

[garvinhicking]

Hi!

My main argument is that downloading and fetching files through FTP or whatever has both larger requirements on the server side (PHP needs to not be firewalled, etc.) and is easily to "fuck up" because of timeouts, interruptons, memory limit, PHP timeout, browser stalling or whatever.

I haven't looked at how wordpress does it, but my stomach aches when I think about an upgrader like that...

Regards,
Garvin

[Timbalu]

Hi

I don't think we need an upgrader itself for now, while this is something you have to know about when using serendipity, but we do need an admin notifier concerning security holes and differing ChangeLogs between current used and current available version at least. Lots of people just do not know their system is vulnerable or outdated, because they do not visit the forum consequently enough. So I think we should have this as soon as possible, in addition with a modernized text how safe and fun it is to upgrade a serendipity system!

Ian

[onli]

But if we mention to them "Hey, your version is outdated, grab the new one yourself" (which we should do and is a good idea - the admintemplate is already designed to offer something like this with its linksection and dashboard) it would be really sweet to offer them "Do it now automatically".

What exactly would an upgrader need to do? I think it is something we should try to build, always with the option in mind that we won't use it if it fails to be as stable as we want.

Is this a complete list?

• (Make a backup - how exactly?)
• Grab the files
• Place them in the webroot, replacing the old files
• Start the upgrader (normally done via visiting the blogpage)

[Timbalu]

In my opinion, the charme of Serendipity is, don't do it automaticly, you always have full control, you can even be minded that javascript is something to be aware of (my historical based contribute to the jquery discussion... ), and so on....

In addition to your list,

• -it would mean a lot of work for Garvin, concerning incremental updates, or
  -something like a sponsor for new server flats.
  -doing backup automaticly is nearly impossible (remember the backup plugin discussions)
  -you never know how some providers do shared installations...

[yellowled]

Pro arguments (and these are the arguments people using it without developement background usually list):
- it's very convenient, user-friendly
- although updating is documented well, some people are still afraid an update might break their installation; an auto-update might solve that for good
- we have a large German user community but no (public) German documentation on updating
- "System X has it"

YL

[garvinhicking]

Hi!

BTW - the dashboard event plugin should already have a version notifier...

I've not even thought about backing up current content in the autoupdater. That's something very important! And SQL backups take considerable place...not even phpMyAdmin works on all servers to provide full dumps...

Regards,
Garvin

[Timbalu]

BTW - the dashboard event plugin should already have a version notifier...

Yes, but who knows? (I didn't!)
What I imagined should work automaticly by default. Without, its not worth thinking about it.

Ian

@YL
"System X has it" ... so whats the difference... I don't want 'X' under a new name

[onli]

In addition to your list,

-it would mean a lot of work for Garvin, concerning incremental updates, or

If done properly, it would mean no work at all. The plugin should fetch the update automatically from the existing infrastructure, if possible.

-something like a sponsor for new server flats.

It isn't additional traffic apart from the notification, which should be negligible.

-doing backup automaticly is nearly impossible (remember the backup plugin discussions)

Probably true, though i don't remember that discussion. It'd be very easy for sqlite-databases and nothing hinders the user to make a backup prior, and to let the updater say so to the user.

- you never know how some providers do shared installations...

Sure, it has to be possible to deactivate it.

[yellowled]

Apart from how hard it might or might not be to implement this -- isn't it kind of a bonus in terms of security overall to make it easier to a) notice an upgrade's available and b) execute that update? If this was implemented and active in the core, we could probably even drop public announcements that there actually is a security issue with S9y. Wouldn't that be a good thing?

YL

[garvinhicking]

Hi!

Apart from how hard it might or might not be to implement this -- isn't it kind of a bonus in terms of security overall to make it easier to a) notice an upgrade's available and b) execute that update? If this was implemented and active in the core, we could probably even drop public announcements that there actually is a security issue with S9y. Wouldn't that be a good thing?

LOl. No. That's really far from responsible security.

Anyhow - the problem with having a notifier is that there are a lot of s9y installations where HTTP access to foreign URLs is not allowed. It is very hard to detect this, so by default the option would need to be disabled because it could possibly lock you out of the whole s9y backend...

There are really a lot of dangers and edge cases with this upgrade manager, and even with update notifications...

[onli]

Google Chrome updates itself automatically on some systems, out of security considerations. It doesn't mean that it is not needed to write about security-issues, but having less old systems means less attackable installations.

Anyhow - the problem with having a notifier is that there are a lot of s9y installations where HTTP access to foreign URLs is not allowed. It is very hard to detect this, so by default the option would need to be disabled because it could possibly lock you out of the whole s9y backend...

I have done that with the autotitle-plugin. Trying to use curl or else httprequest or else die. I don't see why this should lock us out - it is of course possible that the updater fails to fetch the fails or to save them, but I don't see why this would lock anyone out?

[garvinhicking]

Hi!

The checkroutine would definitely need rocksolid coding so that if it fails, the upgrader does not try time and again to be run, because if firewalls and timeouts occur, the PHP programm might halt at that place, that's what I was referring to.

I don't like the idea of auto-updating. We can prompt an update check when a new version is found, but with PHP apps, IMHO auto-updating should never be done without user feedback.

Regards,
Garvin

[yellowled]

We can prompt an update check when a new version is found, but with PHP apps, IMHO auto-updating should never be done without user feedback.

What kind of user feedback do you mean? A "normal" manual update these days runs pretty much without feedback as well. Download zip, unzip it, ftp it to your server, login to admin backend, click a button to update (optional), done.

YL