The problems of daylight savings changes has been covered on the latest health post so I will not repeat that. The problem today is deciding just where I go on breaking the perfectly functional system that I am posting them on! I've already covered the problems of trying to get PHP code updatd so it continues to work on later versions of PHP. There may be 'problems' in PHP7.3 running on top of Firebird 3 and there are bugs that I need to address, but which don't stop the content being displayed. So should I simply maintain those versions of the web stack which are working fine on the current build of Nginx? Life would be a lot easier if I do ... and since *I* control just what is running on my own machines I do not need to worry that some third party will kill off those versions on their hosting. In fact none of the hosting I have used has ever provided Firebird anyway so it is only really the PHP stack that is the general problem, and most hosts still have builds of PHP7 available as a LOT of their customers would have no idea how to fix things anyway, even those using frameworks like Wordpress on top have problems when that forces PHP upgrades on the stack.

I already have the ability to select which version of PHP is used to run a site and adding newer versions is easy as well. I used this crib sheet to great success yesterday having pulled a copy of the latest PHP8.4 source code over. Even the Tumbleweek machine is only being updated to PHP8.3 currently despite PHP8.4 now reaching version 8.4.5 ... and I'm being told that I really need to be running 8.4 to get the latest Firebird drivers. One of the problems with this is that it only supports the pdo driver which I find problematic in the way it handles database transactions, some of which it does not support such as ones working across multiple databases. At present I am not sure that the raw driver is actually working with any PHP8 version despite being able to build it. In addition of cause, Firebird is now shipping Version 5 which adds a lot of stuff which may or may not be useful. Certainly I do not need any of the 'improvements' to Firebird 4 such as the ill-conceived implementation of 'timezone' in FB4, which has no way to handle pre standardised time offsets. My own PHP code handles this properly so will never use the internal changes.

Having at least sorted the generic mapping services and having all of that working in parallel with the current PHP is a start, but the next target is to get the old ibtest.php script working with Firebird 5 on PHP8.4.5. One thing that I am quite happy with is that simply switching from FB3 to FB5 on top of PHP7.3 seems to be working fine, and while most of the problems with stepping up through the newer versions of PHP are due to things like 'Deprecated' and many of these are in the ADOdb and Smarty libraries, so I need to update those first, after getting ibtest itself working.

I need to bring a lot of the crib sheets on lsces.uk up to date, but at least what is there from over the last 20+ years is still accessable.

Have just spotted Laravel and it's tempting if it will run with Firebird and I can port all of the material over from the existing site databases, but we will have to see about that!