Making WordPress.org

Opened 8 months ago

Last modified 11 days ago

#4309 reviewing enhancement

Displaying PHP Compatibility results from Tide on wp.org

Reported by: JoshuaWold Owned by: ck3lee
Milestone: Priority: normal
Component: Plugin Directory Keywords:


On Github we've been discussing how we can show compatibility results for PHP versions on WordPress.org for plugins. You can read more about the discussion and design decisions previously: https://github.com/wptide/wptide/issues/152

This Trac ticket is to kickstart that discussion on Trac and try to move forward.

Attachments (6)

Group 2.png (367.8 KB) - added by JoshuaWold 8 months ago.
Group.png (365.6 KB) - added by JoshuaWold 8 months ago.
not-compatible-with-latest-warning.png (24.5 KB) - added by ottok 5 months ago.
compatible-with-up-to-latest.2.png (22.6 KB) - added by ottok 5 months ago.
very-simple-not-compatible.png (20.6 KB) - added by ottok 5 months ago.
very-simple-compatibile.png (18.3 KB) - added by ottok 5 months ago.

Download all attachments as: .zip

Change History (25)

8 months ago

8 months ago

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

6 months ago

#2 @tellyworth
6 months ago

  • Component changed from General to Plugin Directory
  • Owner set to ck3lee
  • Status changed from new to reviewing
  • Type changed from defect to enhancement

#3 @ottok
5 months ago

I suggest you start out with something much more simple. Instead of the modal thing we could start up with a dead simple list of supported PHP versions.

There are two sources of information to consider here. First of all the current "PHP Version" line uses the "Requires PHP: N.N.N" from the plugin readme.txt. This should still be honored and used to set the minimum PHP version supported in a list fo supported PHP versions.

The second source of information is the JSON report by WP Tide:


From this list all values above the readme.txt stated minimum version should be used.

My suggested UI is below. These examples are hopefully self-explanatory.

(Ticket owner: please delete attachment https://meta.trac.wordpress.org/attachment/ticket/4309/compatible-with-up-to-latest.png, it was the wrong mockup.)

Last edited 5 months ago by ottok (previous) (diff)

#4 @dd32
5 months ago

How often is it likely that a plugin that was compatible with PHP 7.0 and 7.2, but incompatible with PHP 7.1? Does displaying each version of PHP that's compatible useful to the average user or developer?

Wouldn't we be better off sticking with minimum and potentially maximum supported versions of PHP?

#5 @BrashRebel
5 months ago

Could we make it consistent with the way the WordPress version compatibility is presented now?

"PHP Version: 5.6 or higher"

#6 @JoshuaWold
5 months ago

Thank you @ottok for that wonderful mockup!

I think the answer here comes down to what's actually needed for users. If there's situations where, as @dd32 mentioned, I could be compatible with 7.0 and 7.2, but not 7.1, then we should go the way of the mockup @ottok suggested.

Otherwise I agree with @BrashRebel that a simple statement works.

@JeffPaul do you or Derek know the answer to this? :)

#7 @dd32
5 months ago

In 8975:

Plugin Directory: Add a job to import data from Tide into the plugin directory.

This job isn't yet in use, and a follow up commit will enable it.

See #4309.

#8 @dd32
5 months ago

In 8976:

Plugin Directory: Import Tide data for plugins after commits.

See #4309.

#9 @dd32
5 months ago

In 8977:

Plugin Directory: Tide Sync: Handle the case of an empty tide summary report.

See #4309.

#10 @dd32
5 months ago

In 8978:

Plugin Directory: Tide Sync: Only support plugins who use versioned versions, ie. no stable tag: trunk.

See #4309.

#11 @ottok
5 months ago

Thanks @dd32 for working on this! Attaching mockups of the very simple UI version.

If the plugin is not compatible with latest PHP version there should be a link to a page that explains how to run PHPCS yourself and fix it (for plugin authors), and something for users about why PHP compatibility matters.

Last edited 5 months ago by ottok (previous) (diff)

#12 @JoshuaWold
5 months ago

These looks great. Thanks!

#13 follow-up: @afragen
5 months ago

Does this mockup mean the current Requires PHP: header is being replaced ?

#14 in reply to: ↑ 13 @dd32
5 months ago

Replying to afragen:

Does this mockup mean the current Requires PHP: header is being replaced ?

No, anything we do is in addition, or as a fallback for a plugin not specifying it.

I don't think we'll be adding an upper bound of supported php either for the time being, due to difficulties in parsing that with confidence.

Last edited 5 months ago by dd32 (previous) (diff)

#15 @afragen
5 months ago

Should it say Compatible PHP as there will also be a Requires PHP? As requires is a minimum Tide data would be a bonus.

#16 @BrashRebel
5 months ago

I just wanted to raise one other concern real quick: With this addition, "Tested up to:" could become a new point of confusion. We would have for example:


  • WordPress Version: 4.9 or higher
  • Tested up to: 5.2
  • PHP Version: 5.2 to 7.1

The second item does not state what it pertains to. WordPress is implied currently but if we add another item to the list with an independent version number, we could introduce confusion. The matter is potentially exacerbated by the fact that numbers will commonly be similar since coincidentally WordPress has now reached 5.x which is close to much of the supported PHP numbering.

It might be wise to consider revising all three labels for clarity if we are going to introduce independent version numbers.

Separate, less important question: Could we introduce capitalization consistency throughout all the labels?

Last edited 5 months ago by BrashRebel (previous) (diff)

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

4 months ago

#18 @JeffPaul
13 days ago

@ck3lee @dd32 @ipstenu assuming we're able to get to an agreement on HOW the PHP compatibility data from Tide should be displayed on the plugin pages and a patch is created for this update, what would be the process to get that approved and committed?

#19 @Ipstenu
11 days ago

We need to keep Advanced View, as that's also where you manage contributors. Unless you're pulling the WHOLE thing into the Development tab.

TBH, I'm actually not the voice to decide what the page looks like. I just make sure I have access to what I need. I defer to designers and data folx to the rest. I would want to get a designer in on this to make some educated decisions, and if @tellyworth and/or @otto42 like it, go forward :)

Note: See TracTickets for help on using tickets.