Automattic / vip-block-data-api

WordPress plugin that provides an API to retrieve Gutenberg content as structured JSON.
http://wpvip.com
GNU General Public License v3.0
97 stars 7 forks source link

Default and client-side registered attributes (e.g., "anchor") not available in server-side context #68

Closed Zamfi99 closed 2 weeks ago

Zamfi99 commented 1 month ago

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

Expected 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.

smithjw1 commented 1 month 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:

  1. Registering via block.json is the preferred method from Core.
  2. Tapping into the editor front-end is not ideal for end users.
  3. The additional maintenance cost of integration with maintaining a non-supported integration with the post editor.

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.

alecgeatches commented 2 weeks ago

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!