Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses data fallback issues in three scenarios:
1. Single-item request errors
This scenario is set up using an Art Institute of Chicago block:
To mock a failed API request, we'll change the endpoint configuration to something invalid:
On
trunk
, the remote data block fails to load with this change:In this branch (
fix/missing-data-fallback
), we can fix the issue by using storedresult
data in the block's context. We return the result data from theget_value()
fallback, which fixes the issue:2. Single-item removed block
Using the same post as above, we'll instead remove the code that registers the block:
function load_only_if_parent_plugin_is_active() { /* ... */ require_once __DIR__ . '/airtable/elden-ring-map/register.php'; require_once __DIR__ . '/github/remote-data-blocks/register.php'; - require_once __DIR__ . '/rest-api/art-institute/register.php'; require_once __DIR__ . '/rest-api/zip-code/register.php'; require_once __DIR__ . '/shopify/register.php'; require_once __DIR__ . '/google-sheets/westeros-houses/register.php'; }
On
trunk
this fails to load as before. The fix used in scenario 1 doesn't work here, because the block is unregistered, which means nousesContext
is registered, and we no longer have access to parent context to fill data values from savedremote-data-blocks/remoteData
.The new code returns
null
instead of an empty string, which allows WordPress to ignore theget_value()
call and used the stored attribute value. This fixes rendering as above.3. Multiple-item request errors
For this scenario, we'll add a Westeros Houses List to the editor:
Next, we'll change the spreadsheet ID to something invalid:
This causes the front-end rendering to break in
trunk
:This is fixed in this PR using the same logic as the first scenario, using the embedded
result
data from context with an associated item index. The same post infix/missing-data-fallback
:Notes
There are currently two data fallback issues not covered by this PR:
Multiple-item removed block, e.g. removing the Westeros Houses List Block registration. We can't use the same strategy as scenario 2 (use saved attributes) because we only have one saved block, the template:
The rest of the items in the list only exist in the saved
results
header, and it's up to code to loop through these to generate the rest of the markup. We also can't use the fix from scenario 3 (use the embeddedresults
) because the block is unregistered and no longer has access to parent context.I think this may be fixable by detecting an unregistered
remote-data/
block and injecting the ability to useremote-data-blocks/remoteData
context. However I'd like to address that in a separate PR, as it'll probably be more complex.I noticed when testing scenario 2 with a Shopify block that content still doesn't load. It appears to be because we don't actually store any attributes on Shopify item markup and only provide it via context. For this item:
we have this markup in editor:
Note that the
<img>
,<p>
, and<h2>
tags are all empty and rely on context to fill values. I'm not sure why the Shopify block specifically is acting this way and not storing values in markup, but the fix may be similar to the prior issue where we need to pull context in unregistered blocks. I'll also look into this in another PR.Small update: It's also possible to recreate this behavior with other blocks by manually creating a pattern instead of selecting it. It seems like we're only injecting fallback attributes when a pattern is selected from automatic generation.