WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#12862 closed feature request (wontfix)

Actively encourage PHP 5 upgrades

Reported by: dougal Owned by:
Milestone: Priority: low
Severity: normal Version: 3.0
Component: General Keywords:
Focuses: Cc:

Description

I would like to suggest that we begin actively, but subtly, encouraging users who are on PHP4 to upgrade to PHP5.

In areas where functionality is improved by running under PHP5, status messages to the user could suggest to the user that they can ask their hosting provider about the availability of such an upgrade.

For example, in the Timezone settings we say: "Unfortunately, you have to manually update this for daylight saving time. The PHP Date/Time library is not supported by your web host."

Why not add an additional note that this functionality is available in PHP5, and suggest that the user contact their webhost to ask about it? If the note can be made generic enough, it could even be put in a filter in order to more easily add it to other areas of the interface where it makes sense.

This might help increase the uptake rate of PHP5 upgrades by users on webhosts that have left people on PHP4 who probably just don't know any better.

Change History (13)

comment:1 @dancole5 years ago

  • Keywords php5 webhosts removed

The footer in the dashboard will say "Get version X.X" when there is an update for WordPress. How about adding another one like "Update to PHP 5" and link that to a WordPress.org page that explains the situation and how it's going effect them in the --near-- future.

Acceptable keywords for Trac can be found at: http://codex.wordpress.org/Reporting_Bugs#Trac_Keywords

comment:2 @scribu5 years ago

For reference: #11411 #9751

comment:3 @nacin5 years ago

Thinking for 3.1 this is still wontfix, per #9751. We have the health check plugin that will be deployed soon, and it should be given a chance to handle this.

comment:4 @scribu5 years ago

In areas where functionality is improved by running under PHP5, status messages to the user could suggest to the user that they can ask their hosting provider about the availability of such an upgrade.

I like this approach.

comment:5 @miqrogroove5 years ago

-1 bloat, duplicate, wontfix

comment:6 @mrmist5 years ago

Did we not already have this discussion and http://codex.wordpress.org/Switching_to_PHP5 was written to be linked off some notice or other during the upgrade phase, and then for reasons I don't recall the ticket was closed...

comment:7 @nacin5 years ago

Did we not already have this discussion

Yes, that'd be #9751.

comment:8 @dancole5 years ago

Instead of trying to attack this problem by adding code to core, we could get WordPress News Authors to write about it. The hackers' mailing list could a get a list of host together and we could write to each of them. Server administrators are the target audience here. I'm not sure that what percentage of authors using WordPress would be proactive about this, but I don't think it would be very large.

comment:9 @nacin4 years ago

  • Milestone changed from Awaiting Triage to 3.1

Moving to 3.1, only because this either needs to be done for 3.1, or more likely wontfixed.

comment:10 @westi4 years ago

I thought I already WONTFIX'd this but it appears it was another ticket.

Code in core is not the way to do this - Publicity is.

We could promote this fact in the 3.1 release announcement as a reminder

comment:11 follow-up: @aaroncampbell4 years ago

While I agree that code in core to tell people to upgrade needlessly is clearly bloat (like telling IE 6 users to switch to Firefox, etc), I think this differs in two ways:

  1. It's not arbitrary. Version 3.2 will require PHP 5. For those on PHP 4 who use auto-update and don't look at the release notes, they're going to be quite surprised when they try to upgrade to 3.2.
  2. It's basically temporary code. It only "bloats" a single release. Any code that's put in now can be removed from trunk as soon as the 3.1 branch is created.

However, I don't know if this needs to be a notice in the admin. We could just as easily make the upgrader fail out with a message to the user if they try to upgrade to 3.2 and don't have PHP 5.2+.

I agree that this should be publicized, but I guess I just don't see the harm in putting this info in as many places as possible...including core. It's not like we're bumping our requirements from php 4.3 to 4.3.1. We're really raising the bar here. I know that we generally try to use the 80/20 rule, and this definitely only affects 10% of our users, but it seems that it would be an acceptable concession to add a few lines of code *temporarily* to help them out. They are probably among our least-informed and least-tech-savvy users, needing the most they can get.

comment:12 in reply to: ↑ 11 @westi4 years ago

Replying to aaroncampbell:

While I agree that code in core to tell people to upgrade needlessly is clearly bloat (like telling IE 6 users to switch to Firefox, etc), I think this differs in two ways:

  1. It's not arbitrary. Version 3.2 will require PHP 5. For those on PHP 4 who use auto-update and don't look at the release notes, they're going to be quite surprised when they try to upgrade to 3.2.
  2. It's basically temporary code. It only "bloats" a single release. Any code that's put in now can be removed from trunk as soon as the 3.1 branch is created.

However, I don't know if this needs to be a notice in the admin. We could just as easily make the upgrader fail out with a message to the user if they try to upgrade to 3.2 and don't have PHP 5.2+.

As far as I know the upgrader all ready does this and has done since possibly 2.9 as we upped the required mysql version

comment:13 @westi4 years ago

  • Milestone 3.1 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

We already have PHP and MYSQL version upgrade blocking in the core auto-upgrader.

So when we hike the version numbers users will not be able to upgrade and will clearly see this.

This issue is much better addresses with advocacy over core code.

Note: See TracTickets for help on using tickets.