Webstack - PHP Version Upgrades

There are a lot of things that have changed in PHP since it's PHP4 days which is were the original TikiWiki code that was forked first as TikiPro and then renamed to Bitweaver after objections from the TikiWiki team. The essential difference was the move away from a continuous code base to packages that could be selectively activated as needed, and in my case new ones tailored to specific applications added. I have had a bit of a love hate relationship with the php project ever since the late 1990's when I first started using PHP and today I just accept that many of the simple things are gone for ever, such as assuming that a variable is empty if it has not been created. The strict typing rules can be a pain at times, and the move from things like strings being arrays of characters still pops up today with old code tagging them as 'array' when they now need to be 'string'.

Another change that has been forced on my is the move from Eclipse over to VSCode. This came about because I could simply not get Eclipse to run after a Tumbleweed update. I am fairly sure it was down to an incompatibility with the Eclipse PHP extension which being honest had fallen behind and only supported checking up to PHP8.3 at that time. I've had to pay for support for the PHPDevsense extension in VSCode and it does at least nanny on the base of PHP8.4 preferences and it's that nannying that I've been incorporating in the new code base even though it is optional at times. VSCode has a few limitations which I will document at some point, such as not being able to handle dynamically built constant defines which bitweaver uses as part of the package system. I've had to manually add copies to stop these appearing as problems on every code page. The plan today is to make the code clean and functional on PHP8.4 and I have ignored any backwards compatibility, which is a change from my early days when was made sure that code still ran on PHP4 while adding PHP5 functionality. The saga of PHP6 I think signalled an end to some backwards compatibility, and then the changes between PHP7.3 and 7.4 were another brick wall. That my own websites were still running PHP7.3 until the last couple of months was in part because of that brick wall.

So just where are we today? Things like namespace, composer and the likes are considered the modern way of working and so I did try and get on board that bandwagon. I'm not happy with the current state of play which again needs documenting, but essentially each package is now a namespace under Bitweaver and some of the global functions have moved inside a class wrapper such as KernelTools which is now loaded via the autoloader when needed. I think that it is an improvement on many pages which in the past had 'required' other scripts to be loaded, but now 'use' that script only when it is actually needed.

Moving down the stack, ADOdb still does not have a namespace, although I've wrapped it in Bitweaver and SmartySmarty is wrapped in BitweaverThemes but neither code base is completely PHP8.4 friendly and I have added a few changes simply to shut the nannying up in VSCode. ckeditor is another key element which is unfortunately stuck in the past for a number of reasons. I use the source tab extensively as I am doing now, but this has become a chargeable option on the current builds, which is even more annoying. Making it compliant with Content Security Policy is going to be fun as well, but since only I have access to the editor currently I've only got CSP working while users are not logged in.

All the frilly bits are just icing on the cake, but actually things like 'short array format', 'bool ? true : false', 'array ?? default' and the rest do make the code tidier although there is still some conflict with indentation 'rules' which some third party libraries flag up at time. I prefer a 4space tab and retaining the tab characters which is how I have all the editors set and they tidy to that format ... hence the niggle with third party code ... The bitweaver code base is consistent with that even if out of sync with 'modern standards' which require expansion to space characters. That VSCode's assist when converting an array() element to a nicely formatted [ ] one when built over several lines is nice to see, and is expanded on at the PHPSurgery wiki. Although I have just spotted that ckeditor is messing up the <pre> blocks again :( Something else for the TODO list!

One area where I an perhaps at odds with VSCode is it's push to lower case things like false, true and null. It does make sense when added to the lower case string, array and so on in PHP, but when handling SQL scripts then the NULL is the right case, and while I had shut the nannying up by using NOTnull I've gone back to NOTNULL and will maintain upper case for SQL material. 

The modern 'rules' are enshrined in the PSR documents on PHP and I do perhaps need to revisit just where they are in relation to my own coding practices but to date I've not hit anything that is at complete odds with the rules I've selected in VSCode. I am sure there was a guild sheet on the bitweaver.org website, but I can't currently find it as 'search' is not working although a duckduckgo site search failed to find anything either.

Currently working through merging my current build with the bitweaver github base is throwing up a number of things that have been changed. Some I had remembered and others just need documenting to remind me.

1. Add namespace to class pages and use to pages that link to those classes. These replace the 'requires' lines for the relevant script.
   I have probably added namespace elements where they are not needed or perhaps missed ones that should be added. Some elements such as 'vd()' are now 'Bitweavervd()' which is a little cumbersome as is the 'KernelTools::tra()' in place of just 'tra()' and it's that sort of thing which puts me off namespaces.
2. In the past we did not need to worry about $notInitialized variables or $data['optional key']. In PHP8.4 these get flagged and sometimes where there is no $data array, the null value is reported where as in the past all were treated as 'null' or 'empty' quietly.
   As a result of this, many of the smarty templates have had to be extended with either a !empty($notInitialized) wrapper or alternately $notInitialized|default:'' to quiet the reports. This may not be the right way to handle the problem, but for now it's a functional fix.
   Also you can not just add extra variables on the fly, they need to be declared within the class even if they are rarely used. There is a switch to ignore that warning, which I've just deleted on a file but can't remember just what it was! (#[AllowDynamicProperties]) I have just been adding these to the relevant class as they arise.
3. Just a poke for me, putting back the {tr}{/tr} wrappers for elements that can be translated. This is part of the reason that justifies the time I am currently spending verifying differences between my own code and the github master.
   Actually I have notices quite a few places where additional wrappers may be appropriate but given the translation power within most browsers is it really necessary. Some bits may benefit from a more accurate translation, but on the whole the generic browser translation is good enough?
4. Another legacy change was to the names used for icons which I have already covered elsewhere link re silk icon set .
5.