Store legacy sidebars when switching to a block theme

[Mamaduka]

Why

Recently Block Editor introduced a feature to import widgets into template parts. This pathway allows migration to a block theme without losing the widgets.

Storing legacy sidebars provides a better user experience when using this feature.

How

• If a user is switching to a block theme. Previously registered sidebars are stored in the wp_legacy_sidebars theme mod.
• Later, this data is used to register legacy sidebars for a block theme without enabling Widgets support. The sidebars are only available via REST API and are marked as inactive.
• The legacy sidebar registration is required to avoid remapping "orphaned" widgets to the wp_inactive_widgets sidebar.

For more details, see the corresponding Gutenberg PR - ​https://github.com/WordPress/gutenberg/pull/45509.

Trac ticket: https://core.trac.wordpress.org/ticket/57531
Related Gutenberg PR: ​https://github.com/WordPress/gutenberg/pull/45509

## Testing instructions without package updates

1. Switch to the Twenty Twenty theme.
2. Confirm sidebars have at least one widget by going to Appearance > Widgets
3. Switch to any block theme. I was using Twenty Twenty-Three in my tests.
4. Make a get request to the sidebars endpoint. It requires auth, but the Application Password could be used for basic auth.
5. Confirm that the request loads the same sidebars registered for the Twenty Twenty theme.

Example request made by the editor.

{{{http
GET /wp-json/wp/v2/sidebars?context=edit&_fields=id,name,description,status,widgets
}}}

@hellofromtonya, I'm unsure what would be the right place to add PHPUnit tests for this change or the actual "unit" we want to test. In the plugin, the feature is covered by e2e tests.

Thank you, @audrasjb!

Do you have any suggestions about the PHPUnit tests - ​https://github.com/WordPress/wordpress-develop/pull/3893#issuecomment-1400432537?

Concerning unit tests, maybe try to verify that classic sidebars are stored when switching to a block theme?

That makes sense, thank you.

I like the "classic sidebars" term and reference our other discussions from ​https://github.com/WordPress/wordpress-develop/pull/3902#discussion_r1085740716. Do you think I should change legacy_sidebars to classic_sidebars?

That makes sense, thank you.

I like the "classic sidebars" term and reference our other discussions from ​https://github.com/WordPress/wordpress-develop/pull/3902#discussion_r1085740716. Do you think I should change legacy_sidebars to classic_sidebars?

Yeah definitely! I think it would be easier to identify what is it: the system used before blocks started to handle WordPress content dataset :)

Yes it is legacy, but "legacy" can also be used for "legacy Classic" functions/classes/methods/concepts (= legacy-legacy stuff 🤪 ). Let's disambiguate when possible! :D

• Fixed docblock.
• Updated the theme mod name.
• Added simple unit tests.

[hellofromTonya]

Marking the experimental keyword for tracking of backport/sync Gutenberg into Core tickets.

[hellofromTonya]

Patch ​PR 3893

Testing instructions without package updates:

• Switch to the Twenty Twenty theme.
• Confirm sidebars have at least one widget by going to Appearance > Widgets
• Switch to any block theme. I was using Twenty Twenty-Three in my tests.
• Make a get request to the sidebars endpoint. It requires auth, but the Application * Password could be used for basic auth.
• Confirm that the request loads the same sidebars registered for the Twenty Twenty theme.

I like the "classic sidebars" term and reference our other discussions from ​https://github.com/WordPress/wordpress-develop/pull/3902#discussion_r1085740716. Do you think I should change legacy_sidebars to classic_sidebars?

I agree with @audrasjb that "classic" is preferred over "legacy" 👍

@Mamaduka I'll look at the PHPUnit. Thank you for adding it!

Test Reports: I asked @ironprogrammer to do his magic in testing this PR. If anyone has time, please test and add a test report too.

[ironprogrammer]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/3893 👍🏻

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 12.6.2
• Browser: Safari 16.2, Postman 10.9.1
• Server: nginx/1.23.3
• PHP: 7.4.33
• WordPress: 6.2-alpha-54642-src
• Theme: twentytwenty v2.1, twentytwentythree v1.0, twentytwentytwo v1.3

Actual Results

• ✅ With block theme enabled, API request to /wp-json/wp/v2/sidebars?context=edit&_fields=id,name,description,status,widgets includes previously registered classic theme widgets, with status inactive.

Additional Notes

• API tests conducted with Postman, using Cookie and X-WP-Nonce headers scraped from XHR requests logged in as admin.

Supplemental Artifacts

Twenty Twenty Theme: API request before patch -- sidebar-1 and sidebar-2 are active:

[
    {
        "id": "wp_inactive_widgets",
        "name": "Inactive widgets",
        "description": "",
        "status": "inactive",
        "widgets": []
    },
    {
        "id": "sidebar-1",
        "name": "Footer #1",
        "description": "Widgets in this area will be displayed in the first column in the footer.",
        "status": "active",
        "widgets": [
            "block-2",
            "block-3",
            "block-4",
            "block-5",
            "block-6"
        ]
    },
    {
        "id": "sidebar-2",
        "name": "Footer #2",
        "description": "Widgets in this area will be displayed in the second column in the footer.",
        "status": "active",
        "widgets": []
    }
]

Twenty Twenty-Three Theme: API request before patch -- sidebar-1 and sidebar-2 are missing:

[
    {
        "id": "wp_inactive_widgets",
        "name": "Inactive widgets",
        "description": "",
        "status": "inactive",
        "widgets": []
    }
]

Twenty Twenty-Three Theme: API request AFTER patch -- sidebar-1 and sidebar-2 are returned and inactive ✅:

[
    {
        "id": "wp_inactive_widgets",
        "name": "Inactive widgets",
        "description": "",
        "status": "inactive",
        "widgets": []
    },
    {
        "id": "sidebar-1",
        "name": "Footer #1",
        "description": "Widgets in this area will be displayed in the first column in the footer.",
        "status": "inactive",
        "widgets": [
            "block-2",
            "block-3",
            "block-4",
            "block-5",
            "block-6"
        ]
    },
    {
        "id": "sidebar-2",
        "name": "Footer #2",
        "description": "Widgets in this area will be displayed in the second column in the footer.",
        "status": "inactive",
        "widgets": []
    }
]

@ironprogrammer tested the PR and submitted a Test Report https://core.trac.wordpress.org/ticket/57531#comment:13. Works 👍

[hellofromTonya]

Self-assigning for commit review.

Currently reviewing for commit.

@Mamaduka I switched the way this PR is tested by:

• Adding a new test class for the new function _wp_block_theme_register_classic_sidebars().
• Testing the "inactive" state in the REST API.

By doing so, it's now testing different paths for this specific change including:

• Does the sidebar register on theme switch after invoking _wp_block_theme_register_classic_sidebars()?
• Does the REST Controller set the sidebar to inactive?
• Does the switch_theme() set the theme mod?

[hellofromTonya]

• Confirmed this PR includes the changes from the GB PR ✅
• It has a test report ✅
• It has unit/integration tests ✅

It's ready for commit (assuming the CI jobs pass this time 🤣 ) 👍

[hellofromTonya]

In 55200:

Widgets: Preserve classic sidebars when switching to a block theme.

When switching to a block theme, classic sidebars were orphaned and their widgets remapping to the 'wp_inactive_widgets' sidebar . This changeset preserves the sidebars and their widgets, providing a migration path to a block theme without losing the widgets.

Classic sidebars are now:

• Stored in a new theme mod called 'wp_classic_sidebars';
• Restored to the $wp_registered_sidebars global variable when the 'widgets_init' action fires (via a new internal function called _wp_block_theme_register_classic_sidebars());
• And marked as 'inactive' when interacting with sidebars REST API endpoint.

References:

• ​Gutenberg PR 45509 which adds an option for importing widgets from sidebars into template parts.

Follow-up to [50995], [6334].

Props mamaduka, audrasjb, hellofromTonya, ironprogrammer, jameskoster, joen, matveb, mukesh27, noisysocks, poena, youknowriad.
Fixes #57531.

Committed via https://core.trac.wordpress.org/changeset/55200.