Add default attribute values on server side. #24909
Conversation
|
Size Change: +652 B (0%) Total Size: 1.17 MB
ℹ️ View Unchanged
|
Addison-Stavlo
changed the title
Addison-Stavlo
requested review from
spacedmonkey and
TimothyBJacobs
as code owners
Addison-Stavlo
requested review from
youknowriad,
noahtallen,
mcsf,
vindl,
Copons,
david-szabo97 and
jeyip
|
👋 The implementation looks totally correct, but I'm at a bit of a crossroads thinking about #24300 (comment). I'm curious on your thoughts. Also on my mind: how do we invert control so that block authors are the ones (trivially but explicitly) invoking the features they need for their blocks? By features I mean resolving attributes' default values, but also the actual rendering of specific transformations (e.g. injecting GS styles, classes into the serialised markup). |
|
Summarizing a slack conversation I had with @mcsf for visibility (please feel free to add more if I have missed any important points) - On one hand - we cannot support sourced attributes on the back-end, and don't currently have any good ideas of how to accomplish this. Adding this partial fix to apply defaults for these style hook attributes may send mixed signals, and add confusion regarding that these things magically work on the backend as well as they do on the client, when in actuality they do not as there are gaps and limitations. Since there is not a wide spread necessity for these defaults anyways, it may be more worthwhile to manage this in the block types themselves where they happen to be needed. On the other hand - This is a rather simple fix that allows default attribute values for style hooks to be supported for dynamic blocks. And while it may reinforce the confusion of what automatically works on the back end, that confusion may still exist regardless of this change. While there may not be many dynamic blocks that need default attribute support, not going with this change and applying these styles individually on the block type itself is part of what we were trying to avoid when adding the So what is the less bad? Potentially adding more confusion of what does and doesn't work on the back-end or requiring style applications done in |
|
Closing this as we favor rethinking how we handle supports on this side in general. |
Description
Alternative approach to #24300: Following up on the style support added for server side blocks in #23007 - I noticed these default values are already picked up by the corresponding hooks in the editor, but in the case of server side blocks are never applied on the front end.
This PR adds a function that can be used to apply default attribute values to a block array. This function is to be called before the attributes are used, and is currently called as a first step in
gutenberg_apply_block_supports.@mcsf / @youknowriad - We talked about running a function like this on the render_block filter higher up in the chain than where we apply the styles. But I am noticing that filter only filters the content string and not the block object itself. So it seems changes applied to the block object passed in that filter are not persistent to the next step in the filter (unless there is a way to do this I may be missing?).
So for now we are just calling this function as a first step in the apply_styles function to filter the block and apply the default values where necessary. Perhaps this generic function could be available for use by developers when default attributes need to be applied for dynamic blocks. 🤔
A few questions:
If we go with this approach:
if not:
How has this been tested?
There are not currently any server side blocks in Gutenberg that define defaults for these values. In my testing I have added default values (and their corresponding support flags if necessary) to current blocks (such as Post Author). After verifying all default value styles are applied as expected to the front-end, I added a test in class-block-supported-styles-test.php to make this easier to see.
To test this manually for a server side block, you can add default values (and their corresponding support flags) to its
block.jsonfile under attributes. (see below)For named default values you can add the following attributes (note - backgroundColor and gradient to be added and tested separately since they are both for the background):
For custom default values you can add the following to attributes (same note with background and gradient to be tested separately):
also, be sure the required flags are added under
supportsin block.json:Add the block to a post in the editor, save, and view it on the front-end. You should see the styles visually applied, and their corresponding classes and/or inline styles present on the wrapping element.
Screenshots
Before - A server side block with hook style support with default values defined but not applied:
After - Default values applied as expected:
Types of changes
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
(Kind of both of the above. It is a known 'bug' or shortcoming in the current implementation.)
Checklist: