Upgrading to PHP7 with WordPress, including fixes for major plugins
The upgrade is fairly straightforward but there are some incompatibilities in some plugins.
Here’s the upgrade process:
sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt-get install -y tmux curl wget nginx php7.0-fpm php7.0-cli php7.0-curl php7.0-gd php7.0-intl php7.0-mysql php-memcached
vi /etc/nginx/conf.d/upstream.conf
(Change php socket to new php7 socket)
upstream php {
server unix:/var/run/php/php7.0-fpm.sock;
}
MailPoet
Until they fix the bug in their code, you will have to do it for them. Find plugins/wysija-newsletters/core/base.php and edit line 395 to the following (add the { and } brackets):
$result_array['result'] = $this->controller->{$_REQUEST['task']}();
APC Cache Fix
The command for APC cache is now apcu_store instead of apc_store, also apcu_fetch, apcu_delete. This affects WP All Import Pro, Updraft Plus and W3 Total Cache. All of these plugins will continue to work without this fix, but they will not use the APC cache so you won’t get as fast performance as you could.
To fix them all, presuming your web files are in /var/www/html, run the following 3 commands to search and replace the 3 different function names:
find /var/www/html -type f -exec sed -i 's/apc_store/apcu_store/g' {} \; find /var/www/html -type f -exec sed -i 's/apc_fetch/apcu_fetch/g' {} \; find /var/www/html -type f -exec sed -i 's/apc_delete/apcu_delete/g' {} \;
W3 Total Cache
Modify w3-total-cache/lib/W3/Plugin/TotalCache.php – line 512 – remove the & in &$buffer to $buffer.
Then to get APC working again, modify the following 4 files (or just run the general APC cache command-line search/replace from above)
- w3-total-cache/inc/lightbox/self_test.php
- w3-total-cache/lib/Minify/Minify/Cache/APC.php
- w3-total-cache/lib/W3/Cache/Apc.php
- w3-total-cache/lib/W3/UI/GeneralAdminView.php
Search/replace apc_store, apc_fetch, and apc_delete with apcu_store, apcu_fetch, and apcu_delete in each of these 4 files and APC cache will now work with PHP 7 through W3 Total Cache.
wpMandrill
Find /wp-content/plugins/wpmandrill/lib/mandrill.class.php and add the following code at line 542:
if ( !function_exists('set_magic_quotes_runtime') ) { function set_magic_quotes_runtime($value) { return true;} }
Debugging other errors
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);
If you run your site again, you will have a new file in /wp-content/debug.log – open this and search for errors to figure out your remaining PHP 7 issues.
- My WordPress performance plugins and server stack have moved - July 31, 2016
- Price Comparison Pro 1.2 Released - July 5, 2016
- How to run backups on huge WordPress websites without your website being brought offline - February 4, 2016
February 13, 2016 @ 5:12 pm
Hi Dave,
Do you find php7 faster than HHVM?
Jordan
February 13, 2016 @ 5:42 pm
It depends on the type of load on the server. In almost all cases, HHVM is still faster – it is compiled after all, versus interpreted PHP 7. I normally set up HHVM as the primary engine with fallback to PHP 7 in case of incompatibilities (server 500 errors).
If a client’s server doesn’t have much RAM, then I just use PHP 7 for them as the performance problems caused by reduced memory (because running two engines) is a bigger impact. I’m expecting further performance improvements from both HHVM and PHP 7 in the future. PHP 7 is definitely FAR better than PHP 5.6.