All of our sites and most of our customers' sites are hosted on SiteGround. SiteGround is top-notch provider for hosted WordPress solutions. They are so good at what they do, they are one of the top hosting providers recommended by WordPress.org. While many hosting providers meet the minimum requirements to run WordPress, SiteGround offers:
- PHP version 7 or greater
- MySQL version 5.6 or greater OR MariaDB version 10.0 or greater
- HTTPS with HTTP/2 support
- Free Let's Encrypt SSL certificates
- Exceptional Support
With active support for PHP 5.6 having ended in Dec. 2016, we undertook the task of upgrading our sites to PHP7. On SiteGround, upgrading to PHP7 is simply a matter of logging into cPanel and using the PHP Version Manager to change your site to a different version of PHP. The Version Manager writes a single line to the end of your site's .htaccess file and you're done! …Or, so you should be.
When we upgraded the first couple of sites to PHP7, we immediately ran into issues. All of our plugins passed the PHP7 compatibility check. Yet, when we upgraded to PHP7, we instantly received Server 500 issues on these sites. Troubleshooting a Server 500 error is difficult at best because the root cause can be so many things. Server 500 errors are very hard to diagnose.
Stepping through a typical WordPress troubleshooting process, we narrowed the issue down to an apparent conflict between two of the most popular plugins in the WordPress world, Yoast SEO and WP Rocket, a premium performance optimization tool. When both of these plugins were enabled, the server immediately crashed. When either was enabled by itself, the server ran fine. We opened up support tickets with both development groups. After spending a lot of time troubleshooting this issue, both development teams came to the same conclusion. There is an issue with the way SiteGround has the PHP7 opcache configured. They determined this by running the exact same configuration on hosts like WPEngine and InMotion without producing any errors. Unfortunately, neither development team could explain exactly why SiteGround was producing the errors.
Getting to the root cause took some digging, but we eventually discovered the opcache.interned_strings_buffer variable. What is the opcache.interned_strings_buffer variable exactly? It's a neat little setting for which you can find no documentation. PHP7 uses a technique called string interning to improve performance. String interning is a method of storing only one copy of each distinct string value, which must be immutable. Interning strings makes some string processing tasks more time or space efficient.
So, for example, if you have the string "foobar" 1000 times in your code, internally PHP will store 1 immutable variable for this string and just use a pointer to it for the other 999 times you use it. Instead of having a pool of these immutable string for each SINGLE php process, this setting shares it across ALL of your php processes. It saves memory and improves performance, especially in big applications. For PHP7, the default value for opcache.interned_strings_buffer is 4MB. SiteGround uses this default setting. By increasing this value to 8Mb, the apparent plugin conflict resolved itself and the sites began running perfectly. There was never any plugin conflict.
We contacted SiteGround and explained the problem, our troubleshooting efforts, and the results of changing this variable. We suggested that they update their server configurations. This is their response:
…thanks so much for your suggestion—actually, our operations team are aware of the situation and are currently working on implementing the global fix on all of our servers. It may still take time due to the number of the servers in our pool, but we assure you that the issue is being worked on.
So in the meantime, if you find that the SiteGround server your site is hosted on is still set to the default value, use the PHP Variable Manager in cPanel to change this value to 8 or 16. This will fix the Server 500 issue and you will get a boost in site performance as well.
Thanks for sharing this, I also came to the same conclusion a few months back but it seems to have crept up on a new site and this doesn’t fix it. The SiteGround PHP7 caching conundrum continues…
Are you using Wordfence by any chance? I’ve had a lot of problems with Wordfence on SiteGround with PHP7 lately. The last Wordfence update brought down almost all of my SiteGround hosted sites. It’s been a nightmare getting the sites up and running again.
Hi Victor, I’m having this same issue and I’m using Wordfence. Are there any alternatives to Wordfence you would suggest if it has issues with PHP7?
If you disable the advanced firewall and remove the auto_prepend variable from php.ini, it consinues to work.
Hi Victor. I’m using Wordfence on an inMotion VPS and I’m planning to update the server to PHP 7 very soon. Do you know if this issue still exists or have Wordfence updates resolved it by now? Thanks in advance for your answer!
Not that I’m aware of Rick. I’ve been running PHP7 with Wordfence for quite a while now.