ESTERDAY I ranted about PhpWiki, blaming PHP for the most part. Why? My Web host has ‘broken’ a lot of the software that I run in this Web site. Some software has relentlessly and happily been running for a decade or more. It is a lot of software (all in all about 20 databases), some of which I have manually patched or changed/hacked whenever the host upgraded PHP. It is a lot of work. It is a lot of inevitable maintenance. I blame PHP. The latest upgrade is to PHP 5.3. The host reverted back to the older version (5.2) for two weeks (a sort of an ultimatum) to help me sort things out before this upgrade is permanently imposed. PhpWiki was not the only cause of issues, but it was part of it that took a whole noon plus afternoon (almost as much time as it would take to just rebuilt it all manually). While I was able to (eventually) make a minor upgrade (from a 2006 version to a 2008 version, not to the current or even recent versions) it remains unclear why PHP decided to not be backward-compatible. It is a total nightmare for sites for have a lot of PHP code, especially if their maintainers are not full-time PHP developers or are ingratiating components of software which is no longer actively maintained. PHP is risky to choose or work with. I learned this the hard way. It may be normal for proprietary frameworks to do this, but why FOSS?

Today I successfully upgraded two PHP-Nuke sites (thankfully there were upgrade scripts which worked reasonably well) and then I struggled for a whole with Gallery 2, where the upgrade process is complicated and very long, resulting in a sub-optimal outcome (e.g. no thumbnails and no tolerance of a perfectly fine ImageMagick installation). People without very advanced knowledge of UNIX and other such skillsets won’t manage to keep their photo galleries up to date. This is a real travesty. This is the catalyst of ‘Web rot’.

What I’ve identified and am eager to summarise after two days of frustrating work is this:

1. PHP-based software cannot be counted on, especially if it’s intended to run for years (the long run)
2. Choosing less established PHP-based software is risky as it might cease being maintained
3. cPanel does give access to PHP error logs, but this is not too trivial to find
4. Internal server errors can be due to restrictive Web hosts who deny access to scripts based on their UNIX-style permissions
5. It is always better to install software from front-end scripts, such as those found in Fantastico
6. Don’t use too many pertinent bits of software; diversity can be a nightmare to deal with
7. When patching existing software, keep a log/record of everything that has changed
8. If a lot of people across the Web complain about upgraders, importers, exporters, etc. then it’s better not to bother with them at all as they won’t work correctly and just waste time
9. Check carefully and exhaustively a good test set of data following upgrade, or missing data will only be identified several years down the line when backups are too hard to find and revert to (I just found out that this happened to me)
10. Use static HTML where you deem it suitable because the cost of maintaining/upgrading PHP is often too high to justify such a reliance

I am fed up with PHP. One cannot just install something and let it run along for years. It’s a lot of work to maintain and sometimes there’s loss of data, induced by improper upgrade paths and mistakes/accidents.

 Add your comment(s) |  Send this to a friend

This entry was posted on Sunday, June 1st, 2014 at 3:58 pm and is filed under Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.