Page 1 of 1

Using PHP on the new server

Posted: Wed 02 Mar 2016 16:12
by David Gibson
Using PHP on the new Server: some points to note
A couple of people have asked me about this, so here is a summary of some of the points you need to bear in mind. This is based on various earlier postings of mine.

What are the differences?
  • A later version of PHP is now used
  • You may need to make a change to AddHandler, in .htaccess
  • You cannot use php_value or php_flag in .htaccess
A later version of PHP is now used
Using a later version of PHP can give rise to all sorts of subtle problems. These are (for the most part, it seems) documented at http://php.net but, of course, that is not of any immediate use. As and when I come across problems, I'll try to remember to post a note here. For the time being, here is some that caused me a lot of head-scratching...
  • In later versions of PHP, words that you have used as function names or array key names may become reserved. To avoid problems with array keys, make sure you quote key names, e.g. $array['key1'].
  • The behavior of some functions changes subtly between versions ; dirname() is one that I had problems with. Also, be wary of functions that can return (depending on circumstances) an integer zero or a boolean false as this behavior can change from version to version, as minor bugs are corrected.
  • Line Endings: this shouldnt happen on the BCA server, but Ive noticed it on ther servers. The default line-ending for text files depends on the server environment. Your code should check for PHP_EOL instead of "\r\n" or "\n" or whatever you "think" its going to be.
  • The function htmlentities() needs to be checked. You may be using it to display strings that contain the ascii pound symbol,\xA3. For example, htmlentities("\xA3") will return "£". But from PHP 5.4.0, UTF-8 is the default character set, instead of ISO-8859-1 and \xA3 is not a valid character in UTF-8 so – rather strangely – PHP returns an empty string instead of something more helpful! The solution is to replace, in your code, htmlentities($string) with htmlentities($string, ENT_COMPAT | ENT_HTML401, 'ISO-8859-1') for any string where there is expected to be 8-bit ASCII values.
You may need to make a change to AddHandler, in .htaccess
  • If you want HTML documents to be parsed for PHP you need to specify AddHandler application/x-httpd-php5 .html in your .htaccess file
You cannot use php_value or php_flag in .htaccess
If, like me, you use these directives to configure PHP then you will need to do it a different way. You can either...
  • Place these directives in a PHP script using the function ini_set(). Note:
    1. the syntax in ini_set() is different to that in .htaccess.
    2. Not all PHP directives can occur in a script so check the list at http://php.net/manual/en/ini.list.php
    3. You will need to run a script on every page that you need to configure. If, like me, you already do this in order to set heading and footing text, this is not a problem; otherwise, its a bit of a pain.
    4. Using ini_set() might not do all that you want. In particular, you are advised to ensure that the script containing that function contains no PHP errors that you might want to log or report. A simple way to achieve this is to use a very small script file, containing just the bare minimum of code; and to place the rest of your PHP code in a file that is loaded after ini_set() has run.
  • Specify a .user.ini file, on a per-directory basis, to hold a PHP configuration. Note:
    1. .user.ini is only available from PHP 5.3 (i.e. on the new server, but not on the old server)
    2. the syntax in a PHP .user.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 new (britiac3) server currently (5 Aug 2015) 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 a user types a single or double quote in their input, it will be processed differently. note, however, that some 'traditional' database software likes this directive set to ON, so this is rather a minefield!
  • 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 register_long_arrays 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 it to OFF, which is less efficient, but "safer". However, for new code, you should set it to ON because it seems that, for newer versions of PHP it mighjt be ignored and defaulted to ON. The effect of this directive being ON is that (e.g.) $GLOBALS['_SERVER'] will not exist until $_SERVER has been used. The solution to a strange, intermittent failure of your code, is to replace $GLOBALS['_SERVER'] by $_SERVER (etc.).
  • It is worth checking that the .htaccess directives +indexes and and -indexes really do work. I have known implementations that get this wrong. I think the BCA server is OK, but... its a security issue so it is worth checking.
Example of a .user.ini file

Code: Select all

; David Gibson, 4-Aug-2015
;
; PHP per-directory settings
; --------------------------
; These are set here, for servers where php_value and php_flag cannot be used 
; in a .htaccess file. 
;
; Note that some of these directives can be set from within PHP using ini_set(), 
; but NOT ALL of them! 
; See...
; Info on .user.ini:     http://php.net/manual/en/configuration.file.per-user.php
; Info on directives:    http://www.php.net/manual/en/ini.list.php
; Info on scope:         http://php.net/manual/en/configuration.changes.modes.php
;
; Not all these settings need to be made, as some are the default values
; but setting all of this here means that "you know where you are".

; allow_url_fopen        = On	; can only be set at a system level
  auto_globals_jit       = On
  date.timezone          = "Europe/London"
  display_errors         = Off
  error_log              = <<insert the full path to your error log>>
  error_reporting        = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
  log_errors             = On
  magic_quotes_gpc       = Off
  max_execution_time     = 30
  max_input_time         = 60      ; set to 7200 or -1 (?) for HE video uploads
  memory_limit           = "64M"   ; set to 501M for Hidden Earth video uploads
  open_basedir           = ""
  post_max_size          = "8M"    ; set to 501M for Hidden Earth video uploads
  register_globals       = Off
  register_long_arrays   = Off
  register_argc_argv     = Off
  session.serialize_handler = "php" 
  short_open_tag         = On
  upload_max_filesize    = "2M"    ; set to 500M for Hidden Earth video uploads
  user_agent             = "";

; for Development pages over-ride the above with...

  display_errors         = On
  error_reporting        = E_ALL

Re: Using PHP on the new server

Posted: Sun 17 Apr 2016 13:08
by David Gibson
Hi Cookie, I think Im ready for you to move the Hidden Earth site onto britiac3 (No rush of course - it can wait another year :-). When you have flipped the switch, could you let me know straightaway (by text) so that I can do a full test?
I cannot test it at britiac3.miniserver.com because the server does not form the correct URIs for hyperlinks and - importantly - for script files that need to be loaded. (So the pages look badly-formatted because some of the formatting is applied via JavaScript). However, Ive put it all on my sandbox site and it seems to work.

I managed to get the files to a state where - in theory at any rate - they could be transferred to the new server without modification. (The problem being that php directives cannot go in .htaccess on the new server, but cannot go in a .user.ini file on the old server either). The final problem - which taxed me for ages - was that I tried to use an <IF> directive in .htaccess to make it do the correct AddHandler instruction, dependant on the server, so that all the files were identical for both servers. It took me ages to work out why it wasnt working - turns out that Apache 2.2 doesnt support <IF>. How absolutely stupid is that?

Re: Using PHP on the new server

Posted: Sun 17 Apr 2016 13:32
by David Gibson
Hmmm. Now that's odd. britiac.miniserver is not parsing my .user.ini file, but on my sandbox server (on britiac3) is IS parsing it.

Re: Using PHP on the new server

Posted: Wed 25 May 2016 10:34
by David Gibson
David Gibson wrote:Hmmm. Now that's odd. britiac.miniserver is not parsing my .user.ini file, but on my sandbox server (on britiac3) is IS parsing it.
Thanks for doing the switch-over, Cookie. My .user.ini file is now being parsed, so the problem quoted above must be specifically do do with access via the miniserver domain. But, as I said earlier, it doesnt always parse everything correctly in any case.