> Date: Thursday, January 17, 2019 14:53:10 +0000 > From: Lester Caine <lester@xxxxxxxxxxx> > > With distros disabling PHP7.0 and as a result PHP7.2 upgrades being > applied despite ( I thought ) being locked out, I THEN find > problems even with the PHP7.0 machines with thumbnails not being > generated from the pdf uploads. The original problem was > letsencrypt stopping updating the certs and complaining about > python files not being available! Luckily this was before they > expired, but not the first time it's background process has stopped > working and I have lost sites. > > Just how do we set things up so that WE control just what is > updated and what is not? I know it's a distro problem, but I > suspect the solution has to be NOT loading PHP, Nginx and Firebird > from the distribution at all? Yet we are reliant on secondary > software load by the distribution. The PDF problem turned out to be > a change to how 'convert' using ImageMagick actually decides if it > is going to handle a file format - the change stopped it READING > the file. I don't even remember updating that machine since it > worked on Monday! > > I've now got to go through all the sites and fix 'count()', > 'each()' and random complaints about 'numbers' so I can stop hiding > the deprecated messages but I had to switch off all errors just to > get the machine live again and my machines have always run with > errors being displayed as THAT helps when things do go wrong! None > of these give me anything but a waste of even more time :( Just > when did it become necessary to add typing everywhere to stop new > messages? The proper approach is to have a testing environment that matches your production one(s). Do updates there, fully test, and then proceed as indicated. Never apply updates to a production site without full testing and certainly never let a production site "auto-update". Also, unless there are security issues or you *absolutely* need a new feature, production sites rarely need bleeding edge.
