Open ramonjd opened 3 months ago
Also, should we consider only saving relative paths to the database? This applies to fonts as well:
I'm not sure what the best solution is given we've put ourselves into a corner re. backwards compatibility 😅
Actually supporting relative paths seems problematic since it implies that ..
would work which it doesn't, and I'm not sure that we ever should support ..
since we don't want to allow accessing files outside of the theme directory.
So I suppose best to either keep things as they are and document it, or change the prefix to be file:
or file:/
instead of file:./
.
I'm not sure what the best solution is given we've put ourselves into a corner re. backwards compatibility Actually supporting relative paths seems problematic since it implies that .. would work which it doesn't, and I'm not sure that we ever should support .. since we don't want to allow accessing files outside of the theme directory.
Thanks for the feedback! I agree 💯
I think I'd therefore support point 1 in the description ("Communicate that all paths, regardless of the depth, must be relative to the theme root, and perhaps also support "file:" (without dotslash to avoid confusion) by default and have backwards compat handling for "file:./"")
- Communicate that all paths, regardless of the depth, must be relative to the theme root, and perhaps also support "file:" (without dotslash to avoid confusion) by default and have backwards compat handling for "file:./"
I agree that option one seems like the best path here, at least for now. Any changes to support a new/different file syntax and maintain backcompat seem likely to add a lot of complexity, so I don't think there's enough benefit to warrant the added complexity at this time.
What problem does this address?
A convention was introduced as part of the web fonts feature, with regards to relative paths to theme assets in theme.json.
The convention is that a prefix of
file:./
is required to indicate that a path is relative to the theme root directory.For example, the following path —
— assumes that
/assets/
is top-level directory of the theme.This rule also applies to style variations, so theme.json files in the
/styles
folder.This convention was followed for background image URIs.
See the discussions in:
What is your proposed solution?
As @noisysocks points out:
I would propose either:
"file:"
(without dotslash to avoid confusion) by default and have backwards compat handling for"file:./"
As @creativecoder notes, we should update the docs to reflect the current behaviour:
https://developer.wordpress.org/themes/global-settings-and-styles/settings/typography/#registering-web-fonts-font-faces
For example: