Add generic function to determine if URL is a store page

[chihsuan]

Submission Review Guidelines:

• I have followed the WooCommerce Contributing Guidelines and the WordPress Coding Standards.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have reviewed my code for security best practices.
• Following the above guidelines will result in quick merges and clear and detailed feedback when appropriate.

Changes proposed in this Pull Request:

Closes #45110.

The function is_store_page is added to WCAdminHelper and is used to determine if a URL is a store page.

Store pages are defined as:

• Shop Page
• Cart Page
• Checkout Page
• My Account Page
• Terms and Conditions Page
• Privacy Policy Page

Additionally, the following autogenerated pages should be included:

• Product
• Product Categories (taxonomy=product_cat)
• Product Tags (taxonomy=product_tag)

The function ignores the domain and protocol of the URL and only checks the path and query string so that users can only pass $_SERVER['REQUEST_URI'] to the function for checking if the current page is a store page.

How to test the changes in this Pull Request:

Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:

1. Create a fresh site
2. Install WooCommerce Smooth Generator and Code Snippets plugins
3. Either skip or complete Core profiler
4. Go to /wp-admin/tools.php?page=smoothgenerator > Generate 10 products OR run wp wc generate products 10
5. Go to /wp-admin/admin.php?page=snippets
6. Add new Snippet

use Automattic\WooCommerce\Admin\WCAdminHelper;

function maybe_add_banner_to_footer() {
	if ( wp_doing_ajax() || wp_doing_cron() || WC()->is_rest_api_request() ) {
		return;
	}

	$is_store = WCAdminHelper::is_store_page();
	if ( $is_store ) {
    	echo '<div style="position: fixed; bottom: 0; background-color: red; color: white; width: 100%; text-align: center;">This is a store page!</div>';
	}
}

add_action('wp_footer', 'maybe_add_banner_to_footer');

7. Select Only run on site front-end and activate
8. Go to frontend
9. Confirm the This is a store page! red banner is displayed on the store pages (Shop, Cart, Checkout, My Account, Terms and Conditions, Privacy Policy, Product, Product Categories, Product Tags) and not displayed on other pages (Home, Sample Page, etc.)
10. Go to /wp-admin/admin.php?page=wc-settings&tab=advanced
11. Change Terms and conditions page to Sample Page
12. Go to Sample Page
13. Confirm the banner is displayed on the Sample Page
14. Go to /wp-admin/options-permalink.php
15. Change Product permalinks to Shop base with category
16. Change Product category base to test-category
17. Go to a product page
18. Confirm the banner is still displayed on the product page
19. Go to a product category page

Changelog entry

• Automatically create a changelog entry from the details below.

Significance

• Patch
• Minor
• Major

Type

• Fix - Fixes an existing bug
• Add - Adds functionality
• Update - Update existing functionality
• Dev - Development related task
• Tweak - A minor adjustment to the codebase
• Performance - Address performance issues
• Enhancement - Improvement to existing functionality

Message

Comment

[github-actions]

Test Results Summary

Commit SHA: 095c963

Test 🧪	Passed ✅	Failed 🚨	Broken 🚧	Skipped ⏭️	Unknown ❔	Total 📊	Duration ⏱️
API Tests	259	0	0	2	0	261	0m 37s
E2E Tests	343	0	0	10	0	353	7m 35s

---

To view the full API test report, click here.
To view the full E2E test report, click here.
To view all test reports, visit the WooCommerce Test Reports Dashboard.

[github-actions]

Hi @rjchow,

Apart from reviewing the code changes, please make sure to review the testing instructions as well.

You can follow this guide to find out what good testing instructions should look like:
https://github.com/woocommerce/woocommerce/wiki/Writing-high-quality-testing-instructions

[psealock]

Code looks good @chihsuan. What about a page with a WooCommerce block, such as the All Product block. Would that count as a store page?

[chihsuan]

What about a page with a WooCommerce block, such as the All Product block. Would that count as a store page?

Good question. 👍 I think it would but I'm not very sure. @adrianduffell, what do you think? This makes me think that we may need to add a filter so that 3rd party developers can add their own store pages to the list of store pages.

[adrianduffell]

What about a page with a WooCommerce block, such as the All Product block. Would that count as a store page?

It's a good point. I think we could tackle this after the MVP. For now, the "restrict to store pages only" setting will link to external documentation that lists the pages which are included. We could add a note in the documentation about blocks not being supported yet.

We would need to come up with a strategy to detect pages with a WooCommerce block without a performance hit on every front-end request. Perhaps we could build an index of block pages each time a page gets saved. The filter also sounds like a good idea 👍

[rjchow]

I left some comments on possible performance implications, not too sure if they are impactful

[rjchow]

Suggested change

	$quey = wp_parse_url( $url, PHP_URL_QUERY );
	$query = wp_parse_url( $url, PHP_URL_QUERY );

[chihsuan]

Fixed in d84d9f2

[rjchow]

I think we can add a filter here for extensibility, what do you think?

[chihsuan]

Sounds good. Added a filter here 095c963 🙂

[rjchow]

not sure how big of an impact it is on performance but there's a get_option() call in wc_get_permalink_structure()

[chihsuan]

That's a good point. I think it's a minor impact. If it becomes a problem, we can optimize it later.

[chihsuan]

From ChatGPT:

The impact of calling wc_get_permalink_structure() on performance depends on various factors such as server configuration, database size, and the context in which the function is being called.

1. Caching: If the result of wc_get_permalink_structure() is cached, subsequent calls to the function within the same request will have minimal impact on performance. WordPress itself caches the permalink structure, so in most cases, calling this function won't cause a significant performance hit.

2. Database: The function involves querying the database to retrieve the permalink structure. The impact may be noticeable on large or busy websites with heavy database loads. However, for most websites, especially those with caching mechanisms in place, the impact should be minimal.

3. Context: If the function is called frequently or in a critical performance path, such as within a loop that executes many times, the cumulative impact may become more significant. In such cases, it's advisable to call the function sparingly or optimize the code structure to minimize redundant calls.

4. Server Resources: The impact also depends on the server resources available. On high-traffic websites or under heavy server load, the impact may be more noticeable compared to low-traffic websites or under light server load.

Overall, calling wc_get_permalink_structure() typically has a minor impact on performance in most WordPress environments, especially when cached properly. However, it's essential to consider the specific context and optimize code accordingly if performance issues arise.

[rjchow]

not sure how big of an impact it is on performance but there's a get_option() call in wc_privacy_policy_page_id()

[psealock]

This is testing well, nice work @chihsuan you've covered a lot of scenarios.

I couldn't spot any issues with the code (other than @rjchow's comments) 🚀

[rjchow]

Thanks for addressing the feedback!