Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Post Terms Block: Custom Taxonomies variations are not registered correctly #52569

Closed
gaambo opened this issue Jul 12, 2023 · 7 comments
Closed
Labels
Needs Testing Needs further testing to be confirmed. [Type] Bug An existing feature does not function as intended

Comments

@gaambo
Copy link
Contributor

gaambo commented Jul 12, 2023

Description

In #39837 (fix for #32924) support was added so that for all public taxonomies, variations of the core/post-terms block were added. But the hook to check for public taxonomies is run on init with a default priority of 10.
It's safe to asume, that this will run before many plugins will have registered their custom taxonomies, because the core init hook is added earlier and 10 is the default priority (so many developers will register it on 10 as well).

Proposed solution:

  1. Run the complete register_block_core_post_terms on a priority later than 10 (eg 100)
  2. Split the function and add variations for all public taxonomies in the editor in JavaScript (performance for fetching all taxonomies?)
  3. Split the function and add variations add a later point via PHP (not possible because server side version to register block variations is missing)

All other core blocks are registered on priority 10, so I think it would be a bit odd to run the register function for only this block on a later priority. Also of course we can't be 100% sure if on priority 100 all custom taxonomies are already registered (since developers also can use later priorities). So I guess I actually favor solution 2. Is there precedent for any solution like this?

I ran into this problem multiple times, and in the original PR @mrleemon originally found this bug.

Step-by-step reproduction instructions

Negative test:

  1. Register a custom taxonomy (example code from developer.wordpress.org).
  2. Go into site-editor and try to search for a block named like the custom taxonomy (eg "Courses").
  3. Block is not available, only the default "Tags" and "Categories" is available

Positive test:

  1. Register a custom taxonomy (example code from developer.wordpress.org) but change add_action priority to something lower than 10 (eg 9)
  2. Go into site-editor and try to search for a blog named as the custom taxonomy (eg "Courses").
  3. Block is available

Screenshots, screen recording, code snippet

No response

Environment info

  • WordPress 5.2

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

Yes

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

Yes

@gaambo
Copy link
Contributor Author

gaambo commented Jul 12, 2023

Thinking about proposed solution 2:
This might also be a chance, to only display variations of the post-terms block from taxonomies that are related to the current post type. That might be easy in the post-editor when editing a single post type. But when editing a template in the site-editor it might be more complex. I'm not sure about the internals, but as an example I've created a custom post type "event" and wanted to create a single-events template via the site editor. It let's me add the "tags" and "categories" allthough these taxonomies are not connected to the post type. So maybe in the editor we could filter if the post type is connected to a taxonomy, but I'm not sure how to get the post type a template is applied to (since it could also be a general single template, used for all post types)

@gaambo
Copy link
Contributor Author

gaambo commented Jul 12, 2023

I've tried a first attempt at solving this with my solution 1 from the op. I don't think it's good to go yet, but I wanted to try how that would work on the editor side.
Happy for any feedback/review/help :)

@jordesign jordesign added [Type] Bug An existing feature does not function as intended Needs Testing Needs further testing to be confirmed. labels Jul 12, 2023
@github-actions
Copy link

Hi,
This issue has gone 30 days without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest versions, you can help the project by responding to confirm the problem and by providing any updated reproduction steps.
Thanks for helping out.

@github-actions github-actions bot added the [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. label Aug 12, 2023
@gaambo
Copy link
Contributor Author

gaambo commented Aug 16, 2023

The problem described in the original issue is still there in current trunk and the reproducation steps still apply.

@github-actions github-actions bot removed the [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. label Aug 17, 2023
@github-actions
Copy link

Hi,
This issue has gone 30 days without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest versions, you can help the project by responding to confirm the problem and by providing any updated reproduction steps.
Thanks for helping out.

@github-actions github-actions bot added the [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. label Sep 17, 2023
@gaambo
Copy link
Contributor Author

gaambo commented Sep 18, 2023

Work for #53826 happens in #54434 atm. Since the issue is similar, I expect to reuse those results from there for this issues as well.

@github-actions github-actions bot removed the [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. label Sep 19, 2023
@gaambo
Copy link
Contributor Author

gaambo commented Feb 26, 2024

Was fixed in 2c247e2 via the new variation_callback argument when registering the block.

@gaambo gaambo closed this as completed Feb 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Testing Needs further testing to be confirmed. [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

2 participants