-
Notifications
You must be signed in to change notification settings - Fork 58
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
Differentiate unsupported blocks from unavailable #51
Comments
I'd suggest the API thing should go first, since it's basically a requirement to implement this feature. |
@hypest do you know if there is such an API? Can we make that happen so it's ready for Q1? |
The API (WordPress/gutenberg#4116) is not ready yet, and I can't bet sure it will be in 5.0. I don't think there's much to do here if we can't differentiate so I'm postponing this one until we have an API, and we'll just improve styling of the existing unsupported block. |
Sorry I missed the ping earlier. This sounds good to me 👍 |
…n_of_change_events Improve propagation of change events
Putting this on the Backlog and we can revisit if the (ongoing at the time of writing) "Unsupported Blocks Fallback" project is not helping with this. cc @iamthomasbishop |
Turning unrecognized blocks (markup that doesn’t match any of the registered blocks) is the easy part. We also need to identify which blocks are available on the server but don't have a mobile implementation yet.
When the block doesn't exist on the server, we should use a UI similar to the one in WordPress/gutenberg#8274 saying that the site doesn't support that block.
However when it's just not supported on mobile the UI should be different.
To avoid confusion, let's use this terminology unless/until we agree on a new one:
Right now I anticipate we'll need:
Expose available blocks via an API WordPress/gutenberg#4116), and what we need to support that (like WP-API support)
The text was updated successfully, but these errors were encountered: