The PHP developers recently released versions 7.1.31, 7.2.21 and 7.3.8 that fix several bugs. We’ve upgraded the PHP 7.1, 7.2 and 7.3 series on our servers as a result.
These changes should not be noticeable, but as always, don’t hesitate to contact us if you have any trouble.
Update August 21, 2019: The maintenance described below has been completed for all sites.
Over the next few weeks, we’ll be retiring some old servers and moving sites on those servers to new (often faster) ones. Migrating a site takes just a few seconds in most cases, so it’s likely that neither you nor your visitors will notice this happening.
If someone does view your site while it’s being migrated, they’ll see a maintenance screen with a link to this blog post, like this:
If your site is in the small minority that has a large database (more than a few hundred MB), the migration could take a little longer — perhaps a few minutes. We try to do migrations during slow periods for each site, minimizing the impact on visitors.
Read the rest of this entry »The PHP developers recently released versions 7.2.20 and 7.3.7 that fix several bugs. We’ve upgraded the PHP 7.2 and 7.3 series on our servers as a result.
These changes should not be noticeable, but as always, don’t hesitate to contact us if you have any trouble.
If you have a WordPress site, and you use both the WP Super Cache plugin and the Cloudflare content delivery network, the latest version 1.6.8 of WP Super Cache may not properly cache your pages by default.
This is because of a quirk of the update: A new setting makes it think all Cloudflare visitors are “known users” because they have a “cookie” set. If you had the old “disable caching for known users” option turned on before the update, it won’t cache pages for Cloudflare visitors after the update.
The same thing can happen if you have a WordPress plugin that sets a “cookie” for each visitor for some other reason.
This problem is easily fixed by changing the new WP Super Cache “Cache Restrictions” setting from “Disable caching for visitors who have a cookie set in their browser” to “Disable caching for logged in visitors. (Recommended)”. We’ve updated our WP Super Cache page to reflect this change, and if we notice that a site hosted on our servers suddenly has higher CPU resource usage because of this, we’ll update the setting for you to make it work as it did before.
The PHP developers recently released versions 7.1.30, 7.2.19 and 7.3.6 that fix several bugs. We’ve upgraded the PHP 7.1, 7.2 and 7.3 series on our servers as a result.
These changes should not be noticeable, but as always, don’t hesitate to contact us if you have any trouble.
After recent server updates, two customers contacted us with a problem: their pages that used correctly to display “unicode” non-ASCII characters (like “©” or “curly quotes”) started showing invalid characters like “�” instead.
If this happens to you, it’s likely to be caused by a bug in your script that’s only now visible because of a security change in recent MySQL database versions. For example, the problem happened to the two customers we mentioned because they were using old versions of the Joomla and TextPattern software. Updating each of those fixed it, so if you you have trouble, be sure you’re using the latest versions of any software like that.
Read the rest of this entry »Update May 24 11:00 PM Pacific time: The maintenance described below has been completed and all services are running normally.
Over the last year, we’ve been slowly upgrading our servers from Debian Linux version 8 (codename “jessie”) to version 9 (codename “stretch”). We’ll be finishing that process soon, with brief scheduled maintenance on each server.
The upgrade requires that each hosting server be taken offline for a few minutes over a three hour maintenance window and then restarted, causing brief scheduled “downtime” for websites and email on that server. The total downtime for any site should not exceed ten minutes during this three hour period.
Mail arriving while a server is being restarted will be queued and delivered after a short delay. No mail will be lost.
This coming weekend, we’ll be updating some (not all) web servers:
So, for example, the “web05” and “web14” servers will be updated. This page explains how to find which server a site is on. (Servers ending in digits “0” – “3” and “7” – “9” have already been updated.)
Read the rest of this entry »Update May 18 10:46 PM Pacific time: The maintenance described below has been completed and all services are running normally.
Over the last year, we’ve been slowly upgrading our servers from Debian Linux version 8 (codename “jessie”) to version 9 (codename “stretch”). We’ll be finishing that process over the next few weeks, with brief scheduled maintenance on each server.
The upgrade requires that each hosting server be taken offline for a few minutes over a three hour maintenance window and then restarted, causing brief scheduled “downtime” for websites and email on that server. The total downtime for any site should not exceed ten minutes during this three hour period.
Mail arriving while a server is being restarted will be queued and delivered after a short delay. No mail will be lost.
This coming weekend, we’ll be updating some (not all) web servers:
So, for example, the “web03” server will be updated on May 17, and the “web11” server will be updated on May 18. This page explains how to find which server a site is on.
(Servers ending in digits “0”, “9”, “8” and “7” were updated last weekend, and servers ending in digits “4”, “5” and “6” will be updated the following weekend; we’ll post a separate announcement about that.)
Read the rest of this entry »Update May 11 10:20 PM Pacific time: The maintenance described below has been completed and all services are running normally.
Over the last year, we’ve been slowly upgrading our servers from Debian Linux version 8 (codename “jessie”) to version 9 (codename “stretch”). We’ll be finishing that process over the next few weeks, with brief scheduled maintenance on each server.
The upgrade requires that each hosting server be taken offline for a few minutes over a three hour maintenance window and then restarted, causing brief scheduled “downtime” for websites and email on that server. The total downtime for any site should not exceed ten minutes during this three hour period.
Mail arriving while a server is being restarted will be queued and delivered after a short delay. No mail will be lost.
This coming weekend, we’ll be updating some (not all) web servers:
So, for example, the “web10” server will be updated on May 10, and the “web07” server will be updated on May 11. This page explains how to find which server a site is on.
(Additional servers will be updated the following weekends; we’ll post separate announcements about that.)
Read the rest of this entry »The PHP 7.3 series has been out long enough that all modern script software should be compatible with it, and the authors of popular scripts like WordPress recommend using it. Because of that, we’re making PHP 7.3 the default for new customers.
We haven’t changed the version for any existing accounts, but we recommend that all customers use PHP 7.3 if possible. PHP 7.3 is slightly faster than PHP 7.2 and around twice as fast as PHP 5. If you care about your site’s speed (and you should), always use the newest version of PHP that’s compatible with your scripts. Our Why Update PHP? page explains more about PHP version updates.
