Jul 06 2009
With the introduction of WordPress 2.7 upgrade capabilities for local installations are available right out of the box without the need of 3rd party plugins or manual update process.
While this is cool, can also be a tricky, not so straight forward process. If your blog is hosted by WordPress, you do not have to worry about anything as the upgrade is done automatically for everybody. If you host your own blog and use only standard themes an no additional 3rd party plugins, upgrade is also safe for you, as no compatibility issues can occur between versions upgrade. On the other hand, what’s the point of having your WordPress blog self hosted if you do not need the added value of 3rd party plugins?
You’ll need this guide if you host your own WordPress instance, you are using 3rd Party plugins and you are planning for an upgrade. I decided to write this guide after Aperture.ro was not available after upgrading from WordPress 2.7 to WordPress 2.8 via build in upgrade feature. Server displayed HTTP 500 error while loading the main page. Problem was fixed in 5 minutes. Here is how.
Majority of automatic upgrades are failing because one or more plugins that we’re compatible with the old version WordPress do not work with the new one. The question is how you can identify the bugger? There are different scenarios here:
1. Your WordPress is hosted by an ISP who offers standard PHP / MySQL functionality. You have access via cpanel or FTP to your site’ root, but no means of accessing PHP / MySQL error logs (and can’t be sure if the ISP is keeping such logs either).
- If that’s your case, you can call the ISP to check for any bad references in the PHP error log and point you to the plugin(s) that’s causing the mess. If the ISP’ Customer Support department is on a team building in Honduras,
- Logon via cpanel or FTP to your site’ root, make a note of all the plugins in wp-content/plugins/ folder. Copy all of the plugins to your local drive, delete all folders from wp-content/plugins/. Access your wordpress home page. It should work, as all plugins have been removed. Now the part which requires some patience: copy one by one each of the plugins from your local drive and make sure that after each plugin is copied, you do a functionality check of your WordPress blog (both the front page and admin logon). This way you can manually identify and remove the incompatibleÂ plugin.
2. Your WordPress is hosted by you and you have full access to PHP.ini file. This will save you a lot of time and effort. Search for the following lines:
- “error_reporting”. If the field is commented – has a semicolon (;) in front, remove the comment and turn the field into “error_reportingÂ =Â E_ALL“. This will enable error reporting for all errors;
- “log_errors”. Same as above, remove the comment and turn the field into “log_errors = On“. This tells PHP engine to echo errors to an external source, such as a file;
- “error_log”. Remove comment and give the field a value which is the path and the error log file: “error_log = E:\Logs\PHP\error.log“. Replace here the value with a path & file name of your choice.
You have now enable PHP error reporting to a file. Access the site, you will get the same HTTP 500 – Internal Server Error message displayed, but your newly created file will tell you which of the installed and enabled plugins is creating the issue. In my case was a Google Analytics plugin which was causing a PHP Fatal Error (Call to undefined function) when loading the main page. Once the troble maker has been identified, simply remove it and everything should be back to normal.
3. The 3rd way of identifying a malfunctioning plugin is to upload a PHP file into your site root and access it via your browser. the PHP file (we will call it debug.php for the sake of this example), must contain the following code:
Once the file was uploaded to your root folder, access your site, you will get the same HTTP 500 – Internal Server Error. Ignore it and input into your browser address bar: “www.yoursite.com/debug.php“. The page will return last PHP encountered error.
That was more or less the whole story. Next, some things to keep in mind before upgrading your WordPress via automated upgrade tool:
- Check the change log for the new version and ask your self: do I need the added features and bug fixes? Who knows…
- Never upgrade in the same day of the new version release. Upgrading fast sounds tempting, but allow the plugin developers to also update their code to be compatible with the last WordPress version. Some are fast, some are lazy, some are in team building in Honduras…
- Before automatic upgrade, check the plugins within your WordPress administration panel for any updated versions;
- Backup your WordPress database. I use MySQL Administrator (part of MySQL GUI Tools). But every MySQL database administration plugins will do the job.
- Backup your WordPress data files. I backup before every upgrade the whole root dir of the site and transfer it to a different drive.
Hope it helped. Happy upgrading .
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.