You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When editing a page in the WordPress block editor, any block with a "block recovery" status (e.g., due to changes in its save method) will be removed upon saving the page if the Yoast SEO plugin is active. This issue occurs when the block is used as an inner block inside another block (e.g., core/group). Instead of preserving the block, Yoast's getBlocks function inadvertently causes its removal.
Steps to Reproduce:
Install and activate the Yoast SEO plugin.
Create a custom block and make changes to its save method to trigger a "block recovery" state.
Add the custom block as an inner block inside a parent block (e.g., core/group).
Save the page.
Expected Behavior:
The block editor should save all blocks, including those in a "block recovery" state. The Yoast SEO plugin should only collect data for analysis and should not modify or remove blocks.
Actual Behavior:
Any block with a "block recovery" state is removed from the content during the save process.
Potential Cause:
The issue appears to stem from the getBlocks function in Yoast SEO's collectAnalysisData.js. The function likely processes blocks in a destructive manner, removing blocks that are in a recovery state instead of collecting their data non-invasively.
Environment:
Yoast SEO Version: 23.3+
Suggested Solution:
The getBlocks function should be updated to operate in a non-destructive manner. Specifically, it should only collect analysis data from blocks and leave their structure intact. Blocks in a recovery state must not be removed during the save process.
Additional Notes:
This issue affects blocks with "block recovery" status nested inside other blocks, such as a core/group block. The removal of these blocks can lead to significant data loss and disruption in workflows.
The text was updated successfully, but these errors were encountered:
Thank you for creating the issue and using the Yoast SEO plugin. Could you please share a video or screencast demonstrating the issue?
Additionally, could you provide more details about why the "block recovery" message appears in the editor? Does another block plugin cause it, or could it be related to an incorrect method used to trigger it?
We look forward to hearing from you and are happy to help you.
When editing a page in the WordPress block editor, any block with a "block recovery" status (e.g., due to changes in its
save
method) will be removed upon saving the page if the Yoast SEO plugin is active. This issue occurs when the block is used as an inner block inside another block (e.g.,core/group
). Instead of preserving the block, Yoast's getBlocks function inadvertently causes its removal.Steps to Reproduce:
save
method to trigger a "block recovery" state.core/group
).Expected Behavior:
The block editor should save all blocks, including those in a "block recovery" state. The Yoast SEO plugin should only collect data for analysis and should not modify or remove blocks.
Actual Behavior:
Any block with a "block recovery" state is removed from the content during the save process.
Potential Cause:
The issue appears to stem from the
getBlocks
function in Yoast SEO's collectAnalysisData.js. The function likely processes blocks in a destructive manner, removing blocks that are in a recovery state instead of collecting their data non-invasively.Environment:
Yoast SEO Version: 23.3+
Suggested Solution:
The getBlocks function should be updated to operate in a non-destructive manner. Specifically, it should only collect analysis data from blocks and leave their structure intact. Blocks in a recovery state must not be removed during the save process.
Additional Notes:
This issue affects blocks with "block recovery" status nested inside other blocks, such as a
core/group block
. The removal of these blocks can lead to significant data loss and disruption in workflows.The text was updated successfully, but these errors were encountered: