Editing unsupported blocks is disabled on Jetpack and Atomic sites accessed via older WP.com accounts

[dcalhoun]

Describe the bug
A Jetpack-site recently connected to a WPCom account older than December 2018 won’t display the option to open the Unsupported Block Editor. The same applies to Atomic sites.

To Reproduce
Using a WPCom account created before December 2018, follow the steps outlined for UBE TC005.

Click to view detailed TC005 steps

TC005

Precondition

For this test, you need a self-hosted site with the Jetpack plugin installed, activated and connected to a WP.com account. Here are the steps for creating this if needed:

1. Create a site on https://jurassic.ninja/
2. Connect the Jetpack plugin (it comes pre-installed) to a WP.com account
3. By default, Gutenberg is the default editor so no action required there

Editing unsupported blocks is enabled on self-hosted sites accessed via Jetpack

1. On the site described above, add a post, then add a block that's not yet supported on mobile (e.g. Audio at time of writing) via the site's WP Admin web interface
2. Log into the WordPress mobile app using the WP.com account that was used to connect Jetpack to the self-hosted site
3. Open the post and expect to see the unsupported block rendered as a placeholder with the text "Unsupported"
4. Tap the (?) icon and expect to see an option to enable Login with WordPress.com.
5. Tap on that option, and enable Loogin with WordPress.com on the screen presented.
6. Go back and tap the (?) icon.
7. Expect the option to edit the block in a web browser to be shown
8. Tap the edit in a web browser button and expect a web view requesting to Login with WordPress.com.
9. Tap on said option and expect the block to be shown, ready to edit, on a new screen
10. Edit the block content (e.g. update its caption)
11. Tap the Continue button and expect to be taken back to the block editor
12. Publish the post and verify it contains the edits

Expected behavior
The option to "Log in with WordPress.com" is presented, which allows editing the unsupported block via a web view.

Actual behavior
On Android, you are only presented with a notice that the block is unsupported. On iOS, you are provided a message regarding Jetpack security settings, but the "Open Jetpack Securty settings" button appears to not do anything when tapped.

Screenshots

Android	iOS

Smartphone (please complete the following information):

• Device: Samsung Galaxy S20, iPhone SE
• OS: Android 11, iOS 14.4.2
• Version: 17.1

Additional context
Both Android and iOS fail to pass the TC005 test case, but in a different manner.

[jd-alexander]

Thanks for flagging this @dcalhoun I started investigating the issue and I am thinking it may be API related. Here's the logic within the Android codebase:

It seems that the API is returning classic instead of gutenberg for the site's WebEditor so that is causing the UBE to not be enabled thus the logic && "gutenberg".equals(mSite.getWebEditor())) fails even though the block editor/gutenberg is being utilized in the self hosted Jetpack enabled instance.

Below is a screenshot of my site as a SiteModel and the associated WebEditor property.

[enejb]

I notice that on my test jetpack site( selective-squid.jurassic.ninja ) the user I was using would always return "Classic" even though the site didn't have the classic editor installed. Which is definitely not expected. 🤔

[jd-alexander]

True. I noticed that we are usingeditor_web when the editor_mobile property exists and is already being utilized in other parts of the app like here so I was wondering if this is being done because the UBE is editing blocks via the web. Probably @guarani will be able to shed some light on this but overall, I think webEditor logic in the API needs investigation.

[mchowning]

I believe there was a known issue where a Jetpack-site recently connected to a WPCom account older than December 2018 won’t display the option to open the Unsupported Block Editor. I'm not sure whether that is still an issue, but could that be what we're seeing here?

Reference: p9ugOq-Zz-p2#comment-2626

[jd-alexander]

@mchowning that is indeed the issue that we are seeing here. Thanks for the reference to that comment.

[jd-alexander]

So the proper course of action here is to simply update the test checklist with this, as a known issue, so the results/test is ignored until it is resolved right @mchowning ?

[mchowning]

So the proper course of action here is to simply update the test checklist with this, as a known issue, so the results/test is ignored until it is resolved right @mchowning ?

Instead of ignoring the test, could we just update the test so it requires a WPCom account newer than December 2018? It sounds like the test case should work in that case if I'm understanding correctly.

[dcalhoun]

Instead of ignoring the test, could we just update the test so it requires a WPCom account newer than December 2018? It sounds like the test case should work in that case if I'm understanding correctly.

@mchowning thank you for providing this insight. This is my understanding of the situation too. I have opened wordpress-mobile/test-cases#74 to update the test case. I will keep this issue open, but update the details regarding the age of the WP.com account.