Theme preview is not working for block themes

[kafleg]

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.

[Otto42]

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.

[poena]

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.

[dd32]

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.

[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

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

[dd32]

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..

[dd32]

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...)

[oandregal]

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.

[dd32]

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' );
+ 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..

[dd32]

In 11223:

Theme Previews: Namespace the gutenberg_global_styles transient by theme.

See #5818.

[oandregal]

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

[dd32]

In 12078:

Theme Previews: Transient Namespacing: Remove this plugin, as it's no longer needed.

This was rendered unused as the transients are now properly keyed by stylesheet upstream in Core and Gutenberg.

See ​https://github.com/WordPress/gutenberg/pull/34704
See #5818.