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

Plugins that have wp-blocks as a dependency break other plugins that use the filters in wp-blocks #14578

Closed
notnownikki opened this issue Mar 22, 2019 · 6 comments · Fixed by #34299
Assignees
Labels
[Feature] Blocks Overall functionality of blocks [Feature] Extensibility The ability to extend blocks or the editing experience [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@notnownikki
Copy link
Member

Describe the bug

If you have a plugin that needs to register a filter function for blocks.registerBlockType and it gets loaded after a plugin that requires wp-blocks to be loaded (e.g. Jetpack) then the plugin will not register its filter function in time for it to be applied.

To Reproduce
Steps to reproduce the behavior:

  1. Create a plugin that uses blocks.registerBlockType, make sure that its enqueue statements do not require wp-blocks as a dependency, (because it needs to load BEFORE that, so the filter can apply)
  2. Install and activate a plugin which depends on wp-blocks (e.g. Jetpack)
  3. See that the filter function in your plugin does not fire, because the plugin that depended on wp-blocks has made wp-blocks load too early for your plugin's filter function to be applied.

Expected behavior

Plugins should not be able to break other plugins by depending on wp-blocks. This may be affecting other filters too, but the ones in wp-blocks are the most obvious, because one of the most popular plugins for WP depends on wp-blocks, and so breaks all other plugins that use the filters.

@gziolo gziolo added [Feature] Extensibility The ability to extend blocks or the editing experience [Type] Bug An existing feature does not function as intended labels Mar 22, 2019
@gziolo
Copy link
Member

gziolo commented Mar 22, 2019

I was seeking some solution to this issue in the past: #10554. However, I don't plan to work further on this one since we are going to change the way how blocks can be registered after we agree on #13693. Depending on the final shape of blocks registration the solution proposed here might be completely different.

@gziolo gziolo added the [Feature] Blocks Overall functionality of blocks label Mar 22, 2019
@notnownikki
Copy link
Member Author

There's a PR at #14050 which is focused on providing an API for plugins to provide their own embed blocks, and hook into the URL -> Embed Block functionality. The code works, but I wrote a test to make sure that plugins using the API wouldn't break when Jetpack is installed, and that's how I found this bug - they do break.

Should I put that work on hold until the block registration work is complete?

@gziolo
Copy link
Member

gziolo commented Mar 25, 2019

Should I put that work on hold until the block registration work is complete?

It might take some time to finish all improvements to the block registration. So I don't know what would be the best way to tackle it.

@notnownikki
Copy link
Member Author

I think it had best wait, the current implementation relies on a filter, so if that's going to end up working after the registration work is complete then that's all good, if not then it would need quite a rework so I think it had best go on hold until the changes land and we can work with them in their final form. Thanks for the pointers :)

@Feniksss
Copy link

Feniksss commented Aug 19, 2020

Hi @gziolo. Do you have any news about this problem? Also some strange observation - I had this problem with WP 5.4.2 only (for WP 5.3 all works correct)

@gziolo
Copy link
Member

gziolo commented Aug 26, 2021

I have a proposal ready that should resolve this issue for blocks and filters that are registered before the editor screen is initialized. It should cover the majority of use cases. Related PR: #34299.

@gziolo gziolo self-assigned this Aug 26, 2021
@gziolo gziolo added the [Status] In Progress Tracking issues with work in progress label Aug 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks [Feature] Extensibility The ability to extend blocks or the editing experience [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants