Make WordPress Core

Opened 9 years ago

Last modified 3 years ago

#35554 new enhancement

De-emphasise WordPress Version in the admin

Reported by: dd32's profile dd32 Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch needs-testing
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 9 years ago.
remove-all-version-mentions.diff (4.0 KB) - added by dd32 9 years ago.
35554.front-end-html-source.PNG (92.6 KB) - added by SergeyBiryukov 8 years ago.
35554.diff (77.5 KB) - added by danieltj 7 years ago.
Removes WordPress version and moves current active theme.
at-a-glance-meta-box-35554-diff.png (20.2 KB) - added by danieltj 7 years ago.
Screenshot of what 35554.diff looks like.
35554-2.png (19.6 KB) - added by danieltj 7 years ago.
Example of what 35554.2.diff looks like
35554.2.diff (78.8 KB) - added by danieltj 7 years ago.
Further updates to 35554 original patch

Download all attachments as: .zip

Change History (64)

@dd32
9 years ago

#1 @ocean90
9 years ago

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

#2 @stephenharris
9 years 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
9 years 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
9 years 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
9 years 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
9 years 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
9 years 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
9 years 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
8 years 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
8 years 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
8 years ago

In 39583:

Remove the WordPress version number from readme.html.

See #35554

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


8 years ago

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

I feel the same as @dd32 too.

#20 @ocean90
8 years ago

#39723 was marked as a duplicate.

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


8 years ago

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


8 years ago

#28 @jbpaul17
8 years ago

  • Milestone changed from 4.8 to 4.8.1

Punting to 4.8.1 per today's bug scrub.

#29 @johnbillion
8 years 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.


7 years ago

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


7 years ago

#32 @jbpaul17
7 years 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
7 years ago

Removes WordPress version and moves current active theme.

@danieltj
7 years ago

Screenshot of what 35554.diff looks like.

#33 @danieltj
7 years 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.


7 years ago

#35 follow-up: @joyously
7 years 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
7 years 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
7 years 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
7 years 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
7 years ago

  • Keywords ui-feedback added

#40 @melchoyce
7 years 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
7 years 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.


7 years ago

#43 @seanchayes
7 years 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
7 years ago

Example of what 35554.2.diff looks like

@danieltj
7 years ago

Further updates to 35554 original patch

#44 @danieltj
7 years 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.


7 years ago

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


7 years ago

#47 @jbpaul17
7 years 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.


7 years ago

#49 @JoshuaWold
6 years ago

At our Core Contributor day in WCEU 2018 we were able to review this ticket as part of Triage.

From our perspective:

  1. We don’t have any data to validate that there is harm in keeping the version number as is. However, there is anecdotal responses suggesting it’s useful for supporting website owners by keeping it where it is.
  2. Also, we don’t see outlined in here the “why”, why would we de-emphasize the version? Do we have proof that any change should be made?

So we absolutely welcome further feedback, but at this time our recommendation is to close this ticket out.

#50 @swissspidy
6 years ago

why would we de-emphasize the version? Do we have proof that any change should be made?

It's one of the things needed for making WordPress essentially version-less, e.g. like Google Chrome.

#51 @joyously
6 years ago

It's one of the things needed for making WordPress essentially version-less, e.g. like Google Chrome.

That sounds to me like a reason to leave the version visible. Chrome is not a good model to follow. For instance, one of the reasons I do not use Chrome is because I have no control over the version. I do not like auto-updates. Yes, I may be in the minority, but that is what is. For a website, there are many moving parts, and having things auto-update introduces more chance for problems, especially for custom plugins.

I am against WP being version-less and WP auto-updating major versions.

#52 @wturrell
6 years ago

Since I last commented on this (# 12), I don't feel anyone has made an especially compelling argument for how partially removing the version number improves the user experience.

Terms like "De-emphasise" and "making WordPress essentially version-less" are pretty vague; also I don't understand how the latter is achievable. I think to justify this change, someone needs to be able to clearly explain how partially concealing versions is of a practical benefit to those maintaining sites.

Let's suppose the issue is the version number isn't deemed important to some users, or contributes to making the UI "cluttered". In this case, then remove it completely, or better still, leave it by default, but ensure there are hooks for those who do want to hide it to be able to easily do so (much like the default admin dashboard panels can be removed). This might also be convenient for anyone who wants to keep a WP installation running on an older major release (although hopefully still applying the security updates) whilst avoiding pressure from clients to upgrade.

Don't though, just arbitrarily remove part of the version. That helps no-one: it doesn't save any space, it won't stop users being "distracted" by it when using the UI, all it will do is create uncertainty about which version is actually installed, and lengthen the process of checking the exact version via the admin area.

If anything, the patch release (for want of a better term, I realise WP doesn't follow strict semantic versioning) is arguably the most crucial part, as it indicates the site is secure against the most recent security vulnerabilities. It also can't be relied on that an installation will self-update - this may be disabled, deliberately or accidentally, or there could be similar issues to 4.9.3 which cause sites to become stuck.

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


6 years ago

#54 @karmatosed
6 years ago

  • Keywords ui-feedback removed

For now I am removing the design feedback keyword as this has that. We can always add it back in.

#56 @SergeyBiryukov
4 years ago

In 48709:

Upgrade/Install: Show the installed WordPress version number on WordPress Updates screen if there is a newer version available.

This makes it easier for a user to know how significant of an update the change might be, and helps them make an informed decision about how to proceed.

Props tmdesigned, dd32, circlecube, dkarfa, hakre, scribu, MadtownLems, markshep, nbachiyski, dmchale, miqrogroove, ovann86, danieltj, sterndata, seanpaulrasmussen, mrgrt, Commeuneimage, dpacks, puneetsahalot, jonoaldersonwp, SergeyBiryukov.
Fixes #15101. See #35554, #47848.

#57 @Clorith
3 years ago

Since this tickets creation, Site Health was also implemented within WordPress, where the version numbers are available, which is also where most support requests (to use that angle) would hopefully be asking for information from these days.

Should the removal of versions also include the wp-admin footer showing the version? (See also #50272 which wishes to remove this in favor of Site Health).

Note: See TracTickets for help on using tickets.