Site Export: ensure that the export endpoint uses Gutenberg theme classes

[ramonjd]

What?

Extending the WP_REST_Edit_Site_Export_Controller endpoint to use Gutenberg theme methods.

[!NOTE] This PR doesn't require backporting - the code is taken from existing Core methods/functions from 6.0/5.9. The references to Core classes and functions have been changed to _Gutenberg/gutenberg_ only.

Why?

Like it says in the title, ensure that the export endpoint uses Gutenberg theme classes.

It makes sure that theme exports get the benefit of the latest changes to theme json and resolver.

For example, style.background is a new theme.json style property, but it won't be exported by the Core endpoint until version 6.6.

This endpoint hasn't had any backwards compat extensions in Gutenberg for the last few releases and probably further back so it's probably worth doing.

How?

Copying over the public methods and swapping WP functions/methods with Gutenberg ones 😄

The changes live in the /lib folder because none of the changes are backwards compat specific. Props to @andrewserong for pointing this out 😄

Having this extension permanently in Gutenberg means that theme.json exporting will always use the latest version of the Theme JSON family of classes.

Testing Instructions

Add a background image to a site in the site editor.

Save the site

Export your theme

Check the exported theme.json - your background styles should be featured in style.background.

Example snippet from my exported theme.json:

	"styles": {
		"background": {
			"backgroundImage": {
				"id": 26,
				"source": "file",
				"title": "pizza1",
				"url": "http://localhost:8888/wp-content/uploads/2024/05/pizza1.jpg"
			}
		},
		"color": {
			"text": "#333"
		}
	},

[github-actions[bot]]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ramonjd <[email protected]>
Co-authored-by: andrewserong <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions[bot]]

Flaky tests detected in ccd2ac40454a365c36ae7a15777973d6441d02c1. Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9199960175 📝 Reported issues:

• #61806 in /test/e2e/specs/site-editor/zoom-out.spec.js

[ramonjd]

Example snippet from my exported theme.json:

Gutenberg preserves the id/source/title props added by block upload.

				"id": 26,
				"source": "file",
				"title": "pizza1",

I guess they should be reflected in theme.json at some point.

[ramonjd]

One thought while looking at the code change — is there anything about this change that's particular to 6.6 or requires backporting? If not, would it be better to include these changes in either /lib or /lib/experimental to both flag that no backporting is required, and so that the GB versions are still present for subsequent releases? Otherwise, we might wind up needing to re-add the files further down the track when the 6.6 compat directory is eventually removed

Oh yeah, that's a very good point 😄

I think I was hypnotized by the fact that background images in theme.json is a 6.6 feature, but you're right, this will be an ongoing concern so it should be maybe in lib, next to global styles controller? What do you reckon?

[andrewserong]

so it should be maybe in lib, next to global styles controller

Yep, that sounds good to me. I'd lean toward lib if it's identical to wordpress-develop except for calling GB versions of things, and lib/experimental if it's making changes that aren't present in core.

[ramonjd]

Yep, that sounds good to me. I'd lean toward lib if it's identical to wordpress-develop except for calling GB versions of things, and lib/experimental if it's making changes that aren't present in core.

Done!

[github-actions[bot]]

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! :heart:

View changed files

:grey_question: lib/block-template-utils.php
:grey_question: lib/class-wp-rest-edit-site-export-controller-gutenberg.php
:grey_question: lib/load.php
:grey_question: lib/rest-api.php

[ramonjd]

I appreciate the thorough review @andrewserong

This is a good one to get in 👍🏻

[ellatrix]

Should this be backported for WP 6.6? If so, please add the Backport to WP Beta/RC label. Thanks!

[ramonjd]

Should this be backported for WP 6.6? If so, please add the Backport to WP Beta/RC label. Thanks!

This one is just Gutenberg - it's got the label "No Core Sync Required" 👍🏻