Version Updates to MySQL, PHP & Apache

[David Cooke]

It is proposed to update the webserver software to the following versions by 1st June 2014.

• PHP 5.4.26 (5.2.9)
• MySQL 5.5 (5.0)
• Apache 2.4.7 (2.2.26)

The current version is shown in brackets.

BCA will shortly provide a server configured with the latest versions for testing purposes.

It would be useful if webmasters could check their websites and report below if they expect significant compatibility issues.

[David Gibson]

It would be useful if webmasters could check their websites and report below if they expect significant compatibility issues.

That is easier said than done! Last time there was a change in PHP version - I think it was when I transferred the BCRA web site to this server - the repercussions went on for months. Obscure things like ... some variable names that I used were now reserved words; a function returning an empty string now returned a logical value; a function given an empty string as an argument now did something different. It literally took months to be sure I had fixed all the problems. However, that might have been because my code was running under PHP 4 originally. Hopefully, this time, the effects will be smaller? I realise it "has to be done" but it is a distinct nuisance, all the same. I have a small PHP program that I use on localhost, which counts the total number of lines of PHP code on my web sites. It is reporting...

• bcra.org.uk, 19783 lines in *.php at PHP Version 5.2.9, Apache/2.2.26 (Unix)
• hidden-earth.org.uk, 2953 lines in *.php at PHP Version 5.2.9, Apache/2.2.26 (Unix)
• localhost, 2963 lines in *.php at PHP Version 5.3.2, Apache/2.2.15 (Win32). (that's the code for the Hidden Earth timetable)
• site2.caves.org.uk, 10739 lines in *.php at PHP Version 5.2.6-1, Apache/2.2.9 (Debian). (code waiting to be transferred to the BCA server)
• caves.org.uk, 7822 lines in *.php at PHP Version 5.3.3-7, Apache/? (code waiting to be transferred to the BCA server)

Those *.php files are "all" PHP, since my convention is for the web pages to retain the *.html extension but to be parsed for PHP. So.... not a quick job to check all that

[David Gibson]

AAAGH!!!! - More extreme frustration caused by version updates.

Here are some more examples of problems you may face when someone goes and 'upgrades' your server. Im into my third day of trying to debug code that has been moved onto a new server. Just to be clear - this does not involve the BCA server, but it could easily do so

1) My PHP code uses HERE docs, and makes other uses of strings that include line endings. The server has, for some reason, changed the default line ending so where I happen to test for line endings, my tests were failing. Admittedly, I should have been using PHP_EOL instead of testing for \r\n but, nevertheless - my code WAS working, and then it WASNT. And that's bad, for a supposed "upgrade".

2) I was using the function htmlentities() to display strings that contained the pound symbol,\xA3. But from PHP 5.4.0, UTF-8 is the default character set, instead of ISO-8859-1. \xA3 is not a valid character in UTF-8 so - rather strangely - PHP returns an empty string instead of something, shall we say, "more helpful". I Now need to say ... htmlentities($string, ENT_COMPAT | ENT_HTML401, 'ISO-8859-1') instead of htmlentities($string);

3) Another really weird one is that PHP5.whatever does not seem to be responding to the auto_globals_jit flag. I can set it and clear it, and it gets set and cleared; but PHP seems to ignore the setting. This means a lot of code rewrites. OK, so the code is rather old (2007) and one cannot continue to live in the dark ages, in the face of technological breakthroughs like an upgrade from PHP4 to PHP5, but this does highlight that upgrading code is not a simple business.

[David Cooke]

I know it is a pain, I really don't have the time at the moment either but unfortunately it must be done since there are security implications in not doing so.

The astute will have notice the deadline is upon us. From the feedback I've had and issues with the test server I'm going to move it back to the 1st July. I'm also going to aim for php version 5.3.27. I think version 5.4 is too big a step at the moment but that will follow on as soon as practicable. Apache and MySQL will still be upgraded to the versions previously mentioned.

I was hoping to have a test server at no cost to BCA but that has not panned out, so for a limited time BCA will pay for one. More details on that to follow shortly.

[David Gibson]

I'm also going to aim for php version 5.3.27. I think version 5.4 is too big a step at the moment but that will follow on as soon as practicable.

My problems, above, were in moving from 5.2.6 to 5.5.9. I think 5.4 is where the big changes are.

I was hoping to have a test server at no cost to BCA but that has not panned out, so for a limited time BCA will pay for one. More details on that to follow shortly.

From the experience Im having at the moment, I think a test server is essential [Im using one now, for the situation I referred to above]. But how many BCA customers are we talking about here? If Im your "biggest" and "most awkward" customer, it might make sense for me to move my scripts back to Gradwell where I can select the version of PHP I want to use. I can then spend some non-critical-path time updating them.

There are simply loads of possible pitfalls in upgrading PHP - subtle problems that might not appear for months. One, which caught me recently is (IIRC) that some functions in PHP that used, on occasion, to return an empty string or a zero, now return "false" . A significant difference. OK, possibly only if one is using imperfectly-written code but.... that's my code!

Should I prepare to move my scripts?

PS You do realise that Im someone who still uses Microsoft Office 97 in preference to later versions; and who has no plans to upgrade from XP?

[David Gibson]

Hi Cookie, a further progress report...

I have been doing some testing on the new server and, for my sites, there are a number of hurdles we need to get over before I can even start to test the PHP code itself. Im thinking that a suitable stop-gap might be to move all my code onto another server, but it depends what your timescales are and how easily you can accommodate my required settings. I have set up a web page that demonstrates the problems - just ask me for the URL. In summary the problems are...

• The DirectoryIndex directive is apparently being ignored in my .htaccess file, so I cannot specify that index.html is a default for 'no file' in the URL.
• The AddHandler directive is apparently being ignored in my .htaccess file, which means that I cannot specify that HTML pages are to be parsed for PHP. (We had this discussion a long time ago, when you commented that this was 'inefficient'. However, because the vast majority of my HTML pages actually execute PHP to provide headers and footers, this argument does not hold true on my sites).
• Attempting to execute php_value or php_flag in my .htaccess file results in a 500 Internal Server Error. I need these directives to ensure that PHP is configured correctly. Viz...
• In the .htaccess file, I cannot initialise error_reporting , error_log or display_errors. You have these parameters set to 'unsuitable' values for code development. As a work-around, these three parameters could be set from within a PHP script, but it would need to be run on every single page - better if they could be set in .htaccess.
• In the .htaccess file, I cannot initialise register_long_arrays, register_argc_argv or auto_globals_jit. These parameters cannot be set from within PHP so the above work-around cannot be made. In the case of the first two, it is not a particular problem, but having them ON means that auto_globals_jit is ignored (i.e. OFF). Not being certain of the state of auto_globals_jit can give rise to subtle problems. I prefer to set it to ON, which requires register_long_arrays (etc) to be disabled or OFF.
• In the .htaccess file, I cannot initialise magic_quotes_gpc . This parameter cannot be set from within PHP so the above work-around cannot be made. This parameter is now deprecated and will be removed in future versions of PHP. It is set to ON on the new server whereas my code now expects it to be 'off'. On the web page I mentioned above, I have included a demo of the problem that is caused by having it ON. However, its true to say that because the PHP default is ON, a lot of 'bought-in' code will probably expect this parameter to be set - but that is just storing up problems for the future.

[Scmc_Kelvin]

Hi Cookie,

Just wondering how things are progressing with the system update?

Only asking because went to create a new MySQL database and get the warning that it is still working on 5.0.

Cheers

[David Cooke]

Hi Kevin,

It is ready to go, but I need to write out a set of instructions for the webmasters rather than talk to each one individually.

I'll get back to you after Hidden Earth - or find me there if you are going.

[dbenmore]

Hi,

Have the instructions been sent out yet?

I'm trying to implement some new features to the mnrc website but cannot due to an outdated php version.

Thanks,
Dan

[David Gibson]

• The DirectoryIndex directive is apparently being ignored in my .htaccess file, so I cannot specify that index.html is a default for 'no file' in the URL.

Magically, that is now working

• The AddHandler directive is apparently being ignored in my .htaccess file, which means that I cannot specify that HTML pages are to be parsed for PHP.

You told me, Cookie, to use AddHandler application/x-httpd-php5 .html, which works!

• Attempting to execute php_value or php_flag in my .htaccess file results in a 500 Internal Server Error. I need these directives to ensure that PHP is configured correctly.

It turns out that, from PHP 5.3 (IIRC) you can specify a .user.ini file, on a per-directory basis, to hold a PHP configuration. This gets around all the problems we've been discussing over the last 12 months, Cookie! One needs to bear in mind that the syntax in a PHP .ini file is different both to that of .htaccess and that required for the ini_set() function.

The following points should also be noted...

• The britiac3 server currently sets display_errors to ON. For britiac2 this parameter was unset. Displaying PHP errors on a production web page is frowned upon, so users might wish to use .user.ini to set this parameter to OFF
• magic_quotes_gpc is set to ON, on both servers. However, this setting is deprecated and magic_quotes_gpc is removed in PHP 5.5. Users should consider getting into the habit of setting this parameter to OFF, or else, during the next upgrade, you are likely to encounter some surprises. E.g. if you have an html FORM and users type single or double quotes in their input, it will be processed differently.
• auto_globals_jit is set to ON, on both servers. However, this setting is prevented from operating because register_long_arrays is also set to ON - in other words, it is as if auto_globals_jit = OFF. However register_long_arrays is deprecated and is removed in PHP 5.5. Users should consider getting into the habit of setting this parameter to OFF, or else, during the next upgrade, you are likely to encounter some surprises. The issue concerning auto_globals_jit is rather a subtle one. The safest thing to do - for legacy code - is to set auto_globals_jit = OFF, which is less efficient, but "safer". For new code, you should avoid referring to $GLOBALS['_SERVER'] and similar superglobals (ENV and REQUEST).

So, with those two simple tools - AddHandler and .user.ini - I can start to move my code to the new server!