Fix coming soon unintentionally expose the rest of the site

[chihsuan]

Changes proposed in this Pull Request:

Closes #1528.

This PR modifies the handling of WooCommerce's coming soon initialization endpoint to respect WordPress.com's site-wide Coming Soon status. Key changes:

• Added a check to detect if WordPress.com Coming Soon mode is active
• If active, we return true immediately to prevent WooCommerce from modifying the site's visibility
• Only set the woocommerce_store_pages_only option when the site is already live

• This PR is a very minor change/addition and does not require testing instructions (if checked you can ignore/remove the next section).

How to test the changes in this Pull Request:

• Have you followed the Writing high-quality testing instructions guide?

Test with Coming Soon mode enabled

1. Set up a WordPress.com business site with Coming Soon mode enabled
2. Install WooCommerce through the plugins menu
3. Go through the core profiler (either skip or complete)
4. Verify that the site remains in Coming Soon mode after the process

Test with Coming Soon mode disabled

1. Set up a WordPress.com business site with Coming Soon mode disabled
2. Install WooCommerce through the plugins menu
3. Go through the core profiler (either skip or complete)
4. Verify that site is in Coming Soon mode with Store Pages only

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?

FOR PR REVIEWER ONLY:

• I have reviewed that everything is sanitized/escaped appropriately for any SQL or XSS injection possibilities. I made sure Linting is not ignored or disabled.

[github-actions]

Size Change: 0 B

Total Size: 201 kB

ℹ️ View Unchanged

Filename	Size
./build/53.js	1.08 kB
./build/index.css	731 B
./build/index.js	126 kB
./build/marketing.js	58.3 kB
./build/payment-gateway-suggestions.css	1.24 kB
./build/payment-gateway-suggestions.js	6.57 kB
./build/plugins.js	3.93 kB
./build/style-index.css	2.15 kB
./build/style-marketing.css	800 B

_{compressed-size-action}

[adrianduffell]

This looks like a good solution, @chihsuan. I could see other hosts having a similar problem in the future if they integrate with coming soon mode. Perhaps we should move the logic to the core rest api and solve it generally? 🤔

[chihsuan]

This looks like a good solution, @chihsuan. I could see other hosts having a similar problem in the future if they integrate with coming soon mode. Perhaps we should move the logic to the core rest api and solve it generally? 🤔

Good idea! I think we can move the coming soon mode check and return 200 logic to the core reset api. But we probably need to keep the logic for setting woocommerce_store_pages_only option in the host, since only they know how to determine if the site is already live for their environment. cc @ilyasfoo if you have any thoughts on this. 🙏

[ilyasfoo]

Tests well, nice work @chihsuan!

[ilyasfoo]

Perhaps we should move the logic to the core rest api and solve it generally? 🤔

@adrianduffell Good point, I think so too.

@chihsuan I think to provide the most flexibility, we could add 2 filters for both of these just before we set them. It should allow for hosts to determine the default coming soon state and store-only mode after going through core profiler

[chihsuan]

I think to provide the most flexibility, we could add 2 filters for both of these just before we set them. It should allow for hosts to determine the default coming soon state and store-only mode after going through core profile

Sounds good! I'll create a follow-up issue for this.

[adrianduffell]

Code change makes sense and LGTM! Thanks @chihsuan 🚀