Opened 5 years ago
Closed 4 years 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
Attachments (1)
Change History (30)
This ticket was mentioned in Slack in #design by mapk. View the logs.
5 years ago
This ticket was mentioned in Slack in #core-site-health by mapk. View the logs.
5 years ago
#4
@
5 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.
#6
@
5 years 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
#9
@
5 years 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.
This ticket was mentioned in Slack in #core-editor by paaljoachim. View the logs.
5 years ago
#12
in reply to:
↑ 11
@
5 years 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.
That looks good!
This ticket was mentioned in Slack in #core by paaljoachim. View the logs.
5 years ago
#14
@
5 years ago
- Component changed from General to Site Health
- Milestone changed from Awaiting Review to 5.5
#16
@
5 years 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.
5 years ago
#18
@
5 years 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?
- Is the person reporting a bug, but doesn't know the version because they don't have the plugin?
- 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.
5 years ago
#20
@
5 years 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.
5 years ago
This ticket was mentioned in Slack in #core-editor by nerrad. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-editor by annezazu. View the logs.
4 years ago
#24
@
4 years 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.
4 years ago
#26
@
4 years 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
@
4 years 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
@
4 years 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.
#29
@
4 years 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.
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.