PHP 5.3 Support

[GatorJacob]

Hello,

We currently offer PHP 5.3 support on our shared servers as an addition with PHP 5.2. In order to utilize PHP 5.3 on your domain, place the following code inside the document roots .htaccess file:

Action application/x-hg-php53 /cgi-sys/php53
AddType application/x-httpd-php53 .php

Thanks Richard for the below information:

CAUTION: For those who use the cPanel "QuickConfig" feature, it should be noted that it works by putting a php.ini copy into the /home/username/ folder and setting the suPHP_ConfigPath in your primary .htaccess file to point to that copy.

Because the "QuickConfig" php.ini copy is originally based on the php.ini file that is installed as part of the server's setup for its default PHP version, there may be serious problems if the user subsequently decides to use some other PHP version. The php.ini copy pointed to by the suPHP_ConfigPath that "QuickConfig" sets may contain configuration paths, extensions and other settings that are not suitable for a PHP version that is chosen thereafter. It may even be missing some settings required by the newer version entirely.

As just one of many examples of problems that can thus arise, the PHP 5.3 option discussed by GatorJacob as the topic of this thread differs from PHP 5.2 in the server path that is used for its extension modules --
PHP 5.2: extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613"
PHP 5.3: extension_dir = "/opt/php53/lib/php/extensions/no-debug-non-zts-20090626"

So, if you've used cPanel's "QuickConfig" to set up or modify your PHP configuration, get rid of its php.ini copy and the suPHP_ConfigPath pointer to it that "QuickConfig" puts in your primary .htaccess file before implementing any PHP version change!

Here is a generic fix for the TZ issue

PHP Code:

// Force PHP 5.3.0+ to take time zone information from OS
if (version_compare(phpversion(), '5.3.0', '>='))
{
    @date_default_timezone_set(date_default_timezone_get());
}

Please do let us know if you see any problems

[alice]

***I Posted another post before I saw this. Below is an error that I see.***

There is a well know bug in PHP 5.3 that causes errors when using TimeZone functions. When I tested 5.3 a few minutes ago I got this error. The errors will look roughly like this:
PHP Warning: PHP Startup: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Asia/Calcutta' for 'IST/5.0/no DST' instead in Unknown on line 0

The PHP.ini file needs to have the following entry:

In the PHP.ini:

[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = America/Chicago

[alice]

In ".htaccess" I added the following per instructions:
Action application/x-hg-php53 /cgi-sys/php53
AddType application/x-hg-php53 .php

5.3 was confirmed running.

In one of my modules I had the following date code to display date:

<?php echo date("F j, Y, g:i a"); ?>

After 5.3 change I started receiving the following errors:

strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier.

After researching the error I added the following entry to my .htaccess that allows me to point to my own php.ini file (I placed a tested 5.3 php.ini file in the directory):

suPHP_ConfigPath /home/myname/php

The php.ini file included this entry:

[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = "America/Chicago"

***Error continued.

Finally, I added this line of code in the module that contains the erroring date function:

<?php date_default_timezone_set('America/Chicago'); ?>

***PROBLEM SOLVED!

I thought I would leave this here in case someone else encounters the same problem (and they will).

[virtvir5]

CAUTION: For those who use the cPanel "QuickConfig" feature, it should be noted that it works by putting a php.ini copy into the /home/username/ folder and setting the suPHP_ConfigPath in your primary .htaccess file to point to that copy.

Because the "QuickConfig" php.ini copy is originally based on the php.ini file that is installed as part of the server's setup for its default PHP version, there may be serious problems if the user subsequently decides to use some other PHP version. The php.ini copy pointed to by the suPHP_ConfigPath that "QuickConfig" sets may contain configuration paths, extensions and other settings that are not suitable for a PHP version that is chosen thereafter. It may even be missing some settings required by the newer version entirely.

As just one of many examples of problems that can thus arise, the PHP 5.3 option discussed by GatorJacob as the topic of this thread differs from PHP 5.2 in the server path that is used for its extension modules --
PHP 5.2: extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613"
PHP 5.3: extension_dir = "/opt/php53/lib/php/extensions/no-debug-non-zts-20090626"

So, if you've used cPanel's "QuickConfig" to set up or modify your PHP configuration, get rid of its php.ini copy and the suPHP_ConfigPath pointer to it that "QuickConfig" puts in your primary .htaccess file before implementing any PHP version change!

[alice]

Originally Posted by virtvir5

CAUTION: For those who use the cPanel "QuickConfig" feature, it should be noted that it works by putting a php.ini copy into the /home/username/ folder and setting the suPHP_ConfigPath in your primary .htaccess file to point to that copy.

Because the "QuickConfig" php.ini copy is originally based on the php.ini file that is installed as part of the server's setup for its default PHP version, there may be serious problems if the user subsequently decides to use some other PHP version. The php.ini copy pointed to by the suPHP_ConfigPath that "QuickConfig" sets may contain configuration paths, extensions and other settings that are not suitable for a PHP version that is chosen thereafter. It may even be missing some settings required by the newer version entirely.

As just one of many examples of problems that can thus arise, the PHP 5.3 option discussed by GatorJacob as the topic of this thread differs from PHP 5.2 in the server path that is used for its extension modules --
PHP 5.2: extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613"
PHP 5.3: extension_dir = "/opt/php53/lib/php/extensions/no-debug-non-zts-20090626"

So, if you've used cPanel's "QuickConfig" to set up or modify your PHP configuration, get rid of its php.ini copy and the suPHP_ConfigPath pointer to it that "QuickConfig" puts in your primary .htaccess file before implementing any PHP version change!

Richard, Thanks for posting this explanation for problems relating to the use of PHP 5.3. I encountered this problem and we worked through it until my problems were resolved.

This is certainly a problem when using any form of the 'date ()' functions.

Thanks again...Alice

[virtvir5]

You're both welcome, Jacob and Alice.

Yes, that was almost certainly the source of your problem, Alice. The shared server php.ini defaults for PHP 5.2 (copied by "QuickConfig") include no setting at all for date.timezone as required by PHP 5.3 to avoid the problem that you saw.

I believe that HG has since included a date.timezone setting in their shared servers' php.ini for PHP 5.3, but that doesn't help if a user's php.ini has already been set up by cPanel's "QuickConfig" based on the original default PHP 5.2 configuration.

HG could avoid that particular problem by adding a default date.timezone to their servers' original PHP 5.2 set-up also, but that alone wouldn't solve all the other many differences between the php.ini-production reqirements for the two versions. As with many other such site mangement issues, individual understanding of the actual configuration process is and must remain the best answer.

Just gotta love cPanel's marvellous "Site Hosting Management" toys ... NOT! And yes, I know I'm a cynic.

[CypherOz]

Here is a generic fix for the TZ issue

PHP Code:

// Force PHP 5.3.0+ to take time zone information from OS
if (version_compare(phpversion(), '5.3.0', '>='))
{
    @date_default_timezone_set(date_default_timezone_get());
} 


[GatorJacob]

Thanks Cypher! I hope you don't mind that I added it to the first post

[CypherOz]

Originally Posted by GatorJacob

Thanks Cypher! I hope you don't mind that I added it to the first post

No problems!
That code should be very early in you php execution, typically in your init/bootstrap require_once code.

I've noticed that when using PHP 5.4 via the .htaccess hack it needs two processes to run per page hit...

/bin/bash php53 
/opt/php53/bin/php-cgi

Does this affect the 25 process limit?

When will 5.3 become the default and 5.2 as an option (or dropped) on shared servers?
given that PHP 5.2 is officially unsupported by php.net

Thanks!

[CypherOz]

A couple of other PHP 5.3 clues...

The ereg (regex) functions are deprecated in preference for the preg (PCRE) functions.
See: http://docstore.mik.ua/orelly/webprog/pcook/ch13_02.htm

1. Change the ereg matching string to have delimiters and use the PCRE preg functions:

Eg:

PHP Code:

$schema = ereg_replace(",\n$", '', $schema); 


becomes:

PHP Code:

$schema = preg_replace("/,\n$/", '', $schema); 


Another example:

PHP Code:

ereg('pattern', 'string'); 


becomes:

PHP Code:

preg_match('/pattern/', 'string'); 


2. Change split() to either explode() [faster] or preg_split() for regex splits.

Eg a simple split:

PHP Code:

$str = split("\n",$my_text); 


becomes:

PHP Code:

$str = explode("\n",$my_text); 


And a PCRE example:

PHP Code:

$pieces = split('[[:space:]]+', $search_str); 


becomes:

PHP Code:

$pieces = preg_split('/[[:space:]]+/', $search_str); 


[HalbrookTech]

So, ran in to some issues related to date.timezone, Quick Config and Zikula 1.3.0-beta3 which requires 5.3.2.

I set php 5.3.2 in the .htaccess, and the installer runs, so that's working, but the installer checks date.timezone, and it's NOT set for 5.3.2 by default, so used quick config to setup a local php.ini and the installer now reports that PDO extensions are not loaded. That means the custom php.ini is missing SOMETHING, but what? Oh, and the date.timezone settings aren't in the PHP.ini either.

[HalbrookTech]

Okay, so an update to the issue. I searched on the error I was getting, it tells me what needs to be added to the php.ini, but the lines are in there, and when i make the php.ini just

magic_quotes_gpc = Off
extension=pdo.so
extension=pdo_mysql.so
date.timezone = "America/Chicago"

It loads fine, and all those lines are in the local php.ini, in the case of the date.timezone, manually inserted. Gonna start commenting out lines until the error goes away, but seems strange to me that this is happening.

[HalbrookTech]

Found another gotcha that will affect any resellers using WHMCS, need to change the ioncube loader in the custom php.ini to use the 5.3 loader instead of the 5.2 loader, otherwise WHMCS doesn't work right.

[scottie]

Hi. I added the two lines to .htaccess to enable 5.3 and got the following error messages with one of my scripts:

Warning: include(Mail.php) [function.include]: failed to open stream: No such file or directory in ...
Warning: include(Mail/mime.php) [function.include]: failed to open stream: No such file or directory in ...

How can I include Pear Mail in PHP 5.3? Thanks!

[roman2]

Hi,

I've made changes to my .htaccess file and got PHP 5.3 working. However, PDO extensions aren't loaded. What else do I need to do to have this resolved?

Can there be a document in the knowledge base and a post on this forum with a complete set of instructions on how to quickly and easily activate PHP 5.3 fully, without having to roam through forums or involving the support serivice? I imagine this would be in the interests of HostGator too (via saving on support service).

[GatorGPineda]

If PDO extensions are not loading please check and make sure that you do not have a custom php.ini that might be being loaded. If you do, most likely the extension settings for it are going to be for php 5.2.17 which is the default in our servers. This would cause PHP extensions for 5.3 not to load as the extension_dir is not the same. If there are no custom php.ini that might be interfering please open a support ticket with us as this would indicate a server side issue with the php 5.3 installation.

[roman2]

I spent about 2 hours with two chat support people trying to have this resolved. The second one was more responsible and committed to fixing it. It's turned that I had a php.ini above public_html, and it was affecting all of my domains. (I needed to use PHP 5.3 only on one of my add-on domains.)

He moved it inside public_html and placed a new php.ini to my add-on domain, and things started to work as expected. However, having read your reply to me here, I renamed the new php.ini and verified that it's not needed.

You know, spending 2 hours on something basic like this is excessive. I would like HG to train its support personnel in a way that would allow support people to resolve things like this within 5 minutes.

[roman2]

The imagick extension doesn't seem to be enabled in PHP 5.3. Is that an omission on the admins' side or do I have to do something special in order to enable it? (We have it enabled in PHP 5.2.17.)

Using a shared server.

UPDATE: got this resolved by contacting the support service.

[Dusan Zervan]

Do I understand well that it is not possible to use own php.ini (using suPHP_ConfigPath) now with PHP 5.3? When will you change PHP version to 5.3 (or 5.4) by default?

[Dusan Zervan]

Originally Posted by Dusan Zervan

Do I understand well that it is not possible to use own php.ini (using suPHP_ConfigPath) now with PHP 5.3?

It seems it is working, but it is necessary to use /opt/php53/lib/php.ini as base (and make modifications).

[virtvir5]

Jacob: When I wrote my cautionary note (below) that you included in your own instructions on configuring the suPHP set-up for using the PHP v5.3 option, I was quite sure that I understood the underlying methodology. Has any of it changed recently?

HostGator's TOS Monitoring techies are now complaining about my own php.ini set-up and its "associated database" -- whatever that means -- causing excess usage problems on Gator734. I don't see it myself (see attached cpu usage record) but I do suspect some possible malicious intrusions recently. Your comments would be much appreciated.

Originally Posted by virtvir5

CAUTION: For those who use the cPanel "QuickConfig" feature, it should be noted that it works by putting a php.ini copy into the /home/username/ folder and setting the suPHP_ConfigPath in your primary .htaccess file to point to that copy.

Because the "QuickConfig" php.ini copy is originally based on the php.ini file that is installed as part of the server's setup for its default PHP version, there may be serious problems if the user subsequently decides to use some other PHP version. The php.ini copy pointed to by the suPHP_ConfigPath that "QuickConfig" sets may contain configuration paths, extensions and other settings that are not suitable for a PHP version that is chosen thereafter. It may even be missing some settings required by the newer version entirely.

As just one of many examples of problems that can thus arise, the PHP 5.3 option discussed by GatorJacob as the topic of this thread differs from PHP 5.2 in the server path that is used for its extension modules --
PHP 5.2: extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613"
PHP 5.3: extension_dir = "/opt/php53/lib/php/extensions/no-debug-non-zts-20090626"

So, if you've used cPanel's "QuickConfig" to set up or modify your PHP configuration, get rid of its php.ini copy and the suPHP_ConfigPath pointer to it that "QuickConfig" puts in your primary .htaccess file before implementing any PHP version change!

[virtvir5]

P.S: Just in case anyone left at HG still gives a damn about such things, somebody (HG? Google?) has screwed up the CPU Usage view graph utility on the Gator734 server’s cPanel. It was working yesterday when I used it to attach my CPU Usage image attachment to the preceeding post. Now it's not. The javascript error is as follows:

Message: Every row given must be either null or an array.
Line: 53
Char: 63
Code: 0
URI: https://www.google.com/uds/api/visualization/1.0/4da66c523f1d12b8ccaa094c46341418/format+en,default,corechart.I.js