I recently moved one of my sites to a new VPS server. The migration was not so smooth. I faced a lot of problem which made me understand the issues that could arise out of minor configuration changes between the old and new web servers. This article “6 reasons why PHP sites show errors after server migration”, is a compilation of what I learned (and researched a bit after that) because of the migrating experience.
1. PHP Handler
I am keeping this reason at first, intentionally. Because developers don’t track down to PHP handlers until they are exhausted of all other ways of trying to fix the errors. Basically, as the name suggests, PHP handlers are responsible for loading PHP programming libraries and interpreting your PHP code to generate the requested page for visitors. Each PHP handler has its own way and file structure for loading PHP libraries and interpreting PHP code. Before I explain how PHP handlers will make an impact in this scenario, I will give you short description about each of the PHP handlers.
Fast CGI or FCGI is the most popular PHP Handler. Fast CGI delivers high performance when compared to other PHP Handlers. So Fast CGI becomes a natural choice for websites that expect high traffic volume and performance. When running with Fast CGI handler, scripts will run under the cPanel user to whom the script’s ownership is mapped. This makes it more secure than any other PHP handlers.
suPHP is abbreviation of single user PHP. It runs PHP as a CGI module. suPHP’s security feature blocks you from executing other users’ scripts that are hosted on the same server. This is a great advantage for sites running on shared hosting, where hackers try to compromise other accounts through the cPanel accounts they own on the same server. Apart from this, world writable PHP scripts are not interpreted for security reasons and scripts are run only under the user who owns them. In spite of these advantages, most people still prefer Fast CGI because suPHP doesn’t support opcode cache and it runs high CPU load.
CGI stands for Common Gateway Interface. CGI PHP handler runs PHP as a CGI module. Scripts are executed under the default Apache user “nobody“. So the server administrator or scripts will not know who is running a script. suEXEC module can be enabled to know under which user a script is running. But doing this will not solve security vulnerabilities of CGI handler. Also CGI PHP handler delivers poor performance when compared to other handlers. PHP file uploads scripts will because of file permission issues.
Dynamic Shared Object (DSO) is pretty similar to CGI but it run PHP as a Apache module. DSO also runs scripts under the “nobody” user. Since scripts under every account will be run only under “nobody” user, scripts are literally executable by any user /cPanel account owner on the same web server by emulating the required file permission. Files created are not readable from the web. So PHP file upload scripts will fail. If you are running a WordPress site, media uploads, automatic updates may fail because of the file permission issues.
Thats about the PHP handlers. The changes in file permissions, settings in default php.ini files created by some PHP handlers for each directory and absence/presence of required/inessential modules may be the reason why scripts throw errors on the new server. Note: You can also have different handlers for different versions of PHP. For example: you can set to handle php 5.3.0 by suPHP and php 5.4.0 by Fast CGI.
2. PHP Version
PHP versions have major differences between each other. Code written for one version of PHP may not work as intended on other versions. This is because PHP functions are deprecated every now and then for security and other reasons. If one or more function(s)/features used in your code are deprecated in the PHP version installed on your new web server, it will throw warnings. You can disable these warnings to make your code work properly. But this is risky, because after a while, these deprecated functions will be completely removed from PHP. For example, features like
magic_quotes_gpc are deprecated from php 5.3.0 and completely removed from 5.4.0 . So your code will no longer work. So its good to rewrite your code for the newer version of PHP installed on the new web server. In cases where you can’t modify the code, you can downgrade the PHP version on the new server to match that of your old server.
3. Server Timezone
If your new web server’s timezone is different from that of your old web server, then you might run into logical errors. This is more dangerous than PHP errors. You can run
<?php echo date_default_timezone_get(); ?>
to check the default timezone of the new web server. If it is not same as the old web server’s timezone. Then you add the following line on top of php.ini file to change default timezone of the web server.
date.timezone = "US/Central"
Or you can add
<?php date_default_timezone_set(“US/Central”); ?>
on individual pages to locally alter timezone for specific pages.
4. File Permission and Output buffering
Its important that file permission of directories and files match with that of old web server. Especially, if you are running a CMS or PHP framework.
The functions require and include may not work properly when Output buffering is turned Off. To turn output buffering on, add output_buffering = 4096 to your php.ini file.
5. PHP memory limit
If you are running memory heavy scripts, such as scripts that belong to Drupal CMS, WordPress or scripts that does PDF generation, excel import/export etc., you will need to set higher PHP limits. If the new web server is set with lower PHP Memory limit than the memory limit set in old web server you will obviously run into PHP memory limit errors.
You can set
memory_limit = 64M
in the php.ini file or use
to modify PHP memory limit at script level.
Note: Shared hosting providers may have set PHP memory limit to 64 MB or lesser by default. In such cases you can not increase PHP memory limit either by setting memory_limit in php.ini or at script level.
6. HTTP Server
When you migrate to a new server, you should make sure that the new web server runs the same server software. Or you have to install some plugins/ make some configuration changes to get your code work without errors. For example, if your site relies on .htaccess for URL rewriting and if you are moving from an Apache to nginx server the URL rewriting will not work because nginx does not support .htaccess.
So when migrating your PHP website from one web server to another, it is always good to run phpinfo(); function in the old server to know the configurations used in the old web server and setup the new web server accordingly.