Jump to content

Php 5.3


Recommended Posts

Greetings,

 

On Friday May 6, 2011 at 9:PM EST, we are beginning phase one of our planned upgrade to PHP 5.3 on all shared/reseller servers. As always we are selecting one server for this upgrade, we then expect to complete a full roll out before the end of May. I will be updating the forum for the selected server shortly and Ryan will be updating this notice later tonight with some technical insight into this planned upgrade. Please see Ryan's follow up concerning the details of this update.

 

We will post in the Server Forum for each individual server at least one day in advance of any PHP updates. We will also post any relevant information via twitter.

 

Thanks for your time and let us know if you have any questions.

Link to comment
Share on other sites

As part of our commitment to maintaining our servers with the latest technologies available, we have developed an implementation of PHP 5.3 that also allows full retention of PHP 5.2 support. The deployment will make PHP 5.3 the servers default PHP handler and a simple htaccess option is available that provides the ability to revert to PHP 5.2.

 

However, in the interest of avoiding likely issues of sites breaking due to incompatibilities with PHP 5.3, what we will be doing is setting the htaccess option on all sites to force PHP 5.2 usage, which will effectively mean nothing will have changed for you compatibility wise. Then, when and if you decide that PHP 5.3 is something you would like to use or experiment with, you may remove the entry from your sites htaccess file.

 

During our installation of the combined PHP 5.3/5.2 setup, we will check to see if a .htaccess file exists under your users public_html ( /home/user/public_html/.htaccess ), if one does not exist, we will create it for you. Then, the new PHP 5.2 handler type will be added/appended to the .htaccess file ( AddType application/x-httpd-php52 .php ), this will force the account to utilize PHP 5.2, it will be inherited by all paths under your public_html

 

That is it! If at any time you want to test your domain with PHP 5.3, you simply remove the entry from the htaccess file -- if the content you are testing breaks, just re-add it and you will be back on 5.2. As always, if confused or in doubt about any of this, please reply here or open a support ticket and we will be glad to assist you.

 

PHP 5.2 handler type:

AddType application/x-httpd-php52 .php

 

PHP 5.3 handler type:

AddType application/x-httpd-php5 .php

 

TIPS:

- If you have the 5.2 type set in your public_html/.htaccess, and would like to test 5.3 on PHP scripts in, for example, public_html/test/, then you would create a public_html/test/.htaccess and add 'AddType application/x-httpd-php5 .php' to it. Now, the test/ path will be forced to 5.3.

 

- If you would like to have 5.3 as the default across your site, you only need to remove the 'AddType application/x-httpd-php52 .php' entry from public_html/.htaccess and the entire site will then default to 5.3. As with above , you can set the .htaccess in any specific path and add the 5.2 handler to force that version in just that path.

 

- For PHP options specific to 5.2 and 5.3, you can create php.ini files as needed in the applicable paths, for example, if you have the 5.2 handler type set under public_html/oldapplication/, you can drop a php.ini file into that path and its options will apply to PHP requests under that path.

 

Once again, the bottom line here is that, be default, everything will be transparent and PHP 5.2 will remain the version your sites run unless you explicitly remove the 5.2 handler from your .htaccess file. Further reading on features that have changed in PHP 5.3 can be found at: http://www.php.net/manual/en/migration53.deprecated.php

Link to comment
Share on other sites

  • 2 weeks later...

Not sure why but that .htaccess update broke my Drupal (v7) sites. The PHP class 'PDO' couldn't be found. I haven't the time to debug any further ATM, it may be peculiar to the rest of the .htaccess file. Fortunately my live site is small (the second is a test site) and I was able to do a quick test of 5.3 after commenting out the line that was added to my .htaccess file so I'm back up and running.

 

Perhaps you can take this tidbit into account for future upgrades since the approach has the opposite of the desired result - i.e. keeping my on a 'functional' 5.2 install until I could test 5.3.

Link to comment
Share on other sites

I really like the way in which the recent php 5.3 upgrade was done, giving us the option of continuing to run on 5.2 in order not to break scripts using functions deprecated or not supported in 5.3. However, I noticed something different about which I'd like to get some clarification.

 

In the .htaccess file of all of my sites, I had turned register_globals off. After commenting out the "AddType application/x-httpd-php52 .php" that was inserted in all of the root .htaccess files, I see that the

"<IfModule php_config>

php_flag register_globals off

</IfModule>"

 

is ignored.

 

I verified this running phpinfo() in that directory.

 

I can disable register_globals by inserting a local php.ini file in the root directory, but I am curious as to why I cannot do this via .htaccess when I am running php 5.3.

 

Any ideas?

Link to comment
Share on other sites

If we switch register_globals off with a local php.ini does this override the TCH server php.ini and all its directives . When checking my sites server info this seems to be what happens.

 

Does this mean it is best to copy TCH Server php.ini and just add our own entry to switch globals off?

 

Is this the best way, or would this slow the website down?

 

Does this local php.ini cover all directories below the top one?

 

Thanks for any advice and also for making this upgrade optional for now,so we have a bit of time to check our scripts.

Link to comment
Share on other sites

Do you need to define register_globals as off in 5.3? I thought by default it was off and was deprecated as of PHP 5.3?

 

OJB -- That's what I thought, but after switching one of my sites over to 5.3, I ran phpinfo(), and saw that it was on. So, apparently it must be turned on in the php.ini of the server.

Link to comment
Share on other sites

If we switch register_globals off with a local php.ini does this override the TCH server php.ini and all its directives . When checking my sites server info this seems to be what happens.

Yes, your php.ini file will override the server configuration.

 

Does this mean it is best to copy TCH Server php.ini and just add our own entry to switch globals off?

Yes, you should only add switches for what you want different then in the server php.ini file.

 

Is this the best way, or would this slow the website down?

Less is better.

 

Does this local php.ini cover all directories below the top one?

If you want it for your entire site put it in the root folder and it will work for 3 levels down (I think).

Link to comment
Share on other sites

I have two sites where the upgrade has resulted in the site failing to process .php files.

My browser says "You have chosen to open <blank> which is a: application/x-httpd-php52 from: <URL>".

Taking out the AddType line fixed the problem (presumably by using the new PHP).

Link to comment
Share on other sites

Is it possible that this upgrade is why I can no longer access ftp accounts, or create them? I tried in three different browsers (IE, Firefox and Safari), result is the same all commands are ignored.

Link to comment
Share on other sites

  • 1 month later...

Was MySQL upgraded to 5.1 at the same time as PHP was upgraded? Many, but not all, of my tables have been renamed with #mysql50# prepended. Can you please point me to the what, why, how, etc. My scripts are unbroken, but sorting of table names is messed up.

Link to comment
Share on other sites

  • 1 year later...

I've created a php.ini file in my root directory with the following entries:

 

 

magic_quotes_gpc = Off

display_errors = Off

 

This isn't working as both are still on according to phpinfo(). What needs to happen to get the server to read my php.ini file?

 

 

 

Yes, your php.ini file will override the server configuration.

 

 

Yes, you should only add switches for what you want different then in the server php.ini file.

 

 

Less is better.

 

 

If you want it for your entire site put it in the root folder and it will work for 3 levels down (I think).

Link to comment
Share on other sites

php.ini files only affect the directory they are in unless you set it site wide via .htaccess, It will also only affect php info in the same manner, as well as it will not affect the php info that is provided in cPanel itself.

 

Please let us know how deep you want the changes to affect and if you are using cPanel php info option to look for changes.

Link to comment
Share on other sites

What modifications need to be made to .htaccess to make it apply site wide?

 

 

php.ini files only affect the directory they are in unless you set it site wide via .htaccess, It will also only affect php info in the same manner, as well as it will not affect the php info that is provided in cPanel itself.

 

Please let us know how deep you want the changes to affect and if you are using cPanel php info option to look for changes.

Link to comment
Share on other sites

set the following in your .htaccess, adjust to your username and path to the php.ini you want to be global.

 

With php.ini in root of site

>suPHP_ConfigPath /home/CPANELUSER

 

OR with php.ini in public_html

>suPHP_ConfigPath /home/CPANELUSER/public_html

Link to comment
Share on other sites

Thanks. That worked! :rolleyes:

 

set the following in your .htaccess, adjust to your username and path to the php.ini you want to be global.

 

With php.ini in root of site

>suPHP_ConfigPath /home/CPANELUSER

 

OR with php.ini in public_html

>suPHP_ConfigPath /home/CPANELUSER/public_html

Link to comment
Share on other sites

×
×
  • Create New...