PHP Render Callback Approach

In this lesson, we will delve deeper into the concept of block outputs and how they are saved. We will begin by discussing the issue that arises when we change the HTML structure for the save function or the attributes of our block type. As we have seen in the previous lessons, this causes a problem and we run into the "Attempt Block Recovery" message. We will explain why this happens and explore ways to modify our code to prevent this from occurring.

This error message occurs because WordPress needs to trust the saved text to extract values from it using source and selector properties. If the HTML structure of the save function changes, the selector may not select the same value, and hence, the trust is broken.

Now imagine, if we used a block in ten different templates or in hundreds of blog posts and we needed to make a change in the save component. This would entail manually updating each and every template and blog post to remove the "Attempt Block Recovery" error.

We can work around this problem by allowing WordPress to figure things out on its own by changing the HTML structure. We will demonstrate how this can be achieved in our code.

Deprecated property

To provide WordPress with a history of how to make changes, we can add a new top-level property called deprecated to our code.

There are several ways to go about it. We can simply create a deprecated property when registering the block type in index.js. Or we can create a separate file called deprecated.js and import it in index.js.

The deprecated property should be an array of objects, with each object containing the attributes and saved values from the previous version of our code. The objects in the deprecated array can have the following properties:

• attributes

• supports

• save

• migrate

• isEligible

We can then make changes to the save function, while still having a backup of the previous version in the deprecated property.

To add an object to the deprecated array, simply copy the entire save function and its value, along with the attributes property from block.json, and paste them into the new object. We can then make changes to the save function as needed.

This process is repeated for any new versions of our code, by adding another object to the deprecated array containing the attributes and save method. This allows us to make changes to the HTML structure without causing errors or losing our previous versions.

As best practice, it is recommended to add new objects to the deprecated array at the beginning. The parsing of the array starts from the first element and stops when a matching version is found. Therefore, putting the most recent deprecation first increases the chances of finding a match early on. This approach avoids the unnecessary processing of older deprecations that are less likely to match, as the most recent deprecation is usually the most relevant one.

Drawback

With the deprecated property in place, WordPress won’t ask us to click the "Attempt Block Recovery" button and it could actually just use the new code. But this approach has a drawback. Simply creating a new version of our JavaScript file does not update our content. It still requires manually clicking into all the templates and posts that use the block and updating the post or template. This can become a significant problem in real-world scenarios where a block is used in hundreds of posts. The save function in our JavaScript block just returns a string of text which is stored in the WordPress database.