The British Caving Association

I'm inquiring as to whether you have any plans to update the version of PHP on the BCA server(s)? The current version is fine, as is 5.3, but 5.4 and upwards produce serious problems, esp for older Joomla based web sites. I've just had major problems with the peakspeedwell web site even when upgraded to use Joomla 1.5.26. (Fixed manually for the moment.) The problems are:-

1. PHP 5.4.n - E_STRICT standards are enforced by default and produce loads of error messages. You have to switch them off by manually insert a couple of commands in a couple of scripts. (Not too bad.)

2. PHP 5.5.n - mysql_ commands are depreciated and so produce loads of errors unless this reporting is switched off as well. Also the login scripts in Joomla 1.5.n use the preg_replace() function with the /e modifier which is disallowed in this PHP version, sigh. The mysql_ commands are going to be removed in a future version of PHP, not sure which though, but PHP 5.6 is out now!

This will effect the peak and northern cave monitoring web sites, also the DCA and the Darfar PC sites. Wayne Sheldon is also looking at migrating the peakspeedwell site to the BCA server next year too, which is also Joomla, though it might be to the latest version of Joomla. I should be doing that for him. I'll have to have a look around to see which version of Joomla is the earliest which doesn't suffer from these issues, though the peak site is a mambo site, so I'll have to check that too, sigh.

(There's no real need to upgrade PHP beyond 5.3 as long as all security updates have been applied.)

Thanx in advance.

Regards, Mel. DCA Webmeister.

Hi Mel,

No doubt you have see this already but for background see http://www.british-caving.org.uk/phpBB3 ... =31&t=1247 and in particular http://www.british-caving.org.uk/phpBB3 ... 1247#p1954

We are currently at PHP 5.2.9. The new server is 5.3.28 soon to be 5.3.29.

PHP 5.3.29 is already at end of life.

The process of migrating sites to the new server is slower than hoped and I'm taking piecemeal. Not withstanding several sites are now live on the new server and I hope the process will accelerate.

So to answer your question, I'm expecting all sites will be on the new server (5.3.29) by the end of the year. I would then move to 5.4 as soon as is practicable, probably in the new year. The move to 5.5 is a long way in the future.

The question is what is the best way to do this? The safest is the two server approach that I have done with the current upgrade. However that is expensive and those costs need to be passed on. The process needs re-thinking.

Currently my thoughts are:

1. Big bang. Upgrade on a fixed date with plenty of notice.
2. Two servers, as now with one live and one test, with a fixed deadline to control costs.
3. Two servers with a charge (@ cost) to use the test server.

Thoughts?

David Cooke wrote:I'm expecting all sites will be on the new server (5.3.29) by the end of the year. I would then move to 5.4 as soon as is practicable, probably in the new year.

Any update on that, Cookie? At the moment, the new site is unusable by any of my scripts and I need to know whether I should just move the sites somewhere else or whether I need to do a lot of work re-writing and editing my scripts. This is probably 100,000 lines of code and I would not like a deadline to be sprung on me at short notice! In summary the problems are...

• AddHandler application/x-httpd-php .html is apparently being ignored - I need html files to be parsed for PHP. Without this I will need to change and check every single page!
• Parameters error_reporting , error_log, display_errors. These are set "wrongly"in your current configuration . Placing them in .htaccess crashes the server in your current configuration. I can set them in scripts but that is a complete pain to have to do!
• Parameters: register_long_arrays, register_argc_argv, auto_globals_jit, magic_quotes_gpc. Same as above but these cannot be executed from PHP scripts.

When I say that some parameters are set "wrongly" I mean that they are either set to a insecure state (display_errors), or a state that is not helpful to the customer (error_reporting , error_log), or a state that results in a loss of performance of PHP (register_long_arrays, register_argc_argv, auto_globals_jit, magic_quotes_gpc).

My knowledge of Apache is minimal but I gather you have installed PHP in some "different" way to "usual", which means that some parameters cannot be set from .htaccess and possibly that there is no such thing as a php.ini file? Is that right? If so, what do you suggest is the way forward? PS: I dont want you to think there is any element of "ransom" here - if Im the only one causing a fuss, tell me to move my sites somewhere else