-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Background image: add support for relative theme path URLs in top-level theme.json styles #61271
Background image: add support for relative theme path URLs in top-level theme.json styles #61271
Conversation
Size Change: +723 B (+0.04%) Total Size: 1.74 MB
ℹ️ View Unchanged
|
8840474
to
5edf884
Compare
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah, nice spotting. It won't "reset" to nothing as it it's theme.json defined. But if you set a user-defined image it should "reset" back to the theme.json-defined on. But the fact you can click reset at all doesn't sound right, I'll look into it. Thanks!! |
Handling this in a bug fix PR. Thanks again for reporting it. |
Flaky tests detected in 92a5fe8. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9143693322
|
b641060
to
9285a43
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is testing pretty well for me at the root theme.json
level. One subtle thing I noticed in the UI is that it doesn't expose the size controls by default when the theme.json
sets an image. Should it, do you think?
I'm also wondering (not for this PR) if now that we're supporting a theme setting a background image, if we should have none
as an available option, perhaps in the dropdown where Reset
and Open Media Library
live, so that folks could explicitly remove a background image if a theme sets one?
In terms of code, resolving the theme uris before the site editor loads is a clever way to ensure we don't need to worry about requesting the URL via the site editor. A couple of questions:
- I wasn't able to get a theme style variation to work by giving it its own different background image. Should that be possible at this stage? I could very possibly be making a mistake in my local testing environment.
- What happens in the database if we go to save changes, or apply a variation? Does the resolved version of the URL get saved instead of the theme relative one? If so, I wonder if there's a way to preserve the reference to the theme URL instead of "baking" in the URL in the user global styles data 🤔
Thanks for testing and the great questions @andrewserong
Very doable, and it should, I agree. It should be a one liner. I'll add it in another PR 👍🏻
Oh, yeah good idea. That sounds like a useful thing to have. I'll add a follow up task to the tracking issue
Variations aren't supported currently in this PR only the
I'll check, but I'm going to guess "yes", the resolved path is saved. Just thinking out loud... the path resolution in that case should happen when building styles, not merging theme.json data. It's therefore likely we'd need need some of the core data selectors created in #60578 because styles are built in the block editor via javascript from theme.json tree, and we'd need a way to tell if the file belongs to the child/parent theme. As for the frontend, we could just build the path resolution into |
92a5fe8
to
5d3ba0b
Compare
Added an issue for this: |
|
…el theme.json styles (WordPress#61271) * This initial commit: - removes requirement for a `source` property in theme.json as the assumption is that, for now, all paths are paths to image files, whether absolute or relative - checks for existence of "host" in URL and then tries to resolve background image url using get_theme_file_uri - Adds a new public method WP_Theme_JSON_Gutenberg::resolve_theme_file_uris to allow theme devs to optionally resolve relative paths in theme.json to a theme. * For testing purposes, resolve in get_merged_data - should it be optional? That is, done in the global themes controller and wherever a stylesheet is generated? * Rollback test of imperative method in resolver * Moves resolution of file paths back to theme_json resolver * Backend resolution of theme file URIs for global styles. * Working on revisions Backend resolution of theme file URIs for global styles revisions Ensuring links are preserved when updating global styles. * So my linter is working again * Changed the relative link to `wp:theme-file-uris` Always adding path to the link object so that it can dynamically resolved. * Added some explanatory TODOs * Adding valid link attributes to the _link object. Updated tests * Added some unit tests for utils * Switching to using file: prefix, which is an established theme.json convention for relative paths to theme assets. E.g., web fonts Adding test image to empty theme Added theme JSON schema update Unit tests for JS helper Using response methods to add links to response collection * Fix linting * Remove TODO * Update tests * dump var_dump * Check for $theme_json before resolving * be explicit about the background value file:./ * Remove unnecessary empty check * Abstracting getting any resolved URI to separate hook Updating comments * Update lib/class-wp-theme-json-resolver-gutenberg.php * Update lib/class-wp-theme-json-resolver-gutenberg.php * Revert useGlobalStyle changes - no longer required given the new hook * Bad revert * Rename wp:theme-file-uris to wp:theme-file Rename utils file --------- Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: andrewserong <andrewserong@git.wordpress.org> Co-authored-by: noisysocks <noisysocks@git.wordpress.org> Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org> Co-authored-by: oandregal <oandregal@git.wordpress.org> Co-authored-by: TimothyBJacobs <timothyblynjacobs@git.wordpress.org> Co-authored-by: creativecoder <grantmkin@git.wordpress.org>
Due to the addition of the Please see #63495. |
Good catch! I'll comment over on #63495. |
Dev Note 📓
#59354 (comment)
What?
This PR resolves relative paths in top-level
background.backgroundImage.url
values in theme.json and theme variation JSON files using get_theme_file_uri.Part of:
Based on explorations in:
Related trac ticket:
Note
This PR doesn't enable theme relative path resolution for blocks in templates/patterns. That'll be a follow up.
Why?
To ensure that themes with background image values in theme.json are portable — a theme developer can set a relative path to an image asset as a background image value, and that path will resolve correctly to absolute path of the file in the theme directory no matter where the theme is installed.
Contrast this with absolute image paths: every installation of the theme would point to single image files sitting somewhere on the internet.
How?
Paths to images residing in the theme directory can be set in theme.son using the
file:
syntax, a convention already used in Core for web fonts.The path is relative to the theme root. For example:
For the frontend:
Relative paths will be resolved when building the global styles sheet in
gutenberg_get_global_stylesheet()
.A new public method
WP_Theme_JSON_Resolver_Gutenberg::resolve_theme_file_uris
accepts aWP_Theme_JSON_Gutenberg
object and will resolves anyfile:
paths it finds using get_theme_file_uri.For the editor:
Global styles are built using merged theme, core and user theme.json configs in the block editor. All this is done using Javascript.
So that the editor has access to the resolved paths before building editor global styles, Gutenberg resolves the file paths in the backend and passes them to the browser via the
_links
objects in global styles controller REST responses (Global styles and Global styles revisions controllers).Global styles are built using the
useGlobalStylesOutputWithConfig
hook. This PR adds a mutating function to that hook that replaces the relative paths with their absolute equivalents using the data in the_links
object.This approach ensures that the values are used only when building and outputting styles, and not when saving or manipulating the global styles config, thereby preventing any resolved, absolute paths from being stored in the database.
Testing Instructions
Note
Background images won't appear in the theme.json when exporting themes from the site editor until this PR is merged #61561
Test by adding an image or two to your theme directory.
Also add a variation of this theme.json as a style variation (under
/styles
in the theme directory) with a different image.Check for regressions: absolute paths should still work as expected as well:
Run tests:
Screenshots
Do you love budgies?!