WordPress.org

Make WordPress Core

Opened 17 months ago

Last modified 3 weeks ago

#35554 new enhancement

De-emphasise WordPress Version in the admin

Reported by: dd32 Owned by:
Milestone: 4.8.1 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch
Focuses: Cc:

Description

Currently WordPress is very proud of the version it's running - but version strings are not exactly the most important piece of information to a regular user.
I'd like to bring it back to displaying only the major version (ie. Version 4.4, not Version 4.4.1).

A few of us have kicked the idea around over the years, and making the version number less specific as we move towards faster point releases really makes a lot of sense.

There's two options which could be taken:

  1. Simply bring it back to x.y (Version 4.4). attachment:major.minor.diff
  2. Remove it entirely, including the You are running WordPress x.y.z running Theme X theme. message in the at-a-glance widget. attachment:remove-all-version-mentions.diff

The second option is a harder-line approach, but removes information that most users have no need to see most of the time. They'll still see update nags when a new version comes out (Well, except for the million or more of sites which choose to enable automatic updates for major versions too) and the version string will always be available on the update screen where it's useful.

Attachments (3)

major.minor.diff (1.3 KB) - added by dd32 17 months ago.
remove-all-version-mentions.diff (4.0 KB) - added by dd32 17 months ago.
35554.front-end-html-source.PNG (92.6 KB) - added by SergeyBiryukov 3 months ago.

Download all attachments as: .zip

Change History (32)

@dd32
17 months ago

#1 @ocean90
17 months ago

+1. Most applications just show the (complete) version on an about page.

#2 @stephenharris
17 months ago

I think of the two, remove completely: having just the major version is misleading. If you were to ask a user "what version are you using?" they would probably use the 'At a Glance' metabox and report "4.4" whereas in fact they are running 4.4.1 - and when diagnosing a problem, patch versions can matter.

Yes, this information is available on the about page - but until just now I had completely forgotten about it. So if a version is present in the 'At a Glance' metabox, they will almost certainly use that.

As @ocean90 points out most applications only show the version number on an about page, and the WordPress icon in the top left feels like a natural place to look. Incidentally, it was only after thinking 'Ok, if the version number had completely disappeared, where would I get that information' that I rediscovered it...

#3 @swissspidy
17 months ago

Yes, this information is available on the about page - but until just now I had completely forgotten about it. [...] the WordPress icon in the top left feels like a natural place to look

I've seen people thinking it's just a logo, not an actual menu. Also, "About WordPress" sounds like it might be a link to some external site showing the benefits of WordPress. I think the wording could be improved there.

#4 @dd32
17 months ago

If you were to ask a user "what version are you using?" they would probably use the 'At a Glance' metabox and report "4.4" whereas in fact they are running 4.4.1 - and when diagnosing a problem, patch versions can matter.

That's true to an extent, however the minor version is not as often needed as many make it out to be. Simply knowing if they're running the latest in the branch or not is quite often enough. If all facing text of Version x.y was switched out to Update to x.y.z instead (with most users never seeing that thanks to background updates) then that would become less of a problem. Users should be encouraged to update before seeking troubleshooting details IMHO.

I'm feeling more inclined towards removing it all honestly, however IMHO that would require the updates page to be far more user-friendly and clear cut. I'm not sure I find the About screen as being the defacto location a user should go to to find out a version number what a user would expect. I'm not sure the desktop-application argument sways me there at all.

#5 in reply to: ↑ description ; follow-up: @SergeyBiryukov
17 months ago

Replying to dd32:

version strings are not exactly the most important piece of information to a regular user.

I'd argue it's important in terms of support :)

I'm feeling more inclined towards removing it all honestly, however IMHO that would require the updates page to be far more user-friendly and clear cut.

Related: #15101

#6 in reply to: ↑ 5 @dd32
17 months ago

Replying to SergeyBiryukov:

Replying to dd32:

version strings are not exactly the most important piece of information to a regular user.

I'd argue it's important in terms of support :)

And we definitely shouldn't remove all traces of the version for that reason alone, however it doesn't need to be front-and-center :)

#7 @seanchayes
17 months ago

How about keeping the version number and perhaps also linking it to the about page?

That way we could still choose to display the version as major, major.minor or major.minor.patch using option 1 or 2 as outlined in this ticket and if it also linked to about.php then along with the version number there is the rest of the About information.

#8 @wturrell
16 months ago

How about adding the PHP version?

I see requests from time to time from users on shared/managed hosting who aren't sure what PHP version they're running, inevitably followed by someone telling them to upload a file with <?php phpinfo(); ?> (and not always telling them to remove it afterwards.)

echo phpversion(); could be added to At a Glance? (#dashboard_right_now)

#9 @dd32
7 months ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Awaiting Review to 4.8

How about adding the PHP version?

I'm against adding any system information to an area designated for end-users, most users don't understand those things and shouldn't need to. There's tickets elsewhere to add a hidden debug screen for all kinds of data though.

I'm milestoning this for 4.8, as I believe it's time we make a move here.

#10 @dd32
7 months ago

In 39582:

De-Emphasise the minor (x.y.Z) version in readme.html by including only the major version for the 4.7 branch.

See #35554

#11 @dd32
7 months ago

In 39583:

Remove the WordPress version number from readme.html.

See #35554

#12 @wturrell
7 months ago

I didn't discuss the WP version in my first comment and I wanted to agree with @stephenharris – either include the correct version or not at all. Only printing partial information introduces confusion (especially when x.y.z has been there previously) and creates extra work for those providing support.

People may also read a security announcement and want to quickly double-check a WP installation has successfully auto-updated itself or if they need to do so manually.

I've also always thought it a mistake that as soon as an upgrade *is* available, it becomes harder to identify the version you are currently running, with all the WordPress 4.6.1 messages replaced by 'Get WordPress 4.7' and the current version not shown on update-core.php either (unless you have a plugin that's out of date and you're knowledgeable enough to look for the 'Compatibility with...' message.)

I think the 'About' page will only be intuitive to those who have chosen to navigate to it at least once before. It being shown after an upgrade doesn't really count – people won't look at the URL and there's no visual highlighting of the logo as there is when you're within the Posts section, for example.

I agree with removing ALL version details from readme.html (for security, not that it will stop probing by bots).

#13 @knutsp
7 months ago

The only occasion I browse to readme.html is when there is a status 500 or white screen. I wonder if there has been an (auto) update or not, conflicting with theme or plugins. So please leave all digits in.

In the admin, I miss version info in the footer (right) when there is a new version available. No reason to replace that in case of a pending update. Agree with @wturrell.

On update-core.php, remove version numbers, and mention only a new version available.

On about.php leave detailed version info.

#14 @pcfreak30
6 months ago

@knutsp I am against having the version in the readme.html at all. It is a security risk and I would delete the file but its added back every update. Its not good for the front end to ever expose a version number. To that effect, I would think removing it from the generators meta should be done too.

#15 follow-up: @dd32
6 months ago

I'm going to put a general request out there:

Please do not consider this a security ticket; It's not. It's a user-experience ticket.

Showing version numbers is not a security risk and removing them does nothing to protect sites.
You can read the rehashed topic in #23394 and make all the arguments there, this ticket is not the place.

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


6 months ago

#17 in reply to: ↑ 15 @rawrly
6 months ago

Replying to dd32:

I'm going to put a general request out there:

Please do not consider this a security ticket; It's not. It's a user-experience ticket.

Showing version numbers is not a security risk and removing them does nothing to protect sites.
You can read the rehashed topic in #23394 and make all the arguments there, this ticket is not the place.

I don't wish to rehash the security topic, but the utilization of the readme file's version string is what many third party utilities rely on for accurate version reporting for WordPress. It has some indirect security concerns if this gets removed or truncate to only major releases.

Removal of this version string's minor release version would result in some security utilities either choose to inaccurately reporting a site's version (reporting it as vulnerable when it is not, resulting in requirement of the site owners to file appeals), or scan engines to have to become more resource intensive on how they determine a site's accurate version number (this is both resource intensive on their time to code, as well as server resources as they may attempt more requests to get an accurate version). Ultimately if I were to guess, the former will be what will happen in most cases.

Current third party utilities which rely on the site's readme file for accurate version identification are (I personally validated their source):
wpscan
nmap
metasploit
and many more security utilities...

I'm not making an argument that the change is incorrect or bad for any reason, I am only stating a side effect that will occur.

This change will make things look cleaner for most site operators, but it will likely also result in problems for site owners who are utilizing third party utilities for site security monitoring.

#18 @dd32
6 months ago

utilization of the readme file's version string is what many third party utilities rely on for accurate version reporting for WordPress

These items should probably move to utilising the Generator meta fields or another source, I don't think that's enough of a reason to retain the version in the readme.html - especially when it can often be blocked or removed.

#19 @pcfreak30
6 months ago

I feel the same as @dd32 too.

#20 @ocean90
5 months ago

#39723 was marked as a duplicate.

#21 follow-up: @Moosje
5 months ago

I use the readme.html file to check if clients did update their Wordpress website. For the about page you need to log in first, that takes more time and I don't have all the logins.
So it would be very helpfull for me to have the complete version in the readme file

#22 in reply to: ↑ 21 ; follow-up: @SergeyBiryukov
5 months ago

Replying to Moosje:

For the about page you need to log in first, that takes more time and I don't have all the logins.

You could check the HTML source of front-end pages, the version should be present in the generator meta tag. It's also appended to JS scripts for cache busting, e.g. wp-emoji.js?ver=4.6.3.

#23 @Moosje
5 months ago

That's also possible, but the generator meta tag is not always there, checking the html source of the front-end page is also possible but it's a longer way. For me to have a list with readme.html files I click and see if it's ok is the fastest way.

#24 in reply to: ↑ 22 ; follow-up: @heiseybj
3 months ago

Replying to SergeyBiryukov:

Replying to Moosje:

For the about page you need to log in first, that takes more time and I don't have all the logins.

You could check the HTML source of front-end pages, the version should be present in the generator meta tag. It's also appended to JS scripts for cache busting, e.g. wp-emoji.js?ver=4.6.3.

In my staging environment (I am testing 4.7.3), I see no place that says more than 4.7 in the view-source of the front page. This presents a enterprise problem as I need to be able to show that I have performed the upgrade from 4.7.2 to 4.7.3. I just need to be able to expose the full version number to be able to allay security concerns.

#25 in reply to: ↑ 24 @SergeyBiryukov
3 months ago

Replying to heiseybj:

In my staging environment (I am testing 4.7.3), I see no place that says more than 4.7 in the view-source of the front page.

Make sure you've actually updated to 4.7.3 and are not using any plugins that might alter the version. Here's a screenshot of view-source on a clean install with Twenty Seventeen: 35554.front-end-html-source.PNG.

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


7 weeks ago

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


7 weeks ago

#28 @jbpaul17
7 weeks ago

  • Milestone changed from 4.8 to 4.8.1

Punting to 4.8.1 per today's bug scrub.

#29 @johnbillion
3 weeks ago

  • Summary changed from De-emphasis WordPress Version in the admin to De-emphasise WordPress Version in the admin
Note: See TracTickets for help on using tickets.