Homepage replacement on AT: Fix default behaviour

[andres-blanco]

The current behaviour on Atomic is to always preserve the home page.
This PR sets the dont_change_homepage to true on the themes/mine POST request that is made when the Activate button is pressed. If this change is not added now, when this PR (1046-gh-Automattic/wpcomsh) is merged the default action would change on Atomic to "Always replace homepage" and we don't want that.

Testing

1. Apply this PR.
2. Go to a Simple site.
3. Verify changing themes works as expected on its two flavors (replacing and preserving homepage).
4. Go to an Atomic site.
5. Verify changing themes preserves the homepage, the behaviour should be the same as WP.com.

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-38273

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-38273&env=jetpack

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~22 bytes added 📈 [gzipped])

name      parsed_size           gzip_size
themes          +22 B  (+0.0%)       +7 B  (+0.0%)
theme           +22 B  (+0.0%)       +8 B  (+0.0%)
checkout        +22 B  (+0.0%)       +7 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[mreishus]

I don't fully understand what's happening here, but I noticed if I switch to a theme on an atomic site, and that theme hasn't been used on that site before, it uses this block of code which skips over the addition in this PR. Is that an issue?

If the theme has been installed before, I do see it using the new code and overriding keepCurrentHomepage.

[andres-blanco]

I don't fully understand what's happening here, but I noticed if I switch to a theme on an atomic site, and that theme hasn't been used on that site before, it uses this block of code which skips over the addition in this PR. Is that an issue?

If the theme has been installed before, I do see it using the new code and overriding keepCurrentHomepage.

You are right. the value should be set before that conditional because all AT sites are JP sites. I will modify and retest, nice catch!.

[andres-blanco]

I don't fully understand what's happening here

@mreishus It's kind of contrived but I will try to explain. On Simple when you click on 'Activate' you are presented with a modal that gives you two options, preserve or replace your homepage. This option is controlled by a strangely named POST arg called dont_change_homepage, if the user chooses to preserve then dont_change_homepage is true otherwise it's not even sent.
Currently when you click on 'Activate' on a theme on Atomic there's no modal and the behaviour defaults to preserving your content.

Adding this PR (1046-gh-Automattic/wpcomsh) to wpcomsh will do two things:

• Enables the hooks on theme switch to replace the homepage if needed.
• reads the dont_change_homepage arg and disables the home page replacement process (this process was copied almost verbatim from WPCOM).

The thing is that if the dont_change_homepage argument is not sent then the process can not be deactivated causing the home page to be replaced, changing the current default behaviour on Atomic. So I need this change to explicitly set dont_change_homepage to true.

Once the homepage modal is enabled in Atomic this will not be needed anymore.

[mreishus]

Ok, makes sense. LGTM as I see no changes in behavior on either simple or atomic when changing themes.