Making WordPress.org

Opened 8 months ago

Last modified 4 weeks ago

#3791 new defect

Consider bumping pre-commit checker on plugins to PHP 7.1

Reported by: Ipstenu Owned by:
Milestone: Priority: high
Component: Plugin Directory Keywords: pending-systems


Currently we have pre-commit checks set for PHP 7.0, which is great ... except people are starting to use PHP 7.1 and up for their code and getting burned by not being able to commit code to SVN becuase of that.

7.0 is only getting security reports through end of 2018, so it's probably time to have a gander at the possibility of bumping to 7.1 (or if we want to be ahead of the game, 7.2...)

Things to consider:

1) Will bumping the checker have an ADVERSE impact on plugins written for 5.2.4?

2) Do we have a way to see what PHP versions plugins use?

3) If 2 is yes, do more plugins use 5.2.4 or 7.1+?

Change History (9)

This ticket was mentioned in Slack in #meta by tellyworth. View the logs.

8 months ago

#2 @tellyworth
7 months ago

  • Keywords neso added

#3 @tellyworth
7 months ago

More WordPress sites use PHP 7.2 than PHP 5.2. I'll see if I can dig up stats on plugin compat.

It seems like the best way to proceed here is to bump the requirement and listen to feedback.

Can anyone suggest a compelling reason not to?

#4 @dd32
7 months ago

1) Will bumping the checker have an ADVERSE impact on plugins written for 5.2.4?

Shouldn't do. When we bumped it to 7.0 that would have added some (but that was okay)

Looking at the PHP 7.1/7.2 backward incompatible changes, I see nothing that should change linting of older code

2) Do we have a way to see what PHP versions plugins use?

We can run manual lookups for that kind of thing, there are roughly 40 plugins whose requires_php is PHP 7.1 or 7.2.

3) If 2 is yes, do more plugins use 5.2.4 or 7.1+?

Literally thousands more plugins are marked as requiring PHP 5.0~5.2.4. I don't think that has any impact here.

I see no reason why the linting for plugin commits shouldn't be increased to PHP 7.2 (which is what we're currently running for web nodes).

#5 @SergeyBiryukov
7 months ago

  • Component changed from General to Plugin Directory

#6 @SergeyBiryukov
5 weeks ago

  • Priority changed from normal to high

Could we bump the priority for this? See the discussion in https://twitter.com/Josh412/status/1100487567236059136 and https://twitter.com/Rarst/status/1100813140726562816.

Also discussed with @Rarst at WordCamp Nordic 2019.

#7 @Rarst
5 weeks ago

Do note that stable PHP is at 7.3 by now. In larger PHP community it seems that 7.1 is going to be "common" minimum required version for a while.

Having a hard barrier to use current (not even new anymore) PHP features significantly impairs progress of plugin ecosystem. While back I had counted barely 400+ PHP 7+ plugins. This is abysmally low.

#8 @dd32
5 weeks ago

  • Keywords pending-systems added; neso removed

Latest system request for this: https://make.wordpress.org/systems/2019/03/18/change-plugins-svn-linting-to-php-7-current-please/

I've requested that we continue to bump it as we roll out new PHP branches to dotorg, however due to the way the dotorg infrastructure is setup that might not be as easily achieved.

#9 @Otto42
4 weeks ago

We have had problems with the current iteration of the php linter, insofar as it looks at each individual file independently.

If a plugin includes backwards compatibility files in a way where the back compat checks are actually in another file, then the non compatible file, which normally would not be loaded in such an environment, will fail the lint check and thus cannot be committed.

Example: plugin does if ! function exists, then include file. File has that function. Function is a back commit function that exists in PHP 7. File, by itself, fails the lint. But it's never loaded because the plugin doesn't load it in such a case.

This is shockingly common in libraries included by plugins, so the authors don't know why it fails, because it's a library they didn't write.

Note: See TracTickets for help on using tickets.