Wp-calypso: Editor: Opens to Browser Instead of In-app (current ver. 6.3.0)

[dsrl91]

Steps to reproduce

1. Starting at any post editing option within the desktop app (edit draft/post, "write" button, etc)
2. Editing any form or post will prompt the app to open the browser version of the visual/block editor.

What I expected

Open post editor within desktop app.

What happened instead

Opens Chrome to wp-admin post editor page.

Browser / OS version

Google Chrome / Windows 10

Other Information

Disclaimer: I am a basic user without any knowledge on code and used builders or defaults to create and manage my sites. I am simply reporting a persistent issue I cannot seem to figure out or find with basic research. Perhaps, the terminology I use is incorrect, as well.

I have been using the desktop app to write posts since 2016. Created a new site earlier this year mostly run with theme.co and sliderRev, but posts/portfolio page are default WP pages without any major customizations. Both sites are self-hosted and worked fine within the app until around the July/Aug 2020 update, which prompted a manual update via email to 6.1.0 forward due to known update failure bug. Currently on 6.3.0 as of writing and is current available version. Prior to updating to the current version, I kept using the wp-admin editor as a workaround.

Jetpack seems to be installed properly. Login has no issues on both admin or wp-com accounts on either browser or app, respectively. Sites and stats show properly. No enabling block editor settings exist in admin site or desktop app settings.

Theme.co or Slider Revolution has no deliberate involvement to the Posts and Portfolio pages.

Ran as administrator. Web designer colleague (not familiar with desktop app functions) assessed cookie/https issues, and checked code for abnormalities.

Restarted, first, then reinstalled app on 2 Windows 10 machines. Same issues persist in either case.

iOS app editors work within the app; setting to enable block editor also exists and was ticked "ON".

I'm beginning to sense either a major user error related issue due to my lack of technical experience on the matter OR a direct desktop app bug for certain conditions that my sites are in.

[danjjohnson]

We've had a similar report in the Jetpack forum, and both myself and @StefMattana have confirmed the issue.

Steps to reproduce:

1. On a Jetpack connected site, make sure SSO is disabled (Manage > Settings > Security > WordPress.com Login)
2. If you are already logged into the site via wp-admin, log out.
3. In WordPress.com, try to edit a post/page.

Expected

Should be able to edit the post in WordPress.com

Actual

Redirected to wp-admin login page.

If you enable SSO and log in to the site using your WordPress.com login, then you can edit posts/pages in WordPress.com

[cathymcbride]

If the non-desktop app repro is different, please let @danjjohnson or myself know, so we can break that into a separate issue.

[danjjohnson]

FWIW, I just tested the same steps in the desktop app. At first, I was prompted to enable SSO, or continue in browser. After enabling SSO it opened the post editor in the app, but when I tried to actually edit anything, I was redirected to wp-admin in the browser. All seems like the same issue to me.

[jeherve]

In WordPress.com, try to edit a post/page.
Expected

Should be able to edit the post in WordPress.com

Actual
Redirected to wp-admin login page.

I believe that's the expected behaviour. Since we've deprecated the classic editor in Calypso, the only option is the WordPress.com block editor, an iFramed version of the editor from wp-admin. You consequently need to be logged in to access that page.
If SSO is enabled, we're able to log you in as you open the WordPress.com block editor. If you don't use SSO, you have to log in on your own.

Editing any form or post will prompt the app to open the browser version of the visual/block editor.

This, however, seems to be a problem. I believe you should be able to use the WordPress.com block editor from within the app as well. That said, there may be limitations that stop us from doing that. I'll leave that to the folks in charge of the Desktop app, they may know more about this.

[RCowles]

@jeherve we're seeing a similar issue in this Jetpack forum thread. We've ruled out plugin/theme conflict but the issue persists. Is this related to the same issue described above? And either way, any suggestions on where to take it from here?

[designsimply]

We noticed this in beta testing for WPDesktop 6.4.0-beta1 too.

The following Quick links from the Manage your site list take you to a new browser window:

Write a blog post
Add a page
Edit menus
Customize theme

• Tested with Windows 10 Pro – AT site

/hat tip Miguel Campal for reporting this (internal reference: p5T066-1BY-p2#comment-6241) ❤️

[jeherve]

We've ruled out plugin/theme conflict but the issue persists. Is this related to the same issue described above?

Most likely, yes.

cc'ing @Automattic/explorers on this, since they've worked on deprecating the classic editor on WordPress.com in the past few months.

[nsakaimbo]

AFAIK Atomic users will be redirected to WP Admin for a number of flows - in the Desktop app, this will manifest as being re-routed to an external browser.

For the editor specifically, enabling SSO for the site should allow Atomic users to use Gutenberg in-app (but there could be a regression or bug we're unaware of breaking this for specific users).

Also, if the user happens to have the Classic Editor plugin enabled, they _will_ be redirected to an external browser regardless of whether SSO is enabled.

[dsrl91]

SOLVED

Thank you all for being on this. As the latest response by _nsakaimbo_ says, my initial web designer installed Classic Editor. I have just deactivated it and block editor opens up via the Desktop App. Mind you, my install of WP is more or less fresh with just a handful of non-invasive plugins and Slider Rev, for the most part.

Problem:

Desktop App "edit" options opens on browser 100% of the time

Expected Result:

Desktop App allows in-app editing of text

Aggravating Factor mentioned by _nsakaimbo_:

Installation of "Classic Editor" plugin

Solution for _MY_ instance:

Deactivation of "Classic Editor" plugin

Disclaimer: may still be an on-going issue for other users, but the solution mentioned above solved mine in my instance in ver. 6.4.0 as of today (11/16/20)

[cathymcbride]

Closing per comments above. Should anyone else run into it, please feel free to re-open.