21141 decouple hidden fields for metabox

[vraja-pro]

Context

• Decouple metabox hidden fields from block editor. We want to use the block editor without the metabox, but the metadata and block editor are both updated through the hidden fields which are part of the metabox. Also the values in those hidden fields are the source of truth and we want to make the yoast editor store to be the source of truth. We want to clean side effects from the redux actions to update the hidden fields and instead use a sync method. When we are using only the block editor, we want to sync the metadata to the core/editor store for update. This is the first step in decoupling the metabox from the block editor and part of the investigation done in PoC for decoupling metabox and sidebar

Summary

This PR can be summarized in the following changelog entry:

• Decouples hidden fields from metabox and blockeditor.

Relevant technical choices:

• We have to expose our metadata in rest api in order to update it through the core/editor store.
• I removed src/integrations/third-party/wordproof.php and moved the code to src/initializers/wordproof-metadata.php because the hook for adding extra fields needs to be used in an initialiser in order to register the metadata. We need to register the metadata to have it available in the core/editor store.
• I removed the translation for wordproof in the metabox translations method because adding a translation also adds the fields to the hidden fields without any check. The wordproof-metadata class also adds those translations.
• I had to use get_options in the conditional src/conditionals/third-party/wordproof-integration-active-conditional.php because WPSEO option class does not work in the initialiser.
• I have removed the default value property name for schema_page_type in inc/class-wpseo-meta.php line 422 , all other metadata defs are using default_value and the property is used in when getting the value.
• I have removed the adding of defaults of schema metadata from the fields defs, since it is not used as default in the value itself but is used in the front end. I added the defaults to admin/formatter/class-post-metabox-formatter.php metabox window object and then used it in the store for initial state of the default values. That is used then in the dropdown list of schema types.
• I have remove the values from the presenters in the render_hidden_fields methods because the sync will populate those fields on load. We want one source of truth for the metadata, so now those methods only render hidden fields without value.
• I changed the way we import createWatcher for cleaner and safer import and for testing proposes.
• I added createCollectorFromObject to helpers in editor-modules to be used in syncs in add-ons.
• I removed onLoad actions since we are now using the initial state when registering the store to load the values.
• I removed the classes for estimated reading time because it is was not adding the hidden fields in a way that registers it,When using add_extra_wpseo_meta_fields that needs to be done in an initializer class to actually register the meta, which was not the case here. I added it to the meta key in the meta class fields and removed it's classes since we are checking there if it's a post. This check is not done for other fields that are for posts only and there is no problem with that. Also when adding the translations in translate_meta_boxes it adds those fields without any check, so even though we are checking if it's a post, we are adding the fields anyway through the translations .
• Since we need the meta data to be visible in rest api, we also need to make sure it is not visible for those who don't have the edit_posts capabilities. That is why I added the context props in show_in_rest schema property.
• I created get_show_in_rest_args because we don't want to set show_in_rest to true when we the fields is a non-form one.
• The schema defaults were also coupled with the hidden fields when it's not even metadata but part of the options. I moved the logic to the post metabox formatter and added it to the window object.
• I removed yoast_wpseo_metadesc from the elementTarget list because it's an id of a hidden field for elements that their change should refresh the analysis. I trigger the refresh in the subscribe method below. That is why I changed the name of refreshAfterFocusKeywordChange to refreshApp because I'm using it also for the description.
• I added a few more checks in the santize post meta callback function:
  • Since we are checking if linkdex score is an integer in the sanitization callback function, I added also the content score and inclusive language score.
  • With this PR, estimate reading time is now being sanitized, I added a check for integer value
  • Same for primary taxonomy, only I added a check for integer greater then 0.
  • Same rule applies for social appearance images ids.
• Added Metadata_Groups class to have the logic of the visibility of the metadata fields groups in one place, since it is used both in the metabox classes and the formatters
• The metadata values should be rendered in the hidden fields and not synced in order not to trigger unsaved changes.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

Test instructions and code review divided to issues:

• Decouple Social appearance fields hidden fields #21220
• Decouple Advanced settings fields #21221
• Decouple analysis hidden fields #21222
• Decouple primary term hidden fields #21223
• Decouple Schema hidden fields #21224
• Decouple Google preview hidden fields #21225
• Decouple estimate reading time hidden field #21226

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:

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 Decouple hidden fields for metabox

[igorschoester]

CR 🏗️

Why are you not removing the side-effects in the actions?
If you are creating a sync that listens to the store and sets the inputs. The actions can be freed of that responsibility?

Did you investigate using a REST route instead of the script data for retrieving the initial values?

[igorschoester]

CR 🏗️

[vraja-pro]

Meta property is not present in the core and core/editor store when editing a custom post type with block editor. Seems like a bug in WordPress

[igorschoester]

AT 🥳