WordPress.org Bumps PHP Maximum for Plugin Directory to Version 7.2

The WordPress.org SVN system received a version bump to 7.2 on October 3. This change means that plugin authors can now use newer PHP syntax in plugins they submit to the official plugin directory. In the future, the version maximum will match what’s running on WordPress.org.

This should be good news for any plugin developers who are using newer PHP syntax. Previously, authors were able to submit code using newer PHP functions if they had a compatibility check in the same file. However, newer syntax wasn’t allowed.

“The issue was that the Linter (being stuck on 7.0) prevented anyone from checking in code via SVN that used 7.1+ standards,” said Mika Epstein from the plugin review team. “So things like the Spaceship operator would fail on commit and you’d be told the syntax was invalid. This was holding back certain plugins from committing code into the directory.”

Epstein first opened a ticket to address the issue 13 months ago but said she’d been quietly asking for a fix for a while longer.

The max PHP version isn’t listed anywhere in the plugin guidelines. Technically, it’s an SVN limitation on WordPress.org and not something the plugin team chose. However, for plugin authors, they may not have known about the issue until their plugin was rejected by the system. They would then message the plugin team about the problem. “I may end up putting something in the docs, but it’s a somewhat uncommon occurrence,” said Epstein.

This has been an issue for some plugin authors since PHP 7.1 was released, which was December 1, 2016. “It was a once a year issue, then twice, and then it inched up to every couple months,” said Epstein. “As of September, at least once a month someone would hit this and complain to plugins.”

One potential problem with blocking newer PHP code is with plugins that rely on third-party libraries, which may only have security patches in more recent versions. However, Epstein said that she was not aware of any security issues that resulted from the version limitation.

Andrey “Rarst” Savchenko pointed out in the ticket that “7.2 was released almost two years ago.” While he says it’s an improvement over the previous 7.0 limitation, version 7.2 should not be a hard ceiling for plugins in the repository.

PHP 7.3 was released on December 16, 2018, and PHP 7.4 will be released on November 28, 2019.

“Given PHP’s poor adoption curves,” responded Dion Hulse, “all that this means is that you can’t release a plugin through WordPress.org that only works on 15% of WordPress sites. “You can even use newer functions in PHP if including compat code, just not newer syntax.”

Plugin author Josh Pollock called awareness to the issue on Twitter in February. “Hours later, I’m downgrading a dependency, because it requires another dependency, which requires PHP 7.1.”

“I think we got lucky and there were no bugs,” Pollock said of downgrading to an earlier version of the dependency. “I don’t think I’ve used SVN since. I’m really fortunate that’s not a part of my life anymore.”

“I agree with Rarst,” said Pollock. “We should be allowing for PHP 7 and making it easier for plugins not to support sites on out of date versions of PHP.” This echoes the sentiment of other developers who are pushing for WordPress to adopt newer standards or at least allow them to do so in their own plugins in the official directory.

For the majority of plugin authors, this should be a non-issue as long as the SVN system remains updated to match the version of PHP used on WordPress.og.

PHP 7.2 will lose active support on November 30, 2019, and security support on November 30, 2020.


7 responses to “WordPress.org Bumps PHP Maximum for Plugin Directory to Version 7.2”

  1. Like I commented in the issue, it doesn’t matter what the maximum PHP version is, because any hard version limit is arbitrary, and any hard version limit is wrong. This point didn’t seem to have reached the intended audience, and was largely ignored. Even Rarst, when he raised the same point, was told:

    Given PHP’s poor adoption curves, all that this means is that you can’t release a plugin through WordPress.org that only works on 15% of WordPress sites.

    This is a non-answer, because the choice of platform, even a poor one, cannot come from anyone but the developers of the products themselves. Even more so, given that WP runs on PHP versions that are higher than the current arbitrarily set minimum.

    The only acceptable solution is to make this check optional, like I write here.

    This is outrageous.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: