#5818 closed defect (bug) (fixed)
Theme preview is not working for block themes
Reported by: | kafleg | Owned by: | |
---|---|---|---|
Milestone: | Priority: | high | |
Component: | Theme Directory | Keywords: | needs-patch |
Cc: |
Description
On the themes page, we have a preview button but that button is not working for block-based (FSE themes) themes. Check FSE themes and click on preview and nothing will load.
Change History (11)
#2
@
3 years ago
Are there any technical reasons why the preview stopped working, and why enabling Gutenberg so that the theme previews work again is not possible?
Or was this a concius decision to disable the previews?
If so I kindly ask that decisions like this are shared with the themes team so that we can reply with accurate information when we recieve questions about the preview.
The themes are not incomplete.
Block themes don't use index.php and there are no plans from the core editor team to change the format from HTML to PHP.
Themes are not including content in index.php because in 5.8 WordPress will handle showing a message about what kind of theme it is: When Gutenberg is not active.
-The content of index.php would not be shown.
Block themes brings big changes and these themes are important in the directory to help theme authors and users learn.
Not having working previews sets the development and improvement of block themes back as it is not possible to showcase and promote what is possible - and what needs to improve.
For context, the themes team were told that block themes would be able to be activated without Gutenberg in 5.8.
The team planned and acted according to this information and that is why block themes were allowed and added to the directory.
In the end, the release squad needed to make a different decision, and the team is waiting for more information about 5.9.
There are no plans to remove the block themes from the directory.
#3
@
3 years ago
- Resolution set to fixed
- Status changed from new to closed
Are there any technical reasons why the preview stopped working, and why enabling Gutenberg so that the theme previews work again is not possible?
Yes & No.
Gutenberg was disabled quite a few weeks ago now, when the latest version of Gutenberg became incompatible with WordPress trunk (that the previewer uses).
It caused fatals across all w.org sites, so it got deactivated everywhere, and only re-activated where needed. Seems that wp-themes.com never got it reactivated.
I've re-activated it.
#4
follow-up:
↓ 5
@
3 years ago
:wave: I was working on a similar issue that affected the customizer and themes that use the global stylesheet generated by theme.json. For reference, this is the issue https://github.com/WordPress/gutenberg/issues/34531 It turns out there was a cache issue that I'm fixing at https://github.com/WordPress/gutenberg/pull/34540
By looking at the themes under https://wordpress.org/themes/tags/full-site-editing/ I believe what happens there may be related to the customizer bug I've ran into.
Here's what I'm doing to test:
- Load the preview of one of the themes listed at https://wordpress.org/themes/tags/full-site-editing/
- Inspect the contents of the
global-styles-inline-css
embedded stylesheet. - I expect the
global-styles-inline-css
stylesheet to contain theme-specific styles (block styles, preset classes defined by the theme, etc).
When the preview fails to look like the theme, what I find is that the global-styles-inline-css
stylesheet only contains the general styles (body
selector with CSS Custom Properties + some .has-*
classes provided by core) but not the theme-specific ones.
Can we test whether https://github.com/WordPress/gutenberg/pull/34540 will fix this as well? I'm not sure how meta is set up, but a potential harmless and manual testing could be to add that line at https://github.com/WordPress/wordpress-develop/blob/f49d48fdcb30f48307ccab183f9103d8b4527e5c/src/wp-includes/default-filters.php#L338
#5
in reply to:
↑ 4
@
3 years ago
Replying to oandregal:
:wave: I was working on a similar issue that affected the customizer and themes that use the global stylesheet generated by theme.json. For reference, this is the issue https://github.com/WordPress/gutenberg/issues/34531 It turns out there was a cache issue that I'm fixing at https://github.com/WordPress/gutenberg/pull/34540
Hey @oandregal!
The theme previewer doesn't call any of those such filters, as it simply loads WordPress with a different defined stylesheet/template option.
Logic to call that function prior to rendering the page can be added though. Preferably however, Gutenberg should be caching the styles in a manner that is keyed by the theme being displayed.
Without looking closely right now, something else we do is use pre_option_*
filters to prevent some database-set options from being respected - We could do something similar here and simply prevent the cache option ever being set/read to force it to re-create it on every pageload..
#6
@
3 years ago
Additionally, if it makes sense for wp-themes.com to also fire start_previewing_theme
during the bootstrap of the site, that can also be done.
(But we try not to add previewer-specific things to the site, as unscrupulous theme authors in the past have altered their behaviour if they're running on the previewer...)
#7
follow-up:
↓ 8
@
3 years ago
I presume the way wp-themes.com loads the theme fires the setup_theme
hook, is that correct?
We could use that hook to clean the cache. It'd also serve all the use cases (theme directory, customizer, switch themes programmatically, etc.) without the overhead of checking for the current theme in every call.
#8
in reply to:
↑ 7
@
3 years ago
Replying to oandregal:
I presume the way wp-themes.com loads the theme fires the
setup_theme
hook, is that correct?
Yes, setup_theme
fires on every WordPress pageload, regardless of wp-themes.com or not.
We could use that hook to clean the cache. It'd also serve all the use cases (theme directory, customizer, switch themes programmatically, etc.) without the overhead of checking for the current theme in every call.
There should be no real overhead in checking for the current theme in every call, get_stylesheet()
would be called multiple times, and I suspect wp_get_theme()
probably is too.
eg:
-
lib/global-styles.php
31 get_transient( 'gutenberg_global_styles' );31 get_transient( get_stylesheet() . '_gutenberg_global_styles' );
Alternatively, if you can confirm me know which transients are the problem here, I can update some things. It looks like I might've already done it though:
https://meta.trac.wordpress.org/browser/sites/trunk/wp-themes.com/public_html/wp-content/mu-plugins/pub/namespace-transients.php
It looks like I might need to update that to also namespace the gutenberg_global_styles
transient too.. which I'll do now..
#10
@
3 years ago
Nice ones. I've prepared PRs to do that upstream at https://github.com/WordPress/gutenberg/pull/34704 and https://github.com/WordPress/wordpress-develop/pull/1666
For reading the data from the file I still need to do some changes at https://github.com/WordPress/gutenberg/pull/34540
Nothing previews because there is nothing there. Those themes are, for all intents and purposes, incomplete.
Take a look at the first one on that page: https://wordpress.org/themes/rick/
If you look at the index.php in that, it has no output. There is no "theme" to it, in the traditional sense. If you load that onto a site, then it will produce no output. So the preview is actually working there, the theme doesn't produce output when loaded into a current WordPress site.
Themes should probably use better defaults than having just blank pages on them. Themes should also display something meaningful if FSE is not active, as FSE is not yet fully implemented. These themes are still experimental, at present.