Calypso Page screen on Atomic sites reverts to old design

sethmclellana8c commented 1 year ago

Quick summary

On an Atomic site, if you go to edit a page, then return to the "Pages" screen in My Site menu, the design of the Pages screen (listing all available pages) reverts to some sort of old design. Reloading the page refreshes the screen and the design goes back to the "normal" design we're used to.

https://user-images.githubusercontent.com/37377834/200963965-cb044ab1-85aa-4507-83ba-c9b9cadba560.mov

Steps to reproduce

Open an Atomic site
Go to My Site > Pages
On a page line item, click the 3-dots-menu and select Edit
When the Editor screen loads, click the W in the top left to open the menu, then select "< All Pages"
You'll be taken back to the Pages screen in My Site, except the design of the screen is now an older design
Selecting "Pages" from the left sidebar reloads the screen and the design updates to the "proper" screen

What you expected to happen

The design for the Pages screen should stay a consistent design. The modern design.

What actually happened

The Pages screen loads some sort of retro design which can be corrected upon reload.

Context

I was able to trigger this multiple times on two different Atomic sites. This did not happen when I tried it on a Free test site.

Platform (Simple, Atomic, or both?)

Atomic

Theme-specific issue?

I tried on two different Atomic sites with different themes installed.

Browser, operating system and other notes

Chrome Version 107.0.5304.87 (Official Build) (arm64)

Reproducibility

No response

Severity

No response

Available workarounds?

No response

Workaround details

No response

zachspears commented 1 year ago

Able to reproduce in Atomic site on Chrome. This issue is not present in Firefox.

danielbachhuber commented 1 year ago

wojtekn commented 1 year ago

It would make sense to hold with this until we finalize removing the sidebar in https://github.com/Automattic/wp-calypso/pull/71061

The related discussion p58i-dox-p2#comment-56472

simison commented 1 year ago

@wojtekn the same problem was present even when I removed the sidebar, so I think there's something else going on.

It's not the link that needs fixing I assume, it's that the wp-admin version doesn't redirect to Calypso version when it should.

wojtekn commented 1 year ago

I couldn't reproduce it for Atomic sites. I tried to switch between Classic and Default views multiple times in different combinations, and each time I landed at the Default list view:

Screen Capture on 2022-12-20 at 18-10-09

Do we have a consistent way to reproduce it?

kozer commented 1 year ago

Tried to replicate it as well. I get the same outcome as @wojtekn . I can't find a consistent way to reproduce it.

katinthehatsite commented 5 months ago

I spent some time testing this today and was not able to reproduce this either. Now that we have both Classic and Default view, I made the tests with both.

Classic View

https://github.com/Automattic/wp-calypso/assets/25575134/96058cdb-244d-4a67-bbea-05a4a139fe42

Default View

https://github.com/Automattic/wp-calypso/assets/25575134/fd9256bf-d04b-4b55-8142-7cdc7409659a

Since none of us could reproduce this and there were no other incoming reports, I will close this issue for now. It might have been resolved by introducing classic vs. default views. In any case, feel free to re-open should it happen again and we will be happy to take a further look.

github-actions[bot] commented 5 months ago

Support References

This comment is automatically generated. Please do not edit it.

[ ] p58i-dox-p2#comment-56472
[ ] 6527289-zen

katinthehatsite commented 5 months ago

Actually I cancel my words, I took a look at the site mentioned in the related issue: https://github.com/Automattic/wp-calypso/issues/49486 in this ticket 6527289-zd-a8c and I could see the issue for both pages and posts. This was the site: penguinread.com

Despite having the Default view selected, the customer is still having the redirect to wp-admin. Let's keep it open and i will check this closer in the next few days

katinthehatsite commented 5 months ago

I spent some time troubleshooting this with @jeroenpf and here are some notes so far.

Firstly, we finally figured out how to reproduce the issue. We used penguinread.com site as an example. Originally, it seemed the screen reverts to the older design but the screen actually links to wp-admin even before you get out of the editor. To illustrate, with the usual flow:

you first navigate to https://wordpress.com/posts/{yourAtomicSite}
click three dots by a page that you want to edit and hover over the Edit menu item
observe that it is linking to `https://wordpress.com/post/{yourSite}/{postId}

click on the site icon in the top left corner and observe that the link to View Posts or View Pages links back to Calypso:

Now, on the user's site, we can see that even before we enter the editor, they are already being linked to wp-admin:

So when we exit the editor, we are also being linked to wp-admin.

Firstly, we established that the redirect happens because is_jetpack_site_eligible_for_gutenframe in editing-flow.php fails. For this specific site (penguinread.com), it fails the condition that there must NOT be a conflicting plugin from the list of denied_plugins for the user not be redirected to wp-admin. There was siteorigin-panels plugin enabled that is added to the list of the denied plugins. Hence, the user is not elligible for the Gutenframe and they get redirected to wp-admin instead.

This is how you can reproduce the issue:

Ensure you have an Atomic site
Install one of the plugins that conflict with Gutenberg. Here are some examples for inspiration: academic-bloggers-toolkit, divi-builder, elementor, js_composer, kadence-blocks, thrive-visual-editor
Repeat the steps from the issue description

It seems logical that if the user has a plugin that conflicts with gutenberg/ gutengrame, we redirect them to wp-admin. However, if their admin interface is set to Calypso and they get to the editor from Calypso, the should get back out of the editor to Calypso as well for the consistency of the user experience.

Other related notes that seem to be relevant but still need to be made sense of:

this PR is of interest as it implemented how calipsoify is running when the user is using the sidebar to close the editor: https://github.com/Automattic/wp-calypso/pull/42518
it seems that the code in iframe-bridge-server.js is overriding the default behaviour of the sidebar when you navigate out of the editor
there seems to be a a8c.WpcomBlockEditorNavSidebar.closeUrl filter in iframe-bridge-server.js that is responsible for closing the URL
then, [this a8c.WpcomBlockEditorNavSidebar.closeUrl] filter seems to be applied inside wpcom-block-editor-nav-sidebar
Default/wp-admin URL is constructed in this line
closeURL for calypsoifyGutenberg that is in Jetpack: https://github.com/Automattic/jetpack/blob/b969a79cd34a52fee7cc01f99a20d8545d797148/projects/plugins/jetpack/modules/calypsoify/class-jetpack-calypsoify.php#L76
get_calypso_url in Jetpack: https://github.com/Automattic/jetpack/blob/b969a79cd34a52fee7cc01f99a20d8545d797148/projects/plugins/jetpack/modules/calypsoify/class-jetpack-calypsoify.php#L108

Other notes:

Testing steps for applying ETK changes: https://github.com/Automattic/wp-calypso/pull/72657 - we can use similar approach

That's where we ended up for now and next will check how that close URL is executed.

Automattic / wp-calypso