Partial Preload trying to access incorrect shop page urls (WooCommerce)

[webtrainingwheels]

When you publish a product in WooCommerce or update it, Partial_Preload is trying to access some incorrect URLs for the page set as the Shop page in WooCommerce.

On every product publish/update, these 3 URLs 404:

Steps to reproduce:

• Activate WooCommerce
• Go to WooCommerce > Settings > Products: make sure the Shop page has been set (it can be set to any page): https://jmp.sh/8midTHf
• Make sure preload is active in WP Rocket
• Update a product
• Use whichever tool you like to log 404 errors (I used Redirection plugin)
• Observe that the URLS indicated give a 404: https://jmp.sh/dGHBk7w

Tickets:
https://secure.helpscout.net/conversation/986778716/127894?folderId=377611
https://secure.helpscout.net/conversation/983825572/127434?folderId=377611

[webtrainingwheels]

@Tabrisrp Is it a duplicate, or related to : #1904 ?

[Tabrisrp]

Is the shop page the archive page for the Products CPT?

[GeekPress]

@webtrainingwheels If you have a chance to remind you the problem, can you reply to @Tabrisrp question? 👆

[webtrainingwheels]

@Tabrisrp ummmm sorry for the delay! ;) Yes, the shop is the archive page for Products

[camilamadronero-zz]

Related: https://secure.helpscout.net/conversation/1151176167/161778?folderId=2675957.

[GeekPress]

@webtrainingwheels Thanks for the response.
Will it be possible to update your original post with the Steps to reproduce section?

[webtrainingwheels]

@GeekPress done

[alfonso100]

Another case here: https://secure.helpscout.net/conversation/1296584740/198620/

[webtrainingwheels]

Similar case: https://secure.helpscout.net/conversation/1320995121/205970?folderId=377611
In this case it's the archive page for a different CPT, not the Shop one.

Similar to Alfonso's case above, Preload is trying to directly access:
index-httpspage (???)
index-https.html_gzip
index-https.html

[vmanthos]

Similar to Alfonso's case above, Preload is trying to directly access: index-httpspage (???)

When rocket_clean_post() runs we are gathering related posts to clean their cache. That's being done with rocket_get_purge_urls().

This seems like it could be coming from here:

wp-rocket/inc/common/purge.php

Line 74 in e493551

$purge_urls[] = $post_type_archive . $filename . $GLOBALS['wp_rewrite']->pagination_base;

[NataliaDrause]

Same issue: https://secure.helpscout.net/conversation/1355362490/219272/

[vmanthos]

This is happening because of what I mentioned in my previous comment on this thread.

We are adding the $filename here, which we shouldn't be doing:

wp-rocket/inc/common/purge.php

Line 74 in e493551

$purge_urls[] = $post_type_archive . $filename . $GLOBALS['wp_rewrite']->pagination_base;

Note:
We should investigate if the resulting URL should include a trailing slash or not.

Slack Conversation: https://wp-media.slack.com/archives/C43T1AYMQ/p1610721622025900

Related ticket: https://secure.helpscout.net/conversation/1393456557/230505

[NataliaDrause]

Related: https://secure.helpscout.net/conversation/1421855418/238401/

[webtrainingwheels]

https://secure.helpscout.net/conversation/1495106947/259280?folderId=377611

[NataliaDrause]

Related: https://secure.helpscout.net/conversation/1561866652/276589/

[DahmaniAdame]

Related - https://secure.helpscout.net/conversation/1790422765/326752/

[webtrainingwheels]

Temporary solution: https://docs.wp-rocket.me/article/1506-remove-custom-post-urls-from-purge

[piotrbak]

As an update for this specific case and the new Preload:

1. Warning in the logs is not present
2. We're clearing the cache of shop (archive for WooCommerce products) correctly
3. We're not changing the status of shop in the database
4. We're adding the unnecessary entries (shop/index-https.html shop/index-https.html_gzip shop-7/index-httpspage) to the database and setting their status to pending
   

[CrochetFeve0251]

Reproduce the problem

The problem was easy to reproduce.

Identify the root cause

The root cause of the problem is coming from the clearing cache logic.
As we don't want it to clean recursively every files inside the shop folder, we have to precise files.
However at the level of the preload we are saving urls given directly.

Scope a solution

A quick solution would be to remove index.html or index.html_gzip from url we add to preload.

For that we can create a new filter rocket_preload_format_url before adding the url to the database in create_or_update and create_or_nothing.

Then we will create a method format_preload_url on the Preload subscriber with the following logic:

public function format_preload_url( string $url ) {
 return preg_replace('/(index\.html)|(index\.html_gzip)$/', '', $url);
}

Finally we will hook that function to the filter rocket_preload_format_url.

Estimate the effort

Effort XS

[NataliaDrause]

Related: https://secure.helpscout.net/conversation/2032139861/373700?folderId=3864740

These URLs are being preloaded:

https://www.profesenapuros.com/tienda/index-httpspage/
https://www.profesenapuros.com/tienda/index-https.html_gzip/
https://www.profesenapuros.com/tienda/index-https.html/

[alfonso100]

related:
https://secure.helpscout.net/conversation/2004873613/367560?folderId=273766