Skip to content
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

Gutenberg Single Block mode for Mobile unsupported blocks. #21874

Open
etoledom opened this issue Apr 24, 2020 · 0 comments
Open

Gutenberg Single Block mode for Mobile unsupported blocks. #21874

etoledom opened this issue Apr 24, 2020 · 0 comments
Labels
[Feature] Blocks Overall functionality of blocks Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) [Type] Discussion For issues that are high-level and not yet ready to implement.
Projects

Comments

@etoledom
Copy link
Contributor

Is your feature request related to a problem? Please describe.

On Mobile Gutenberg, we will always have the problem of blocks that are unsupported.
We are working on a solution that will allow the user edit those blocks without leaving the mobile app, using a web view that loads and editor instance from their site.

Ideally we want this web editor instance to just show the single block the user wants to edit, Together with controls to edit this single block, hiding any other control like Page edition, Saving/Publishing, inserting new blocks, etc...

We have a working solution that looks like this:

edit-mid

What we do is basically:

  • We load the wp-admin's new-postURL.
  • We use window.wp.data.dispatch/select to insert/retrieve the HTML content of the block.
  • We use injected CSS to hide the unwanted UI elements.

Insert Block script
Retrieve Block script
Injected CSS

But there are a few issues with this approach:

  • The time of when is safe to inject the block varies on WPCom and a Self-Hosed site.
    • On WPCom, just waiting for window.onload is not enough.
  • We can't hide all the elements we would like to hide using just CSS.
  • We will have troubles if there are changes on CSS classes or if there are bigger structural changes, making this approach quite fragile.

Describe the solution you'd like

The objective of this ticket is to gather ideas for possible solutions to implement on a future version.

This is my innocent solution I would like to see, but you are the masters:

  • It would be great to have a "Single Block" mode, which will not render any element that's not needed for editing a single block. This could be set via a LocalStorage setting or a URL Query (or maybe other).
  • Since window.onload won't work in all cases, maybe we could have an window.wp.editorReady or something similar to know exactly when it's safe to inject the block.
  • Other ways to inject/retrieve the block? My fear it that the current action/selector might get deprecated at some point.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

  • I tried hiding the elements using JS, but it's not easy to find the elements since most of them doesn't have IDs.
  • I've tried using window.wp.data.subscribe to inject the block when the store starts receiving events but this also didn't work. (apparently it's still too early).
  • My first approach to inject the block timely was to wait for a specific element in the editor (edit-post-header) to appear in the document. This worked on WPCom but seemed to be way too fragile.
@gziolo gziolo added Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) [Feature] Blocks Overall functionality of blocks [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues. labels Apr 24, 2020
@youknowriad youknowriad added [Type] Discussion For issues that are high-level and not yet ready to implement. and removed [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues. labels Jun 4, 2020
@hypest hypest added this to Triage in Mobile Apps via automation Aug 11, 2020
@hypest hypest moved this from Triage to To do in Mobile Apps Aug 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks Mobile App - i.e. Android or iOS Native mobile impl of the block editor. (Note: used in scripts, ping mobile folks to change) [Type] Discussion For issues that are high-level and not yet ready to implement.
Projects
Mobile Apps
  
To do
Development

No branches or pull requests

3 participants