Closed Zamfi99 closed 2 weeks ago
@Zamfi99, thanks for submitting this bug report. There are two separate issues here, one for default attributes, and one for custom attributes registered on the front end.
I've created issue #69 to track work on default attributes.
I've marked this issue as wont fix
because we know the limitation on client-side registered attributes. We agree that your suggested solution would be the best approach. It is the one the WP GraphQL Gutenberg takes.
We have decided not to extend the plugin into the editor to capture client-side registered attributes for three reasons:
We realize this limits the usefulness of the plugin for block attributes registered on the front end, but that is a trade-off we have decided to make.
Closing this issue in favor of #69. Please see this comment https://github.com/Automattic/vip-block-data-api/issues/69#issuecomment-2263535285 for an anchor
attribute workaround. Thank you!
Describe the bug Currently, there is a significant issue with default and client-side registered attributes, such as the
anchor
attribute, which are registered on the frontend and not in the backend. As a result, these attributes are not available in the server-side context, causing them to be missing in the API response. This discrepancy can lead to functionality problems and inconsistencies when handling blocks, particularly those relying on default attributes for proper rendering and behavior.To Reproduce
anchor
anchor
attribute and other client-side registered attributes (if applicable) are missing in the API responseExpected behavior Default attributes, such as
anchor
, along with client-side registered attributes on the frontend, should be consistently included in the API response.Actual behavior Specific default attributes, such as
anchor
, as well as client-side registered attributes on the frontend, are currently missing from the API response.Proposed solution To address this issue, I propose the creation of a custom block type registry that can be dynamically updated from within the Gutenberg editor on the frontend. While not the most ideal solution, it appears to be the most feasible approach. This registry will ensure that both default and custom attributes registered on the frontend are also available in the backend, thereby providing a consistent and reliable API response.