ClassicPress/ClassicPress-v2

🐞 Discussion about FSE themes throwing errors in CP v2 and possible solutions

Closed this issue · 5 comments

Deleted user commented

Expected behavior

When looking for a theme I see all the themes are installable. There are 3 types of themes (Classic, block and FSE). Installing Classic or Block themes do work. FSE themes throw an error:

"There has been a critical error on this website. Please check your site admin email inbox for instructions."

They do not have the code to use the customizer and they break the site.

Expected behaviour is having some sort of notice warning me that that specific theme cannot be installed.

Current behavior

As of now the FSE themes do install and break the site

Possible solution

disabling the install button for FSE themes

Steps to reproduce bug

trying to install and activate a theme that is FSE outputs the error after activation

Context

No response

ClassicPress version

2.0

PHP version

8.1

Can you help?

I can help test a solution

viktorix commented

@ElisabettaCarrara thanks for bringing this up.

I agree. We need to deal with block themes.

@xxsimoxx can we use block compatibility feature from #25 to prevent block themes from causing an error?

If we can filter out block themes from theme search, users might accidentally still upload a zip file with block theme. So it would be good if we could prevent errors.

Overall, we should see if it's possible to exclude block themes from theme search in admin.

xxsimoxx commented

@xxsimoxx can we use block compatibility feature from #25 to prevent block themes from causing an error?

Sure @viktorix .
We have to point out which functions can be "polyfilled".

Maybe also check for full-site-editing tag.

Deleted user commented

I have to point out one thing, some block themes do work, the ones having fallback code for the customizer. The completely FSE block themes either have a notice upon activation like Twenty-twentythree that they are broken OR they crash the site without the notice. So we could just exclude the ones that do not have the fallback code to use the customizer? but then again as you say we still do need the polyfills because the block themes can throw errors and even with customizer code they sometimes malfunction.

mattyrob commented

I think this may be the function to polyfill and report potential incompatibility.

is_block_theme()

  • 👍1
viktorix commented

I did a little digging around. There are two things we need to look at:

  1. Before theme is installed, in the search, WP uses a tag to identify block themes: full-site-editing. This is what's used to filter block themes in the themes page search (js code here).
    • Next step: We need to filter API results to exclude themes tagged with full-site-editing in search results.
  2. As @mattyrob suggested, we need is_block_theme() function (WP code reference).
    • Next step: Instead of polyfill, we should restore the function to its original location to reduce merge conflicts. This is where it should be.
    • Then we can add necessary checks, notice, and prevent block themes from being activated.

Side note: WP core uses themes API v1.2, but it's not documented anywhere. It does seem to work similarly to v1.1.

  • 👍1