WordPress.org

Make WordPress Core

Opened 9 months ago

Closed 2 weeks ago

#48329 closed feature request (wontfix)

Show Gutenberg version in Core

Reported by: mapk Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Site Health Keywords: has-screenshots
Focuses: Cc:

Description

There have been a few requests to see which Gutenberg version is included in Core. Here's an example of one: https://github.com/WordPress/gutenberg/issues/14708

It was closed due to cherry-picking updates to include in Core, but maybe we can still show the latest version of Gutenberg that was included with Core regardless?

Adding this in the wp-admin footer seems like a good place to do this. I'm uncertain if this should say "Gutenberg version" or just "Block Editor version" seeing as we don't use the word "Gutenberg" in Core. But at the same time this specifically refers to the Gutenberg plugin version that was merged into Core.

Gutenberg version

http://cldup.com/5iw3-fCB4k.png

Block Editor version

http://cldup.com/IfhLxpQQc7.png

Attachments (1)

Site-Health-Info.png (255.3 KB) - added by paaljoachim 2 months ago.
Site Health Info screen

Download all attachments as: .zip

Change History (27)

#1 follow-up: @jorbin
9 months ago

I'm not sure I like the idea of showing different components versions, especially as a long term goal has been that version numbers don't matter to the majority of people.

I do think this could be useful to add to the health check though. Essentially making it discoverable but not prominent. It could also help with debugging.

Last edited 9 months ago by jorbin (previous) (diff)

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


9 months ago

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


9 months ago

#4 @Clorith
9 months ago

I'm with @jorbin that adding various component versions will get messy, and confusing to users in the long run.

Fitting this into the Site Health component is absolutely something we could do, and it would fit nicely in the Info tab along with the WordPress core verison and such under the WordPress section there.

We'd need to introduce the block editor version somewhere (probably version.php) if it's not already bundled somewhere, I'm only familiar with the composer file having this reference right now.

#5 in reply to: ↑ 1 @SergeyBiryukov
9 months ago

Replying to jorbin:

I'm not sure I like the idea of showing different components versions, especially as a long term goal has been that version numbers don't matter to the majority of people.

Yep, this seems to go the the opposite direction of #35554 :)

Also related: #15101, #31046, #47848.

#6 @netweb
6 months ago

From a developer point of view, I've spent the past ~10 minutes trying to determine which release of Gutenberg shipped with 5.3, 5.3.1, and 5.3.2

As I write this I do not have that answer :(

Adding this to /src/wp-includes/version.php would be great:


/**
 * The WordPress Block Editor version string
 */
$wp_block_editor_version = x.y.z;

Just had a thought, look at the Gutenberg version in gutenberg.php of the wp/trunk branch on GitHub

That results in 7.1.0 and satisfies my needs for now, not easily discoverable for developers to say the least

#7 @ocean90
5 months ago

#49409 was marked as a duplicate.

#8 @ocean90
2 months ago

#50090 was marked as a duplicate.

#9 @paaljoachim
2 months ago

I happen to create a new ticket #50090 on the same issue without searching first.
I would instead suggest to add Gutenberg plugin information to the WordPress accordion under the Site Health Info area.
Adding plugin version to the footer beside WordPress would be a bit much. Having it in the Site Health Info area would be the most natural place to add information about which Gutenberg plugin is included in Core.

The benefit of adding Gutenberg plugin information to Site Health is that we can at the same time educate people to where they find additional information about their web site.

Last edited 2 months ago by SergeyBiryukov (previous) (diff)

@paaljoachim
2 months ago

Site Health Info screen

This ticket was mentioned in Slack in #core-editor by paaljoachim. View the logs.


2 months ago

#11 follow-up: @mapk
2 months ago

Not a bad idea, @paaljoachim, to include it in the Site Health section. Here's how that might look... Note that I dropped the "Site Language" just for the purpose of this mockup. It would still exist, but just below the block editor version.

http://cldup.com/AIQ0N4QqnQ.png

#12 in reply to: ↑ 11 @paaljoachim
2 months ago

Replying to mapk:

Not a bad idea, @paaljoachim, to include it in the Site Health section. Here's how that might look... Note that I dropped the "Site Language" just for the purpose of this mockup. It would still exist, but just below the block editor version.

http://cldup.com/AIQ0N4QqnQ.png

That looks good!

Last edited 2 months ago by paaljoachim (previous) (diff)

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


2 months ago

#14 @SergeyBiryukov
2 months ago

  • Component changed from General to Site Health
  • Milestone changed from Awaiting Review to 5.5

#15 @SergeyBiryukov
2 months ago

  • Keywords needs-patch added; needs-design-feedback removed

#16 @Clorith
2 months ago

So, just to add some other points to the discussion, which will need discussing/clearing up.

The ticket uses Gutenberg/Block editor as synonyms, which is not the case.

Do we need to separate out the packages somehow, is that needed? For example "Gutenberg" as we view it is really a collection of a lot of NPM packages built together, all with different versions.

It should also be noted that using the Gutenberg plugin version as a reference to "Block editor" in core is also wrong. Gutenberg is a much larger codename (gah, the confusion) which covers not only the block editor, but also menus, widgets, full screen editing, customizer, it's way too much and shouldn't be filed in one pile, for consistency, what if a minor version backports a fix to a smaller components, and not to the whole editor, which would make the number shown be misleading.

Do we instead of listing packages and versions, need to list components and versions?

Example as of the time of this writing in trunk:

  • Block editor version 3.7.8 (based on the package @wordpress/block-editor)
  • But also; Block editor version 9.12.8 (based on the package @wordpress/editor) - what's the distinction here, and which takes priority?
  • Customizer version x.y.z (based on the package @wordpress/customizer which does not exist yet)
  • Menus version x.y.z (based on the package @wordpress/menus which does not exist yet)
  • ... and so on

But I'm not comfortable using just the Gutenberg plugin version as a reference point, as it's incorrect, and what happens when we're all happy with how things are and stop using the plugin and it's just "core" again, things like that :)

This ticket was mentioned in Slack in #core-editor by andraganescu. View the logs.


8 weeks ago

#18 @mapk
8 weeks ago

@Clorith, Ugh... your comment is spot on. I totally mixed the names up in the ticket's description. Thanks for clarifying.

The question comes up many times. Figuring out "why" is important in how we proceed. What problem are we trying to solve?

  1. Is the person reporting a bug, but doesn't know the version because they don't have the plugin?
  2. Is the person just trying to identify which version of the block editor they have?

Can we get wild with this?

Without the Gutenberg plugin activated:
"Block Editor Version 6.7"

With the Gutenberg plugin activated:
"Gutenberg Version 8.1" Actually show the plugin name. Or maybe we hide the row because the version can be found in the plugins screen?


Do we instead of listing packages and versions, need to list components and versions?

Quite possible!


what happens when we're all happy with how things are and stop using the plugin and it's just "core" again

Can we just remove this row completely when that happens?

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


7 weeks ago

#20 @Clorith
7 weeks ago

I like the idea of showing the block editor version, but how do we define it (based on my question about which package actually declares block editor versions, since it's not clear right now, and using the Gutenberg plugin version isn't reasonable given that it's so much more than just a block editor now).

As for how to approach it with the plugin, the plugin should filter the debug data and amend the block editor version accordingly instead of hiding or replacing the full entry I'd say.

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


6 weeks ago

This ticket was mentioned in Slack in #core-editor by nerrad. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core-editor by annezazu. View the logs.


3 weeks ago

#24 @paaljoachim
3 weeks ago

We discussed this ticket in the Site Health Slack channel a few weeks ago. No solution has yet found. It was brought up in the Core Editor channel today.

How can we approach this from a more basic angle?
How can we move this ticket forward?

I suggested adding WordPress versions and the Gutenberg plugin version these contain into the docs. Making it possible for developers to in a very basic way easily find which plugin is included in which WordPress version. It seems like the most logical way forward. The docs can also contain additional information which would not be space for in the WordPress section of Site Health tool.

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


2 weeks ago

#26 @Clorith
2 weeks ago

  • Keywords needs-patch removed
  • Milestone 5.5 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

After a bit of back and forth, I'm going to close this as wontfix. There's just no clarity in what defines the correct versions that would be expected (or what is to be expected as expected), and an approach with proper documentation on the relationship between core and plugin versions is instead being worked on, which is a much better approach at this time.

Should there ever become a clearer path on this, we can re-visit the ticket at that time.

Thank you all for your valuable input in trying to find a sensible path forward here, you can find the continuation of this at https://github.com/WordPress/gutenberg/issues/23344

Note: See TracTickets for help on using tickets.