WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 11 months 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 17 months ago.
Site Health Info screen

Download all attachments as: .zip

Change History (30)

#1 follow-up: @jorbin
2 years 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 2 years ago by jorbin (previous) (diff)

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


2 years ago

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


2 years ago

#4 @Clorith
2 years 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
2 years 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
21 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
20 months ago

#49409 was marked as a duplicate.

#8 @ocean90
17 months ago

#50090 was marked as a duplicate.

#9 @paaljoachim
17 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 17 months ago by SergeyBiryukov (previous) (diff)

@paaljoachim
17 months ago

Site Health Info screen

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


17 months ago

#11 follow-up: @mapk
17 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
17 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 17 months ago by paaljoachim (previous) (diff)

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


17 months ago

#14 @SergeyBiryukov
17 months ago

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

#15 @SergeyBiryukov
17 months ago

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

#16 @Clorith
17 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.


16 months ago

#18 @mapk
16 months 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.


16 months ago

#20 @Clorith
16 months 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.


16 months ago

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


15 months ago

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


15 months ago

#24 @paaljoachim
15 months 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.


15 months ago

#26 @Clorith
15 months 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

#27 @annezazu
14 months ago

Just to close the loop in case anyone else returns to this issue in the future, this document was created listing Gutenberg Versions in WordPress: https://developer.wordpress.org/block-editor/principles/versions-in-wordpress/ This was the result of the issue mentioned above: https://github.com/WordPress/gutenberg/issues/23344

#28 @pablogreenpeace
11 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Hi, I also spent the last 10 or 20 minutes trying to figure out what version of Gutenberg is installed.

It is called a "plugin" but is not shown under plugins. Is not showing anywhere in the dashboard. There are features that relate to specific versions, for example: the Block Directory is enabled since version 8.4. So I need to know the specific version. Not a range of versions.

I read this whole conversation, the "versions" standalone page, and this issue: https://github.com/WordPress/gutenberg/issues/23344#issuecomment-652635643

But it's not use if I can't get the specific version.

For example, the issue says:

Gutenberg Versions
7.6, 7.7, 7.8, 7.9, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5

WordPress Version
5.5

So how do I check for the specific version? Do I need to download & install the plugin? I've been developing Gutenberg blocks with no issues without installing the plugin.

I think the need to check which specific version of Gutenberg is currently running is key. Is not just any component, it's really tied to the core.

Thanks in advance.

---
Edit: I just installed the plugin to see what changes, in the issue I linked, for version 5.4 (my local version) it says:

Gutenberg
6.6, 6.7, 6.8, 6.9, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5

WP
5.4.2

I just installed the plugin, its version is 9.2.1, it showed no warnings.

This is all very confusing!

Cheers.

Last edited 11 months ago by pablogreenpeace (previous) (diff)

#29 @Clorith
11 months ago

  • Resolution set to wontfix
  • Status changed from reopened to closed

Hi,

So there's the plugin, Gutenberg, and it has many different features which go into WordPress in a major release. But once parts of its features are put into WordPress, they become a part of core, and are not considered a plugin at all (yes, this can be confusing, because the features do still live in the plugin as well, for those who have not updated WordPress it self yet, but are trying out new features, for example).

The document at https://developer.wordpress.org/block-editor/handbook/versions-in-wordpress/ shows the relationship of which versions of the plugin (and thus which features) were included in a given WordPress release.

For example, the upcoming (at this time) WordPress 5.6 will have the equivalent of the Gutenberg plugin version 9.2 included.

The listing shows 8.5.1 - 9.2, this just summarizes the versions included between the last two releases of WordPress it self (and helps developers know what minimum set of features are available if they integrate with the block editor, or any other aspect of the Gutenberg project).


Unfortunately, as Gutenberg is a project with many focus areas, and not a singular element (like just the block editor), there's no good way to distinguish between the individual features and display them all in core in a reliable and useful manner, beyond the document as described.

Note: See TracTickets for help on using tickets.