-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug]: Erroneously throwing error #1986
Comments
Note, we are using null in the block-support example
|
I couldn't replicate the issue using https://github.com/wpengine/faustjs/tree/canary/examples/next/block-support but I had some other issues with a missing BlockB type in the template throwing an error for a missing type - https://gist.github.com/colinmurphy/2b97f29bbb90a5214406a32148a8d18e I will try tomorrow and setup the canary branch and follow the setup tutorial to try and replicate the issue. |
@moonmeister I still cannot replicate the issue with a fresh install of Faust. I am using faust/blocks version 5 but that particular function isn't updated between 4.1.0 and the latest version. I tried the following config changes and these all worked locally.
|
@moonmeister Can you still replicate the issue? |
… and also updates tests to use WP 6.6 and 6.7 Fixes various issues with using content replacement for the site URL.
Description
We were getting :
Error: useBlocksTheme hook was called outside of context, make sure your app is wrapped with WordPressBlocksProvider
This simply wasn't the case. AS you can se from the
_app.js
A quick mental check told me I'd recently edited one line in here. Reverting that fixed this issue:
This was strange as in JS these should be practically the same.
Some code seleuthing quickly turned up:
faustjs/packages/blocks/src/components/WordPressBlocksProvider.tsx
Line 75 in e17d318
The use of
===
means we don't type castnull
to undefined even if it's practically the same. And allowingnull
to work whileundefined
doesn't.So, being the docs show a prolific use of
null
to no pass a theme butundefined
doesn't work, neither does simply not passing thetheme
in the config object. Seems like the fundamental issue here is we're checking for theWordPressBlocksProvider
based on the value oftheme
and not wether theWordPressBlocksContext
orWordPressThemeContext
are actually availableSteps to reproduce
See above
Additional context
related: #1844
@faustwp/core Version
3.1.0
@faustwp/cli Version
3.1.1
FaustWP Plugin Version
na
WordPress Version
na
Additional environment details
@faustwp/[email protected]
Please confirm that you have searched existing issues in the repo.
The text was updated successfully, but these errors were encountered: