WordPress.org

Make WordPress Core

Opened 21 months ago

Last modified 2 weeks ago

#35554 new enhancement

De-emphasise WordPress Version in the admin

Reported by: dd32 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch needs-testing ui-feedback
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 (7)

major.minor.diff (1.3 KB) - added by dd32 21 months ago.
remove-all-version-mentions.diff (4.0 KB) - added by dd32 21 months ago.
35554.front-end-html-source.PNG (92.6 KB) - added by SergeyBiryukov 7 months ago.
35554.diff (77.5 KB) - added by danieltj 6 weeks ago.
Removes WordPress version and moves current active theme.
at-a-glance-meta-box-35554-diff.png (20.2 KB) - added by danieltj 6 weeks ago.
Screenshot of what 35554.diff looks like.
35554-2.png (19.6 KB) - added by danieltj 3 weeks ago.
Example of what 35554.2.diff looks like
35554.2.diff (78.8 KB) - added by danieltj 3 weeks ago.
Further updates to 35554 original patch

Download all attachments as: .zip

Change History (55)

@dd32
21 months ago

#1 @ocean90
21 months ago

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

#2 @stephenharris
21 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
21 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
21 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
21 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
21 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
21 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
20 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
10 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
10 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
10 months ago

In 39583:

Remove the WordPress version number from readme.html.

See #35554

#12 @wturrell
10 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
10 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
10 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
10 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.


9 months ago

#17 in reply to: ↑ 15 @rawrly
9 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
9 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
9 months ago

I feel the same as @dd32 too.

#20 @ocean90
9 months ago

#39723 was marked as a duplicate.

#21 follow-up: @Moosje
9 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
9 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
9 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
7 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
7 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.


5 months ago

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


5 months ago

#28 @jbpaul17
5 months ago

  • Milestone changed from 4.8 to 4.8.1

Punting to 4.8.1 per today's bug scrub.

#29 @johnbillion
4 months ago

  • Summary changed from De-emphasis WordPress Version in the admin to De-emphasise WordPress Version in the admin

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


3 months ago

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


3 months ago

#32 @jbpaul17
3 months ago

  • Milestone changed from 4.8.1 to 4.9

Per today's bug scrub, we'll punt this as the focus for 4.8.1 is regressions only.

@danieltj
6 weeks ago

Removes WordPress version and moves current active theme.

@danieltj
6 weeks ago

Screenshot of what 35554.diff looks like.

#33 @danieltj
6 weeks ago

  • Keywords needs-testing added

I've added a patch above which removes the WordPress versioning in the At a Glance meta box and moves the current theme up into the list of meta boxes now. I think this works well as it removes the versioning from being displayed there so prominently but also keeps the current theme in view in that meta box.

What is everyones thoughts on this? My idea with this approach was it was the best of both worlds and doesn't change things up to drastically.

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


4 weeks ago

#35 follow-up: @joyously
4 weeks ago

Several people have given good reasons to continue showing the complete version in the admin.
No one has given any good reason to remove the version number from the admin.

I think this ticket is a "dehancement" instead of an "enhancement".

#36 in reply to: ↑ 35 ; follow-up: @danieltj
3 weeks ago

Replying to joyously:

Several people have given good reasons to continue showing the complete version in the admin.
No one has given any good reason to remove the version number from the admin.

I think this ticket is a "dehancement" instead of an "enhancement".

I disagree, the version of WordPress is still shown in the bottom right hand corner of the WordPress admin footer. Some people may not have the At a Glance meta box shown on the dashboard, so putting the version number there is not important. Also, to add; it makes much more sense having the theme shown there with a dashicon than next to the version number I think, personally.

#37 in reply to: ↑ 36 ; follow-up: @SergeyBiryukov
3 weeks ago

Replying to danieltj:

I disagree, the version of WordPress is still shown in the bottom right hand corner of the WordPress admin footer.

Not if there's a newer version available, see #15101 and #31046.

If we go with 35554.diff, at least attachment:31046.diff:ticket:15101 should go in as well.

#38 in reply to: ↑ 37 @danieltj
3 weeks ago

Replying to SergeyBiryukov:

Replying to danieltj:

I disagree, the version of WordPress is still shown in the bottom right hand corner of the WordPress admin footer.

Not if there's a newer version available, see #15101 and #31046.

If we go with 35554.diff, at least attachment:31046.diff:ticket:15101 should go in as well.

I think combining those two would be the best course of action.

Although keeping the version number there as it is might not be as elegant as it could be. Give me until later on tonight and I'll try and get another patch that combines both that still keeps within the elegance of At a Glance. I think I can improve my patch further.

#39 @melchoyce
3 weeks ago

  • Keywords ui-feedback added

#40 @melchoyce
3 weeks ago

FWIW, I'd rather remove it from most places and then have one place (like about.php) where you can see the full version, than truncate away the point version — I agree that just removing the point version could make it harder for support folks to triage issues.

#41 @joyously
3 weeks ago

This ticket doesn't enhance anything. It only hides something that is needed in certain situations.
There is no advantage to displaying 4.8 when it is really 4.8.2.
It just adds obscurity. There is no benefit.
I think it would add confusion for users when dealing with updates and problem solving. And trying to find where WordPress hides the version number when you are trying to troubleshoot a problem just adds to the stress of the problem. If it is visible at the bottom of the admin, it is one of those reassuring things that all is as it should be.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


3 weeks ago

#43 @seanchayes
3 weeks ago

I still feel that some users would like to know the exact version they are on and perhaps add to any patch on this ticket have the display of version information filterable so larger installations, corporates and other parties can, at a glance, see this information or direct someone to report this information.

@danieltj
3 weeks ago

Example of what 35554.2.diff looks like

@danieltj
3 weeks ago

Further updates to 35554 original patch

#44 @danieltj
3 weeks ago

I've updated the original patch that I did. It now shows the version number with the other stats with a Dashicon that I thought fits quite well. The link will take you to about.php or update-core.php if there is an update available. Also requires that you have the update core capability to see the version number with a link there in that meta box.

I think this is the best course of action. It makes the box look uniformed by default but still retains the important information in that section. I've tested it and works fine, but can someone else please double check just in case. Thanks.

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


3 weeks ago

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


2 weeks ago

#47 @jbpaul17
2 weeks ago

  • Milestone changed from 4.9 to Future Release

Punting to Future Release per today's 4.8 bug scrub.

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


2 weeks ago

Note: See TracTickets for help on using tickets.