Automattic / wp-calypso

The JavaScript and API powered WordPress.com
https://developer.wordpress.com
GNU General Public License v2.0
12.42k stars 1.99k forks source link

Design Picker: menus on sites created using the design picker aren't set up correctly #57260

Closed p-jackson closed 2 years ago

p-jackson commented 3 years ago

Steps to reproduce

  1. https://wordpress.com/start?flags=signup/setup-site-after-checkout (use the explicit flag to guarantee the feature is enabled)
  2. Go through signup flow, can just choose free site
  3. Choose a design from the design picker that has a menu e.g. Geologist

What I expected

The newly created site has a correctly configured menu. It doesn't have to perfectly match the menu in the thumbnail (we might decide to trim some of the pages), but it should work at least.

What happened instead

The menu has been created in the new site, but the "menu location" isn't configured correctly, so it doesn't appear on the front end of the site

Screenshot / Video

The menu in the Geologist demo site:

Screenshot 2021-10-22 at 9 25 08 PM

Menu settings of a newly created site:

Screenshot 2021-10-22 at 9 27 19 PM

Some Links

p1632210899071500-slack-CRWCHQGUB pdgK6S-9j-p2#comment-318

autumnfjeld commented 2 years ago

@p-jackson It seems like these items, reported in the CfT are related: Link to sheet image

If they aren't related, I'll make new issues for them.

bitmoji

p-jackson commented 2 years ago

@autumnfjeld the 2nd row is the same as this issue.

The 3rd row seems like it could the same as this issue. This could be what it looks like when the primary menu has been applied to the secondary menu location. Which would mean it's the same issue.

The 1st row is sort of by design, sort of known issue. We know that links to other pages will often link to the demo site. I suppose we could add new headstart functionality to migrate those links over to the newly created site, but it's not straightforward. Or we could change all the demo site's to not have this sort of link on any pages, but that seems like quite a limitation. It's a bit of a quandry.

roo2 commented 2 years ago

@p-jackson I went through this with the zoologist theme, it looks to me like it's just {"trim_content": true} being passed in that is causing the menus not to be setup, which would be as intended? When I made a request from my rest client with {"trim_content": false}, the menu was added as expected.

In the slack thread p1632210899071500-slack-CRWCHQGUB you mentioned originally testing it with this diff D67131-code I haven't tried that, but I also want to make sure that this issue is still occurring with current themes and content trimming.

roo2 commented 2 years ago

ah ok, I can reproduce the issue with the twentytwentyone theme, I can reproduce it in postman by making a request to change the theme POST .../themes/mine and then a request to run headstart POST .../theme-setup in quick succession. This simulates what happens on the processsing screen after a theme is selected in the start flow.

The issue happens only when both requests are sent in quick succession, if time is left between them, the menus are set up correctly.

@p-jackson suggested it may be an async job kicked off by one of the requests which looks likely to me p1639428751075700/1639398526.064700-slack-C029SB8JT8S

p-jackson commented 2 years ago

Ah yes, I wasn't sure about whether the theme change had anything to do with it. It could be that it's an async job associated with the theme change that's breaking it.

All of these themes are auto-loading-homepage themes. I wonder if that auto-loading-homepage feature happens to be doing anything with the menus? If changing themes changes the homepage then maybe that results in some menu processing to try to add the new homepage to menus?

roo2 commented 2 years ago

@p-jackson I've got a fix proposed, it turns out it's related to cleanup that's done on the first wordpress reload that's done after a theme is switched. D71479-code

p-jackson commented 2 years ago

Fixed by D71479-code