Fix: Issues on block level settings

[jorgefilipecosta]

What?

During the backport to the core I noticed some regressions on the block-level settings in Gutenberg:

• The property scope_selector was changed back to protected while it should be public.
• Some code references WP_Theme_JSON_6_1, which was meanwhile deleted.

Testing

I pasted the following code on the code editor, saved the post, and verified everything works well:

<!-- wp:group {"settings":{"blocks":{"core/button":{"color":{"palette":{"custom":[{"slug":"button-red","color":"red","name":"button red"},{"slug":"button-blue","color":"blue","name":"button blue"}]}}}},"color":{"palette":{"custom":[{"slug":"global-aquamarine","color":"aquamarine","name":"Global aquamarine"},{"slug":"global-pink","color":"pink","name":"Global Pink"}]}}}} -->
<div class="wp-block-group"><!-- wp:paragraph -->
<p>Leaf paragraph of inner group block.</p>
<!-- /wp:paragraph -->

<!-- wp:buttons -->
<div class="wp-block-buttons"><!-- wp:button {"backgroundColor":"button-blue"} -->
<div class="wp-block-button"><a class="wp-block-button__link has-button-blue-background-color has-background wp-element-button">blue</a></div>
<!-- /wp:button -->

<!-- wp:button {"backgroundColor":"button-red"} -->
<div class="wp-block-button"><a class="wp-block-button__link has-button-red-background-color has-background wp-element-button">red</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons -->

<!-- wp:paragraph {"backgroundColor":"global-aquamarine"} -->
<p class="has-global-aquamarine-background-color has-background">global-aquamarine</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph {"backgroundColor":"global-pink"} -->
<p class="has-global-pink-background-color has-background">global-pink</p>
<!-- /wp:paragraph --></div>
<!-- /wp:group -->

[Mamaduka]

I just noticed that we're making scope_selector a public API.

@oandregal, we had a similar discussion at #46571 (comment). Do you think this would be a valuable method for third parties, worth maintaining the BC?

[oandregal]

The class is still private, so this shouldn't be considered a public API. We have other methods that are also public in this class, though unnecessarily too many, in my view. In #45171 I list some that we need a public API for.

My concern in #46571 (comment) was that we were promoting or expecting third-parties to use it. If we expect anything to be used by 3rd parties, we need to create a proper public API outside this private class.

In this particular case, I don't know that we expect 3rd parties to use it. If that's the case, I'd support extracting it to its own method as a utility used by block supports and this class. If we don't expect anyone else to use it, I feel less pressure to extract it (though it'd still be a good thing).

Does that help clarify my rationale?

[Mamaduka]

It does help. Thank you, @oandregal!

[jorgefilipecosta]

Exactly the class is internal. This function is not helpful as hopefully, third-parties never deal with low-level selectors, but if it turns out to be useful, we can extract it in a function. This PR is just fixing a regression that caused a crash when the functionality was originally merged. The function was already public and inside an internal class.