What happened to progress
It is now over ten years since I started playing with PHP as a replacement for the windows based system I'd been using up until then. We have been providing Enquirysolve to offices in the UK since the early 90's, initially with just hard wired terminals at each counter location ( government offices had not heard of computers in those days ;) ) but by the late 90's counters were being equipped with PC type terminals, so we migrated to client applications, and now the web based systems which still access the legacy hardware for information displays, announcements and counter call displays.
The first problem was finding a programming language, but this was something of a no-brainer at that time as PHP really had no competition. A situation that personally I think exists still today despite the roadblocks currently being erected. I was looking into PHP just as PHP5 came on line, but while I never installed PHP4, all of the code at that time was PHP4 based. In hindsight this was probably a wrong place to start as much of the current hassle is caused simply in bringing that legacy code into the current PHP coding style.
Our initial base picked up ADOdb very early on with a simple content management system re-engineered to access the legacy data. Since we have used Interbase since the early days, it's 'end of life' announcement by Borland in 1999 caused something off a panic which was quickly alleviated by the creation of Firebird and the open sourcing of the code base. Something that Borland quickly realised was a bad choice but had committed to before realising just how extensively used it was. While the PHP world may not think Firebird is popular, it has a heavy world wide user base in desktop applications and runs some extensive database systems. We have 20 years of data on some sites now stored in Firebird, so any web solution has to support that, which ADOdb does nicely. That original code is still running on some sites as what they want to do has simply not changed over the years. However the code will not run clean with E_STRICT mode enabled.
Having solved the short term web based problem, the next step was to move to an enhanced content management framework, initially for our own websites, but also as an enhancement to the Enquirysolve system. With the requirement for Firebird and being now used to ADOdb, tikiwiki was a package I started to play with. Some of the reasons are worth elaborating since recent developments are totally ignoring them!
At the time I was getting irritated with websites that had different logins and different editors for each of the entry screens, so what I was looking for was a framework that provides a single login, standard edit interface, and single styling system. At that time tikiwiki was looking nice and I spent a lot of time fixing areas that did not work with Firebird, but another area that caused problems was it's monolithic design. Adding my own packages to the framework was not easy, so the forking by some developers to create tikipro offered a nice path to give a cleaner install system. Following complaints from the tikiwiki team, the new project was renamed bitweaver. While not as well supported these days, a number of large systems have been forked from it and it is one of the few CMS systems that still supports Firebird, something that the now renamed tiki and a number of other packages no longer do. (Progress?)
A large number of the packages that used to be available in bitweaver are current stuck behind the roadblock that is E_STRICT. For many years, bitweaver ran as happily on PHP4 servers as it did on PHP5 and it's only recently that PHP5.2+ became a requirement, but I don't see anything that PHP has added that provides any improvement to my active sites. Many are still running on older versions of bitweaver and only need 'upgrading' because PHP no longer supports the older style of working cleanly. We have always run with 'display_errors' on and hiding warnings is simply not acceptable on production sites!