Prevent fatals with the Howto block in rare situations

[Djennez]

Context

• Prevent fatal errors on PHP 8+ when trying to use arithmetic operations on strings.

Summary

This PR can be summarized in the following changelog entry:

• Prevents a fatal error in an uncommon case where the duration of a how-to block contains non-numeric values.

Relevant technical choices:

• We only prevent storing strings as duration in javascript in the block editor. However, a string may still be stored via other means (we should probably prevent that as well). When PHP tries to perform arithmetic operations on strings, it will start throwing fatals as of PHP 8. This PR checks if the value can be numeric and if so, casts it to an integer. All other cases will return a 0.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

We need request manipulation to test this PR. Manipulation is needed as the "normal" editing of the post does not allow for these values to be submitted. Firefox allows for this request manipulation out of the box, so these instructions use the Firefox browser.

• Make sure you are running PHP 8+ (PHP 7 will throw warnings instead of errors I believe)
• Add a How-to block to a post and fill it out with all the details, including a valid duration.
• Click the button to update the post while you have your network inspector open.
• Rightclick the POST request to https://basic.wordpress.test/wp-json/wp/v2/posts/###?_locale=user and click Edit and resend.
• In the additional window, look for the body of the request and scroll to the first instance of \"hours\":\"1\" (where the 1 is the value you filled for the hours in the howto block.
• Change this 1 to a letter and click 'send'.
• Without this PR, the editor and the page on the frontend of the site should both throw a fatal error.
• With this PR, the duration will simply be cast to 0.

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

QA can test this PR by following these steps:

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

• The How-To block.

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Other environments

• This PR also affects Shopify. I have added a changelog entry starting with [shopify-seo], added test instructions for Shopify and attached the Shopify label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

Quality assurance

• I have tested this code to the best of my abilities.
• During testing, I had activated all plugins that Yoast SEO provides integrations for.
• I have added unit tests to verify the code works as intended.
• If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.
• I have written this PR in accordance with my team's definition of done.
• I have checked that the base branch is correctly set.

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label.
• I have added my hours to the WBSO document.

Fixes #

[coveralls]

Pull Request Test Coverage Report for Build f3a3c7d2e2653104caf8797325ca493d5cf0c89b

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
• 28 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-6.3%) to 45.948%

---

Files with Coverage Reduction	New Missed Lines	%
admin/class-admin-asset-manager.php	1	34.35%
admin/class-customizer.php	11	0.0%
src/integrations/blocks/structured-data-blocks.php	16	38.46%

Totals
Change from base Build 447fe11c916acaec5a7487fc47708a8eecc5e1ed:	-6.3%
Covered Lines:	15342
Relevant Lines:	34721

---

💛 - Coveralls

[igorschoester]

CR 🏗️