Skip to content

[Gutenberg] Unsupported block fallback#11919

Merged
marecar3 merged 42 commits intodevelopfrom
gutenberg/unsupported-block-fallback
Jun 8, 2020
Merged

[Gutenberg] Unsupported block fallback#11919
marecar3 merged 42 commits intodevelopfrom
gutenberg/unsupported-block-fallback

Conversation

@marecar3
Copy link
Copy Markdown
Contributor

Proof of concept Unsupported block fallback on native side.
This opens a web view with a new-post editor, and insert the required block via "User Content Javascript" (JS code inserted to the web view).

We extract the final block content in the same way.

To clean up the canvas from unwanted UI elements we inject CSS that hides those elements.

gutenberg-mobile side PR: wordpress-mobile/gutenberg-mobile#2063

PR submission checklist:

  • I have considered adding unit tests where possible.
  • I have considered adding accessibility improvements for my changes.
  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

@marecar3 marecar3 added the Gutenberg Editing and display of Gutenberg blocks. label May 14, 2020
@marecar3 marecar3 requested review from guarani and mchowning May 14, 2020 15:49
@peril-wordpress-mobile
Copy link
Copy Markdown

peril-wordpress-mobile bot commented May 14, 2020

You can trigger optional UI/connected tests for these changes by visiting CircleCI here.

@guarani
Copy link
Copy Markdown
Contributor

guarani commented May 18, 2020

@marecar3 the downloadable build task failed so I haven't been able to test this.

@mchowning
Copy link
Copy Markdown
Contributor

Most likely pulling in the latest changes (with the no-jitpack updates) will get this passing CI.

@marecar3
Copy link
Copy Markdown
Contributor Author

Most likely pulling in the latest changes (with the no-jitpack updates) will get this passing CI.

thanks @mchowning!
@guarani I have updated with the latest develop.

@oguzkocer
Copy link
Copy Markdown
Contributor

oguzkocer commented May 18, 2020

Hi there! 14.9 is being frozen, so this PR is being bumped to 15.0. If these changes have to be shipped with 14.9, please target release/14.9 and cc me in the PR so I can cut a new beta release. Also if you can keep the release dates in mind and bump the PRs & issues you are working on before the code freeze date, we'd really appreciate it.

@oguzkocer oguzkocer modified the milestones: 14.9, 15.0 May 18, 2020
@peril-wordpress-mobile
Copy link
Copy Markdown

peril-wordpress-mobile bot commented May 18, 2020

You can test the changes on this Pull Request by downloading the APK here.

@guarani
Copy link
Copy Markdown
Contributor

guarani commented May 18, 2020

I have updated with the latest develop.

Thanks @marecar3!

@guarani
Copy link
Copy Markdown
Contributor

guarani commented May 18, 2020

Hey @marecar3, I installed the apk and got this error upon opening the editor:

Unable to load script. Make sure you are either running a Metro server (run 'react-native start') or that your bundle 'index.android.bundle' is packaged correctly for release.

I thought that if there was a problem with the React Native bundle, there was a UI test that would have caught that, so I'm not sure if it's an issue on my end or not.

@marecar3
Copy link
Copy Markdown
Contributor Author

Hey @marecar3, I installed the apk and got this error upon opening the editor:

Unable to load script. Make sure you are either running a Metro server (run 'react-native start') or that your bundle 'index.android.bundle' is packaged correctly for release.

I thought that if there was a problem with the React Native bundle, there was a UI test that would have caught that, so I'm not sure if it's an issue on my end or not.

Yes you are right I am getting the same message. Maybe @hypest can help us?

@guarani guarani modified the milestones: 15.0, 15.1 May 29, 2020
@guarani
Copy link
Copy Markdown
Contributor

guarani commented May 29, 2020

@marecar3 I took the liberty of updating this to 15.1 since 15.0 is being cut soon.

Copy link
Copy Markdown
Contributor

@cameronvoell cameronvoell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking good so far, what a cool feature! I left a minor comment related to String constants.

I was able to use the Unsupported blocks feature first try to edit the core/social-links block from within the app and it worked great! jetpack/podcast-player worked well also.

For jetpack/markdown I saw some interesting behavior that prompted the following question:

For some content in the jetpack/markdown, the Unsupported fallback on iOS and Android shows "This block contains unexpected or invalid content" but that same block opens up fine in normal gutenberg Web, both on desktop and mobile browsers. Do we know what could account for the difference here?

This is the HTML view of the block that works on web but not in the unsupported fallback:

<!-- wp:jetpack/markdown {"source":"### This is Markdown\n*Test*"} -->
<div class="wp-block-jetpack-markdown"><h3>This is Markdown</h3>
<p><em>Test</em></p>
</div>
<!-- /wp:jetpack/markdown -->

This is what shows if I press Resolve:
Screenshot_20200602-201647_WordPress

public static final String ARG_BLOCK_CONTENT = "block_content";

public static final String RESULT_SAVED_CONTENT = "saved_content";
public static final String RESULT_BLOCK_ID = "block_id";
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a little confusing that ARG_BLOCK_ID and RESULT_BLOCK_ID have the same value. Probably should be different to ensure that we use the right one in the right place, or we should just reuse ARG_* strings and remove the RESULT_* strings. See comment below.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. Fixed (we are now using only one type of param)

protected void saveContent(String content) {
Intent savedContentIntent = new Intent();
String blockId = getIntent().getExtras().getString(ARG_BLOCK_ID);
savedContentIntent.putExtra(ARG_BLOCK_ID, blockId);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a little confusing, I think in GutenbergEditorFragment you extract this value using RESULT_BLOCK_ID (L473 of GutenbergEditorFragment) and the only reason it works is because it has the same value as ARG_BLOCK_ID.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. Fixed (we are now using only one type of param)

@etoledom
Copy link
Copy Markdown
Contributor

etoledom commented Jun 3, 2020

For some content in the jetpack/markdown, the Unsupported fallback on iOS and Android shows "This block contains unexpected or invalid content"

Great catch @cameronvoell !

What is happening is that the \n from {"source":"### This is Markdown\n*Test*"} is being transformed to an actual new line, breaking this property.

I'm not sure why is this happening, on iOS we are escaping it in the html string we pass to JS (like \\n) but on the JS side is received with *Test*} written on a new line.

Clearly it's happening on both platforms, so the solution might be on the Block insertion script (somehow). Will give it a try!

@etoledom
Copy link
Copy Markdown
Contributor

etoledom commented Jun 3, 2020

For some content in the jetpack/markdown, the Unsupported fallback on iOS and Android shows "This block contains unexpected or invalid content"

So, I haven’t been able to find a good solution for this, but I can confirm that the problem is what I mentioned previously.

The only thing that worked was to replace instances of \n with \\\n on the block html on native side before sending it to JS.

Of course this looks quite ugly and it might break blocks with new lines on its content.

I’m open to suggestions.

Copy link
Copy Markdown
Contributor

@cameronvoell cameronvoell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the changes @marecar3, the changes in the PR look good. We may need some coordination with this PR which seems to be blocking us building with latest gutenberg-mobile develop branch #12041. But otherwise these changes are good to go.

@marecar3
Copy link
Copy Markdown
Contributor Author

marecar3 commented Jun 8, 2020

Thanks for the changes @marecar3, the changes in the PR look good. We may need some coordination with this PR which seems to be blocking us building with latest gutenberg-mobile develop branch #12041. But otherwise these changes are good to go.

Thanks @cameronvoell 🙇

@marecar3 marecar3 merged commit 8cba1de into develop Jun 8, 2020
@marecar3 marecar3 deleted the gutenberg/unsupported-block-fallback branch June 8, 2020 14:22
@guarani
Copy link
Copy Markdown
Contributor

guarani commented Jun 18, 2020

The only thing that worked was to replace instances of \n with \\n on the block html on native side before sending it to JS.

That's true—what wasn't immediately obvious to me is that the content in the JSON object's source had to match the content in the <p> tag, otherwise I'd still get the "This block contains unexpected or invalid content" error. So I had to add one backslash inside the JSON and two more inside the <p> tags.

For future reference here's an example of what worked for me:

<!-- wp:jetpack/markdown {\"source\":\"Hello\\\nWorld\"} -->\n<div class=\"wp-block-jetpack-markdown\"><p>Hello\\\nWorld</p>\n</div>\n<!-- /wp:jetpack/markdown -->

Like @etoledom said above, this isn't a good solution. I spent half a day yesterday digging into this but didn't make much progress. I understand that JSON requires new line characters, \n, to be escaped, resulting in \\n.
What I'm not sure about is whether the invalid content error we're seeing is only because of the newline, or if it also has something to do with the difference between what's in the JSON:

Hello\\nWorld

and what's in the <p> tags:

Hello\nWorld

It appears these have to be exactly the same string for the invalid content message to not appear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Gutenberg Editing and display of Gutenberg blocks.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants