-
Notifications
You must be signed in to change notification settings - Fork 14
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
Support for Reusable blocks #103
Comments
As a proof of concept, I think this is reasonably trivial, the below added here ContentBlocksResolver.php:56 and the reusable blocks seem to resolve as expected. I've not done extensive testing yet, but the GQL response looks good and replacing a few components in active pages seems to work as anticipated. Given it's just replacing the core/block with the content of the rendered reusable block(s), it should be good to go with something as trivial as this? Let me know if you'd like a PR and I'll wrap up some tests and get that added
|
@williamjulianvicary Thanks. Sure go ahead. We will review the code with the team. |
We do require a one time CLA for people adding contributions: If you could review and fill in this form: https://docs.google.com/forms/d/1O5bQCRHSSJmrOCAzWYJBIHjBNnVRg2PboSvuB2NfAI4/edit Then we will send you a DocuSign to complete. Then we can review your PRs. Thank you. |
That's complete - let me know if you have any questions |
Merged #104 |
I noticed that #54 was closed as resolved for the Classic Editor component of the issue but the reusable block item is still problematic.
I can see we can query like so:
This identifies the block type as reusable, and we're able to retrieve the ref attribute associated with the reusable block, however as far as I can tell it's not then possible to query for the reusable block directly. We're also using Faust, which means ideally we'll be wanting to pass down the complete response rather than having to resolve the appropriate block within the CoreBlock.
We can get the innerHtml but that doesn't allow us to then handle the attribute, and I see that blockJSON was removed with the release of wp-graphql-content-blocks which would have been the other option, possibly.
I guess ideally these blocks would be resolved to the underlying blocks (as flattened innerBlocks?) within the response, at which point they'd then be usable as if they were any other block.
This is a bit of a blocker for us using Faust long term for clients, the utility of reusable blocks is unsurpassed for repetitive content that needs to be centrally maintained and the alternative is either - produce static non-editable blocks or ask our clients to put up with copy + paste across all of their Gutenberg pages - neither a great option!
Is this on the roadmap?
The text was updated successfully, but these errors were encountered: