Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#47797 closed enhancement (fixed)

Provide compatible core update for users not on PHP >= 5.6

Reported by: afragen's profile afragen Owned by:
Milestone: WordPress.org Priority: normal
Severity: normal Version:
Component: Site Health Keywords: has-patch needs-testing early
Focuses: Cc:

Description

As discussed in #core-site-health we were searching for a way for users on unsupported PHP versions to be able to update to the highest compatible WP version. https://wordpress.slack.com/archives/CKSU841L7/p1564417381105300

Initially it was thought that we would need to serve a modified API return to the user. I think I've found a way in core to make this work, however, it would require backporting.

The goal was to enable users to WP 5.1.1, the most recent version to still support PHP 5.2.4 and the version containing the dashboard callout for PHP updating. At least I think that's what the goal is/was.

Attachments (2)

47797.diff (703 bytes) - added by afragen 5 years ago.
47797.2.diff (708 bytes) - added by afragen 5 years ago.
remove short array syntax

Download all attachments as: .zip

Change History (20)

@afragen
5 years ago

#1 @SergeyBiryukov
5 years ago

  • Milestone changed from Awaiting Review to 5.3

This ticket was mentioned in Slack in #core by miss_jwo. View the logs.


5 years ago

@afragen
5 years ago

remove short array syntax

This ticket was mentioned in Slack in #core-site-health by garrett-eclipse. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by afragen. View the logs.


5 years ago

#6 @afragen
5 years ago

@azaozz if this could be handled in an API update that would be so much better.

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


5 years ago

#8 @JeffPaul
5 years ago

  • Milestone changed from 5.3 to 5.2.3

#9 @JeffPaul
5 years ago

We need to get to a decision on approach here and then implement it if we hope to land it in 5.2.3, otherwise we'll punt this to 5.3.

This ticket was mentioned in Slack in #core-site-health by miss_jwo. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by marybaum. View the logs.


5 years ago

#12 @marybaum
5 years ago

  • Milestone changed from 5.2.3 to 5.3

#13 @afragen
5 years ago

Related: #Meta4699

Last edited 5 years ago by afragen (previous) (diff)

This ticket was mentioned in Slack in #core by david.baumwald. View the logs.


5 years ago

#15 @davidbaumwald
5 years ago

  • Keywords early added
  • Milestone changed from 5.3 to 5.4

This ticket still needs testing. With version 5.3 Beta 1 tomorrow, this is being pushed to 5.4, and I'm adding the early tag to hopefully get some early testing for feedback.

#16 follow-up: @dd32
5 years ago

  • Milestone changed from 5.4 to WordPress.org
  • Resolution set to fixed
  • Status changed from new to closed

I've fixed this through an API change, a little used functionality in Core allows the API to return multiple update offerings which the user can choose between. I'm fairly sure it was added for this exact scenario happening at some point in the future.

Re-using/re-branding the autoupdate responses as done in the attachments here isn't recommended, as it has the potential to use the wrong packages.

I'll copy the Meta comment here:

Replying to dd32:

I've made an API change which returns multiple versions for users on WordPress 3.7~5.1 running PHP 5.2.4~5.6.20.

We can make a similar addition for when PHP 5.6 support is dropped (It won't be automatic, as I hard-coded the PHP and WP versions)

The above attachment shows the experience, it's not fantastic especially as the string in core doesn't expect that this could ever occur.
I figured showing both would at least allow the user to update to a recent WordPress, while at the same time also making it clear there's a newer version of WordPress that has a more modern PHP requirement.

Fixed via r15417-dotorg:

API: Core Update endpoint: Offer WordPress 5.1.x as an update destination for < 5.1.latest and PHP 5.2.4~5.6.19 users.

The attachment being referred to above is the following, which is the experience for a WordPress 4.9 user running PHP 5.3 following this change, previously they'd have just seen the first "You cannot update because ..." message.

https://meta.trac.wordpress.org/raw-attachment/ticket/4699/Screen%20Shot%202019-10-17%20at%2012.33.30%20pm.png

I'm going to mark this as fixed, but feel free to re-open if there's something further wanted to be done in core here. If you'd like the API changed, please @mention me on the Meta ticket above :)

Version 0, edited 5 years ago by dd32 (next)

#17 in reply to: ↑ 16 @dimadin
5 years ago

Replying to dd32:

a little used functionality in Core allows the API to return multiple update offerings which the user can choose between. I'm fairly sure it was added for this exact scenario happening at some point in the future.

This is actually used since beginning for WordPress installations with language other than en_US, you are offered to update to WordPress X.Y.Z-aa_BB and WordPress X.Y.Z-en_US.

This ticket was mentioned in Slack in #core-site-health by dd32. View the logs.


5 years ago

Note: See TracTickets for help on using tickets.