getEditedPostContext() doesn't return what it used to.

[Hug0-Drelon]

Description

What?

getEditedPostContext() selector from the Site Editor store doesn't return what it used to as of WordPress 6.5.
Also it seems to be deprecated reading this, but no warning is raised in the console.

Given that, I think it breaks backward compatibility. For instance, it broke Polylang Pro plugin sidebar in the Site Editor.

Here is a summary of what we got (might not be exhaustive be we can get an idea):

• WP 6.1 => didn't exist yet!
• WP 6.2 => returns {templateSlug: your-template-slug} but only for templates, not template parts! (which are the only entities managed in Site Editor at this point).
• WP 6.3 => returns {templateSlug: your-template-slug} for global style, page as template (e.g. 404), templates. Otherwise {postType: 'your-post-type', postId: 'your-post-id', templateSlug: 'if-applicable'} for patterns or undefined for navigation.
• WP 6.4 => returns same as WP 6.3
• WP 6.5 => returns always {}...

We manage to find a way to fix this in Polylang Pro plugin, but it'd be great to have some insight on how to get the current post type and post id (currently we're using getEditedPostId() and getEditedPostType() but it doesn't return the same values for global styles for instance).

In other words, we would like to have a trustful way of retrieving the current edited post type and post id.

Step-by-step reproduction instructions

Call getEditedPostContext() in several WordPress versions.
Call getEditedPostId() and getEditedPostType().

Screenshots, screen recording, code snippet

No response

Environment info

We reproduce with Polylang Pro activated of course, but any plugin using getEditedPostContext() could face this issue.

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

No

[talldan]

Possibly the getCurrentPostType/getCurrentPostId selectors from the core/editor store might be the best way in future.

I'm not sure the back compatibility break was intentional. I think @youknowriad has been working on some of this so might know more.

[youknowriad]

Yes, Call getEditedPostId() and getEditedPostType() should be the way forward given that the site and post editor will ultimately merge. That said, I'm not sure why the context is returning empty for now. I'd expect to still return the right postId and postType when your opening a "page" in the site editor but I also expect it to return empty if you're actually loading a template or template part in the site editor.

[youknowriad]

Can you share more in which case it's returning empty for you?

[annezazu]

@Hug0-Drelon tagging you once more in case you can follow up on this as we're in the midst of the 6.5 release cycle.

[Hug0-Drelon]

Sorry for the delay @youknowriad.
So here is what I get throughout the Site Editor, using wp.data.select( 'core/edit-site' ).getEditedPostContext() in my dev tools.

• empty object {} for all screens
• except on https://mysite.site/wp-admin/site-editor.php?postType=page&postId=n&canvas=edit and https://mysite.site/wp-admin/site-editor.php?postType=page&postId=n where I get {postType: 'page', postId: 'n'}.
  I hope it helps.

[youknowriad]

So here is what I get throughout the Site Editor, using wp.data.select( 'core/edit-site' ).getEditedPostContext() in my dev tools.
empty object {} for all screens
except on https://mysite.site/wp-admin/site-editor.php?postType=page&postId=n&canvas=edit and https://mysite.site/wp-admin/site-editor.php?postType=page&postId=n where I get {postType: 'page', postId: 'n'}.
I hope it helps.

This matches my expectation personally, the page are the only places where we actually set a "context" for the block editor template. For the others, there's no need.

[Hug0-Drelon]

Hi @youknowriad,

Could you explain why there is no need for other screens (e.g. Navigations, Patterns, Templates, Global Styles...) to have a context?
For all I know, {postType: 'wp_navigation', postId: 'n'} could refer to a valid Navigation context.
Also, getEditedPostContext() is public API by design. Then changing the return values from one version to the other is a regression.

In other word, I don't mind getEditedPostContext() changes since I managed to go around it. I just want to understand why sometimes it's used and sometimes it's not.

[youknowriad]

The getEditedPostContext is for the block editor context.

• For instance when we render a template in a block editor and we want to fill the post content, post title blocks... with the right post information, we provide the postId and postType, that's what blocks consume using the useContext property of the blocks to render the right information.

• When editing template and template parts, navigation ... though, we want the block editor to show placeholders for post title, post content... which means we need an empty context.

[Hug0-Drelon]

Thanks for the insight @youknowriad!

[youknowriad]

Closing this for now. Thanks @Hug0-Drelon