Web lists-archives.com

Re: How do we know ...

> 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

Also, unless there are security issues or you *absolutely* need a new
feature, production sites rarely need bleeding edge.