After a number of false starts I now have a copy of the bitweaver code base which has a namespace setup that works for me, but is probably not 'right' for such services as composer. There is still some work to do and while 'traits' could have been useful, the idea of converting hundreds of possibly single line functions into classes just does not make sense to me. I've ended up with an extension for Smarty5 with all of the functions and modifiers managed through that but I still need to make the blocks classes accessible to the rest of the bitweaver code base. Something that has taken time is shutting up VSCode/DevsensePHP errors, warnings and nannying but although there are a few items still left to clean, the vast majority of the code is now PHP8.4 compliant. I have not worried about previous versions of PHP and to that end I've also stripped the legacy stuff such as upgrade code from now long out of data versions of bitweaver. The installer still needs a bit of work and there is still the thought about moving over to Bootstrap5 but the next step is to make sure everything used on the current live sites is working and move all of them over to what I am calling bitweaver5.

I did try to use Mistral Chatbot to help with tidying code, and while it was helpful at times, it's tendency to push the track that it has started gets annoying. I am quite happy to say that it lacks ANY demonstration of intelligence such as demonstrated by the failures to pick up things like the fact that PHP changed the rules on PCRE in version 7.3, something that would have triggered my own memory of why some functions were not working. That my current version of bitweaver is working on version 7.3, but at some point I HAD fixed the regex filters, a change that was not reflected back into the master code base. Mistral's 'help' converting the strings did not produce working solutions and I wasted time trying to work with it longer than I should have. regex101 is the place to debug all of this stuff and has been a lot more help. The key problem was the page name links in bitweaver content and now I have them working again and probably more important I understand just how bitweaver handles these via a number of filters, so not all a waste of time. My previous fixes had managed to avoid the how side of things.

VSCode has a number of irritating problems, such as it's complaints about the defining of constants dynamically which the bitweaver package system uses. I've had to manually add the path defines just to shut it up, but I need to investigate if there is a cleaner solution. The other thing that has actually been helpful is it's linking to the doc-block parameter information. Another area that still needs some more work to sort a 'standard', but being able to list elements used in the hash lists that bitweaver uses a lot is something I am taking time to tidy. One of the problem areas is the likes of {pagination} and {libertypagination}. Two solutions to the same problem and using different hashes of information to build them. I prefer the {pagination} style of working and have now established that only a few cases of {libertypagination} actually exist annoyingly in the same package that is also using {pagination} and my key image management tool. Outside that package only the boards one has a single usage which will be easy to replace.

Another step I've taken again is not the right solution, but is working. Mistral had suggested that the <package>_lib tool kits could be implemented as 'traits', but I'm not sure that is the right interpretation of these. I've ended up with another class full of static functions such as KernelTraits but the right thing to do with this is to rename it as KernelTools but having to add KernellTools:: before each function took a little time. There are similar tool kits in other packages which will at least allow me to remove a number of other 'require_once' instructions in the code base. I'm just trying to work out what to do with the key setup_inc.php file which is in effect the autoloader for bitweaver. I have a 'proper' autoloader for the package classes which also handles smarty and which I will add ADOdb in it's own namespace and I think the setup_inc loader could be handled via that route as well? Bitweaver\Setup seems to make sense, but currently IT loads the main autoloader ... chicken and egg problem.

Anyway back to sorting functionallity such as in the fisheye package although reworking that as photos as has been done in the main code base is now looking a sensible move even if it is still called 'fisheye' inside that package. I need a better way of managing the pdf archive and perhaps in an image gallery is not ideal although style sheets for library layouts are an easy addition to the fisheye package. The main target is to get bitweaver uploading the search layer in my current pdf library into the search package in bitweaver, even if my desktop tools do a good job of those searches locally. Being able to search from my tablet or phone is the target as is other areas such as my calendar information that Samsung/Google/Firefox makes such a bad job of ...