re: PHP Extensions

Thank you to everybody who has contributed to the conversation regarding PHP extension requirements!

This post is meant to summarize the feedback had so far, and not to make recommendations at this stage.

Background

Following the release of WordPress 5.2 and Site Health Check, the hosting team started working on documentation to help bring clarity about requirements and recommendations to users and hosts.

The official requirements do not yet list PHP extension details. There is a meta ticket discussing how to handle this.

Site Health Check, however, lists both PHP extension requirements and recommendations via WP_Site_Health::get_test_php_extensions() in the new Site Health functionality in 5.2.

The recommendations included are extensions that are not required by core, but are used when available to make WordPress function better.

Discussion on changing these was started in this trac ticket. While discussion is in progress, feedback was requested from hosts.

Following that, @dd32 helped with a first pass on requirements and recommended something like phpcompatinfo to check in an automated fashion. @amykamala ran phpcompatinfo as recommended, and you can check out the results in this doc.

Host Feedback

Based on feedback received in @mikeschroder‘s post regarding PHP requirements:

• 75% of feedback indicated that the handbook should make recommendations beyond the required PHP extensions.

• There was a 50/50 split on whether Site Health Check should also recommend PHP extensions beyond requirements.

• However, more than half of responses indicate that core requirements and recommendations (if provided) should both be available via Site Health.

The following extensions were suggested as additional recommendations to be made:

  • opcache
  • bcmath
  • memcache
  • memcached
  • Intl

@peterwilsoncc recommended here that the following parameters be in place for determining what extensions are recommended:

“1. it’s used in WordPress Core
2. it’s included in the default PHP build for each version WordPress Core supports, currently the default builds for PHP 5.6+”

About Intl

There is an existing feature request for recommending the intl extension, found here.

@zodiac1978 brought up the idea of recommending intl in this github issue:

“It is necessary to use the Normalizer function which would solve many problems with internationalization issues for special characters: https://www.php.net/manual/en/intl.requirements.php

@fierevere  Pointed out that “intl has hard dependency on icu system libraries, which will consume over 30 Mb diskspace on smaller (VPS/embedded) systems. Each loaded library claims some memory and initialization time overhead. Bigger distributions can link libicu to libxml2 library and therefore it can be loaded by libxml2 linked extensions, but this dependency is optional”

This trac ticket was re-opened and is related, in that Normalizer::normalize requires the intl and icu extensions.

@bronsonquick mentioned here that they “… had to created a new Chassis extension for PHP intl when I was working on a clients site in another language as it wasn’t bundled!”

@swissspidy brought up an important point here, stating that “an available extension does not necessarily mean that it’s working. For example, we’ve often ran into issues where hosts disable functions like curl_multi_init or even curl_init. Or, in the case of the INTL extension, when a server is running PHP 7.2 but uses a super outdated version of the extension which doesn’t include the functions and constants one would expect. So any site health check for extensions should also check against these things.”

Thank you

Thank you again to everyone who contributed to the conversation regarding PHP extensions. Please feel free to add additional comments here or bring it up in the #hosting-community Slack channel. Your feedback is important!