Upgrade from backend

[kochs-online]

This is just a feature/enhancement request.

I noticed that I tend to postpone Zenphoto upgrades because it's a bit of a struggle to do them.
It starts out with the requirement to have some sort of tool at hand (FTP/SCP/SSH/…) to upload the new version to the web server. Next step for me is always checking and thinking about which directories and files will need to survive the upgrade and which ones should be replaced (i.e. deleted beforehand). Some minor steps add to this and the upgrade procedure ends up taking me like an hour or so. YMMV. But comparing this to other CMSs (*cough* WordPress *cough*) I think the whole thing could be automated and be easier, quicker and safer (!) for users to do.

But I don't come empty-handed! 😄
I started out to write a shell script to perform those described steps and some additional ones.
But then I realized that a shell script is just a few steps away from a PHP script that everyone might benefit from. So I thought I'd throw my notes out here to discuss it with you guys. Some steps also require your support which I'll describe below.

Steps involved (notes in italics):

1. Check availability of new Zenphoto version
2. Check file size of new version and available space in file system (quota?)
   Latest release can be found here: https://github.com/zenphoto/zenphoto/releases/latest/
   But unfortunately the filename cannot be derived automatically to download https://github.com/zenphoto/zenphoto/releases/latest/download/[filename]
3. Download new version
4. Validate checksum of archive file (unavailable for GitHub as of now?)
   Also see SHA256 checksum changed for v0.26.0 libgit2/libgit2#4343 (comment)
   Possible solution: Checksum supplied by maintainers?
5. Decompress archive file to (temporary) new version directory
   .tar.gz should be preferred to preserve file permissions, but PHP lacks (built-in) support for .tar.gz.
   Are file permissions set in .tar.gz for installation files?
6. Delete archive file
7. Activate Zenphoto site_upgrade plugin
   Optional.
   Not too helpful being an extension of Zenphoto that's going to be deleted in a second, is it?
8. Delete selected files from Zenphoto installation (e.g. files in Zenphoto root)
9. Delete selected directories from Zenphoto installation (e.g. zp-core, but keep zp-config)
   Problem: Third-party extensions should be kept as well, but are installed in the same directory as default plugins. Maybe these could be moved to a different directory for ease of handling in future versions of Zenphoto?
10. Move new files and directories to Zenphoto installation
11. Delete (temporary) new version directory
12. Show link to setup and remind user of maintenance mode (cp. site_upgrade plugin)

Obviously this is just a draft and I might have missed something or you might have better ideas, but that's why I wanted to share this. 😉
If you don't like the idea at all, that's cool too. I'll just go ahead and hack together a shell script for my installation then.

[acrylian]

Next step for me is always checking and thinking about which directories and files will need to survive the upgrade and which ones should be replaced (i.e. deleted beforehand).

It's actually quite simple and noted on our installation instructions. You need to replace the root index.php, the official themes and zp-core. That's it. If your ftp client is set to really replace it on upload you don't even need to delete beforehand. Mine asks for either update or replacing.

But unfortunately the filename cannot be derived automatically to download

GItHub has an API that allows getting the filename.

Not too helpful being an extension of Zenphoto that's going to be deleted in a second, is it?

The state is actually set via the config file which the root index.php uses so it does not matter. But that root index.php will of course also be deleted so temporarily the site will be off.

Problem: Third-party extensions should be kept as well, but are installed in the same directory as default plugins. Maybe these could be moved to a different directory for ease of handling in future versions of Zenphoto?

Actually not true unless you do things wrong ;-) Official plugins are in zp-core/zp-extensions, third party ones are in /plugins. You cannpt even switch them especially if they have an additional folder as the paths are different.

---

This is of course already on our list for the "next major release" although I cannot promise that we'll manage to include it. (I already have a basic draft function which however is not yet working at all). It should be secure and also not killing anything accidentally.

[kochs-online]

It's actually quite simple and noted on our installation instructions. You need to replace the root index.php, the official themes and zp-core. That's it. If your ftp client is set to really replace it on upload you don't even need to delete beforehand. Mine asks for either update or replacing.

Yes, I know the instructions page, but then again I always have to read and follow those; every time introducing the possibility of errors. And working with a client software is the second requirement. Knowing the login credentials for my webspace the third. Also, replacing files is not a safe way to perform updates because you will fail to delete files that are no longer part of the new software version.

Don't get me wrong: I'm not bashing the current process! I just want to think about where it could be improved for a better and safer user experience.

GitHub has an API that allows getting the filename.

Ah, this one, right? https://developer.github.com/v3/repos/releases/#get-the-latest-release
That's good to know! But it would even better if there was a (HTTP 302?) link on zenphoto.org because it wouldn't require to use an API. Just a stable link and you're done.

The state is actually set via the config file which the root index.php uses so it does not matter. But that root index.php will of course also be deleted so temporarily the site will be off.

Maybe a redirect to a maintenance page could be included in the .htaccess file as kind of a failsafe solution? So while index.php is unavailable requests would get redirected to a (static html) page.
Something in the way of:

RewriteCond %{DOCUMENT_ROOT}/index.php !-f
RewriteRule ^(.*) /maintenance.html [L,R=503]

Actually not true unless you do things wrong ;-) Official plugins are in zp-core/zp-extensions, third party ones are in /plugins. You cannot even switch them especially if they have an additional folder as the paths are different.

Huh! I really didn't know that and did it wrong for quite a time then! 😄
I even built plugins myself that are residing in zp-core/zp-extensions. I'm gonna fix that immediately.

[acrylian]

Yes, I know the instructions page, but then again I always have to read and follow those; every time introducing the possibility of errors. And working with a client software is the second requirement. Knowing the login credentials for my webspace the third. Also, replacing files is not a safe way to perform updates because you will fail to delete files that are no longer part of the new software version.

I use a FTP client and have all saved there. Can't really find it that complicated. And if it is set to replace instead of update (or as mine asks for it) there is no problem. I do that for years without ever having this problem ;-)

But regardless we will add such a facility in the future as lots of CMS have this for years of course. I have a rough download+copy-stuff locally but it is nowhere of ready or finished (one of the ca. two dozend places to work on for our major release ;-))

.tar.gz should be preferred to preserve file permissions, but PHP lacks (built-in) support for .tar.gz.
Are file permissions set in .tar.gz for installation files?

Forgot to comment on this. We would use the zip file because of PHP having support. Setup sets the permissions generally and also the server should handle it when extracting copying (respectively that would use setting accordingly).

That's good to know! But it would even better if there was a (HTTP 302?) link on zenphoto.org because it wouldn't require to use an API. Just a stable link and you're done.

The current version check does also use our latest release post and not GitHub itself as do the download links which are then generated and then downloaded from GitHub. Download from GitHub is of course better to move any download overhead to them ;)

Maybe a redirect to a maintenance page could be included in the .htaccess file as kind of a failsafe solution?

Probably, but the index.php rarely changes and would be the first to change so it should be available quite fast again.

Btw, could you perhaps send me a mail directly?