Provide a Mandatory Blank Theme and Stop Faking the Theme
Opened this issue · 9 comments
Preface:
Oxygen "disables" the active theme by manipulating the theme name to "oxygen-is-not-a-theme", and changing the template and stylesheet paths to "fake". This worked in the past with the older, simpler themes.
Since WordPress introduced Full Site Editing themes, there are many more steps involved in theme initialization, like the theme.json, the blocks configurations, and many more.
This causes issues with the default themes like "Twenty Twenty-Two", "... -Three", "...-Four", and the recommendation is to activate an older or a blank theme.
One example that comes to my mind is theme "Twenty Twenty-Four" that tries to load font "Inter", included in the theme's assets folder, via theme.json. Since the theme name and path is invalidated by Oxygen, the access to the font causes a 404 error in frontend.
The last WordPress update to 6.5.2 is now causing even more issues, especially with custom Gutenberg Blocks that utilize features like script, editorScript, style, editorStyle, ... See ticket #3525
It's pretty foreseeable that future WordPress, Theme, and Gutenberg updates will cause even more unexpected issues.
Dozens of issues reported in the Facebook group are caused by Oxygen's theme faking in conjunction with FSE themes and the newer Gutenberg Block features.
Request:
Instead of trying to disable a theme's influences, and trying to keep up with changes in recent WordPress versions,
- Provide a mandatory blank theme, with minimal to no functionality.
- Remove all those attempts to disable/fake the theme.
Advantages & Benefits:
- All the issues with the faked/disabled theme are history.
- No more guessing if a user's issue might be caused by Oxygen's theme faking and the use of FSE themes: All users have the same theme
- Plugins that require a working theme would be satisfied
Example from my head: Ultimate Member stores mail templates in the theme's folder. Not the best approach, but that's how they implemented it. - Theoretically, we could even create a child theme, e.g. with a functions.php, or a custom theme.json for better control of the Gutenberg editor features.
This. @maltmann-muc to the moon 🚀🤘👩🚀
Though technically it doesn't matter, semantically it is strange that Oxygen is a plugin instead of a theme in the first place, given that it effectively functions as one. An official blank theme would be a welcome standardized way to ensure everyone is running the same theme environment. My only feedback would be that I personally use a blank theme I created specifically so that I can control theme.json to enable/disable options in Gutenberg. I would not want to lose that capability, so I'd support this move as long as some consideration goes into that -- either by creating a theme.json editor of some kind in Oxygen, or by implementing this in a way that allows a child theme as Matt mentioned.
@shoelaced Absolutely, in this case theme.json can simply be defined in the child theme, overriding parent settings and styles.
You got my vote.
mi vote
👍
up
- Plugins that require a working theme would be satisfied
- Theoretically, we could even create a child theme, e.g. with a functions.php, or a custom theme.json for better control of the Gutenberg editor features.
This! And we are even more flexible in working with Oxygen. Makes a great tool even greater and much less annoying for some tasks. No need to hack around with own workarounds any longer.
Upvoted.