Updating Textpattern.

ruud · 2015-05-25 19:34:08

Those of you who use that rather popular blogging software which shall not be named, may have have noticed that it by default updates itself whenever there’s a minor release and you can (if you want) set it up to update automatically even on major releases. So I was wondering why TXP doesn’t do that and if it would be interesting to write a plugin which does this, in which case I’d like to write one.

I think such a plugin should

check once every day (at most) if a new version is available
if there’s an update available email the users with the role admin/owner every day (nag, nag, nag) until they finally give in and update. Perhaps force the update if the owner doesn’t respond within 1 or 2 weeks.

The owner would then log in on the TXP admin interface, go to extensions => update. Some things should be checked there:

are the current files modified… if so, the owner should think twice about having those files overwritten.
are the RPC / sites directories present? If not, I don’t want to install them during an update.
is the .htaccess file modified?
warn the owner about making backups. This should not be done by this plugin, because making backups should be done more often than just during upgrades.

Then a button “update” which:

downloads the package (using “curl” or isn’t that installed everywhere?)
unpacks it in the /tmp dir
copies the relevant files (not /images and /files) over the existing install
removes the unpacked contents
triggers the relevant update scripts
updates installed languages.

This would rely on the most recent version being available via the textpattern.com/latest.tar.gz link and the check_updates function being up-to-date as well. Ideally, this is how the aforementioned blogging software does it, you would call a script @txp.com with the TXP version as querystring parameter and get a JSON result which contains all the possible options for upgrading, including the link to the corresponding download package.

And yes, ideally, this should go into TXP core, but having it as a plugin would make it much easier to upgrade the old installs as well.

Any other suggestions / ideas / comments?

Destry · 2015-05-25 20:27:10

I can’t tell if this is covered in #4, but would it be possible to remove the unnecessary post-install files, e.g., the “update” folder?

Other than that, this seems like a highly practical endeavor, Ruud.

uli · 2015-05-25 22:56:01

Christmas in May :)

ruud wrote #291058:

Any other suggestions / ideas / comments?

sacripant asked for a relief during updates for admin CSS files (errm, in my words). I want to mention that here again, with the meaning of “one tool for the update”. sacripant aims at only Hive, could be convenient to have something for each theme.

And I thought of something for textpattern.js, like a standard file/filename that is to be included/imported by default. From update to update, I’ve to think of dragging several lines with me.

^{Can of worms:} What can a plugin do against breaking admin plugins before an update? Warn on every update? I.e. first enticing the user into the update and, as the next step, cautioning them to be careful when they’re willing? Pooh!

bici · 2015-05-26 00:21:00

I believe there are many cool CMSes that don’t auto-update themselves.
having said that i don’t WANT any updating that did not backup my PUBLIC folder and my MySQL files.

ruud · 2015-05-26 08:42:14

uli wrote #291064:

sacripant asked for a relief during updates for admin CSS files (errm, in my words). I want to mention that here again, with the meaning of “one tool for the update”. sacripant aims at only Hive, could be convenient to have something for each theme.

I think it’s too difficult or even impossible (because you don’t know what the exact changes are or because the differences between the old and new TXP version are too great) to automatically merge changes made to the old TXP version into the new TXP version. It is possible to rename the modified old files (txplib_misc.php => txplib_misc.php.old instead of replacing them, so the changes don’t get lost.

And I thought of something for textpattern.js, like a standard file/filename that is to be included/imported by default. From update to update, I’ve to think of dragging several lines with me.

That’s something that would have to go into TXP core.

^{Can of worms:} What can a plugin do against breaking admin plugins before an update? Warn on every update? I.e. first enticing the user into the update and, as the next step, cautioning them to be careful when they’re willing? Pooh!

Show the release notes / history before updating, so the user can make an educated guess if the changes will affect the admin side plugins. There would have to be a warning in the release notes or course. A better solution would be to have a central plugin repository which also stores which plugin version is compatible with which TXP version and then add an option to update the plugins as well. That’s a bit too much for me to handle at the moment.

bici wrote #291065:

I believe there are many cool CMSes that don’t auto-update themselves.
having said that i don’t WANT any updating that did not backup my PUBLIC folder and my MySQL files.

I’m not sure what the public folder is. Assuming you backup regularly anyway, you could (should!) do that just before updating. In the current proposal, you could use the plugin just to get notified about a new release and handle the update manually yourself if you want.

gaekwad · 2015-05-26 09:17:21

ruud wrote #291071:

In the current proposal, you could use the plugin just to get notified about a new release and handle the update manually yourself if you want.

Forgive my wonky brain – is there (was there) such a thing as a Textpattern release update mailing list?

phiw13 · 2015-05-26 09:53:12

Note that there is already some core mechanism that checks for availability of upgrades (there is a notification tucked away on the Admin > Diagnostics tab – quite invisible if you ask me). Could the plugin at the very least improve on that?

It could —for example— issue a notification on the default tab (as set in the prefs) when the admin/owner logs in. The #messagepane notification bubble could be used here (perhaps including a link to the release notes). And perhaps it should keep a visible marker in the TXP UI (in the <header>) similar to what the CMS-that-cannot-be-named does.

I’m not sure I’d personally want or use an automatic updating system though – I don’t allow my OS to update itself automatically either; ditto for third party apps installed outside the App Store, most use the Sparkle framework that does more or less the above.

Destry · 2015-05-26 11:21:15

If it did this…

Informed me of a new release needing updated (daily nagging might be too much; 3 days? weekly?)
Showed me what changes were made (with relevant security details at top), so I didn’t have to go find some blog post that may or not even be written, or have to open up the ~~ReadMe~~ History file from the release.
Gave me an option for “Auto-update now!” (default being I do it manually, in case it’s necessary)

…then I don’t see any problem with this idea. People could use it or not in that case. If all my system checks were a go, whatever those might turn out to be, I would use it.

But if it’s strictly an auto-update mechanism in the background, then I can see phiw13’s concern.

2 cents.

Last edited by Destry (2015-05-26 12:56:35)

colak · 2015-05-26 11:48:49

It could be something simple. A couple of text links in the write tab, visible to the main admin of the site. The links could link to the new read me and the second could do the automatic upgrade. The links could just be invisible if someone is running the latest version.

Regarding saving the old files. I think that it is a good idea (especially as far as the htaccess file is concerned) but at the same time it could be mostly superfluous because if the db is updated, the old files will return errors unless a backup of the db is reinstalled.

I know that in all but one of my sites such automatic upgrades will be handy and I would definitely like to see this as a plugin or a core feature.

I would also have an option to update all dev steps as well, as it will save organising an svn connection. This will/might help with the development of txp as more people will be able to spot bugs.

Will this plugin also delete the setup folder every time it executes an update?
What happens with the htaccess file? – especially if there is an official update to that?

ruud · 2015-05-26 12:30:17

phiw13 wrote #291076:

Note that there is already some core mechanism that checks for availability of upgrades (there is a notification tucked away on the Admin > Diagnostics tab – quite invisible if you ask me). Could the plugin at the very least improve on that?

I was planning on using the same method of checking for updates, assuming that is the official way to do it.

It could —for example— issue a notification on the default tab (as set in the prefs) when the admin/owner logs in. The #messagepane notification bubble could be used here (perhaps including a link to the release notes). And perhaps it should keep a visible marker in the TXP UI (in the <header>) similar to what the CMS-that-cannot-be-named does.

Yes.

Destry wrote #291080:

Showed me what changes were made (with relevant security details at top), so I didn’t have to go find some blog post that may or not even be written, or have to open up the ReadMe file from the release.

I think the HISTORY.txt file is the most useful. The stuff in README would be handled by the plugin. It would be useful to have a more detailed history.txt (doesn’t have to be that file) that would indicate what might break on updates and how to fix that. For example, the need to register plugin tag handlers when upgrading to TXP 4.6.

But if it’s strictly an auto-update mechanism in the background, then I can see phiw13’s concern.

It is not. The main goal is to prevent ancient TXP installs from not ever being updated because the owner simply doesn’t check for updates himself and also to make it easier to do the update so it’s just one click to update and there’s no need to get a ‘guru’ to do this.

colak wrote #291082:

Regarding saving the old files. I think that it is a good idea (especially as far as the htaccess file is concerned) but at the same time it could be mostly superfluous because if the db is updated, the old files will return errors unless a backup of the db is reinstalled.

WP contains code to do a roll-back. My experience with TXP is that upgrades just work and the problems you do encounter are only visible after the DB upgrade is complete, so downgrading isn’t really easy. I suspect for the more complex websites you’d first upgrade a development site and only upgrade after testing.

I would also have an option to update all dev steps as well

Do you mean keeping up to date with the development version (GIT, not SVN these days)? That’s outside the scope of this plugin.

Will this plugin also delete the setup folder every time it executes an update?

Of course.

What happens with the htaccess file? – especially if there is an official update to that?

I think the .htaccess file should be part of checksums.txt in TXP core, but what I could do is hard-code known MD5 hashes of .htaccess from all TXP versions and if the current .htaccess file matches one of those, it’s safe to update it, because the user never modified it.

Destry · 2015-05-26 12:55:42

ruud wrote #291084:

I think the HISTORY.txt file is the most useful.

That’s actually what I meant.

It would be useful to have a more detailed history.txt (doesn’t have to be that file) that would indicate what might break on updates and how to fix that. For example, the need to register plugin tag handlers when upgrading to TXP 4.6.

Sounds good.

bici · 2015-05-26 15:04:02

ruud wrote #291071:

I’m not sure what the public folder is. Assuming you backup regularly anyway, you could (should!) do that just before updating. In the current proposal, you could use the plugin just to get notified about a new release and handle the update manually yourself if you want.

i meant the Textpattern directory. Apologies … I misunderstood your proposal, I like the idea of getting a notification. very useful

Textpattern CMS

Textpattern CMS support forum

#1 2015-05-25 19:34:08