wp-rocket
wp-rocket copied to clipboard
wp-media
Partial Preload trying to access incorrect shop page urls (WooCommerce)
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
@Tabrisrp Is it a duplicate, or related to : https://github.com/wp-media/wp-rocket/issues/1904 ?
@webtrainingwheels If you have a chance to remind you the problem, can you reply to @Tabrisrp question? 👆
@Tabrisrp ummmm sorry for the delay! ;) Yes, the shop is the archive page for Products
Related: https://secure.helpscout.net/conversation/1151176167/161778?folderId=2675957.
@webtrainingwheels Thanks for the response. Will it be possible to update your original post with the Steps to reproduce section?
Another case here: https://secure.helpscout.net/conversation/1296584740/198620/
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
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: https://github.com/wp-media/wp-rocket/blob/e49355167e75f1d3cf51ee65c429b75f3e28682e/inc/common/purge.php#L74
Same issue: https://secure.helpscout.net/conversation/1355362490/219272/
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:
https://github.com/wp-media/wp-rocket/blob/e49355167e75f1d3cf51ee65c429b75f3e28682e/inc/common/purge.php#L74
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
Related: https://secure.helpscout.net/conversation/1421855418/238401/
https://secure.helpscout.net/conversation/1495106947/259280?folderId=377611
Related: https://secure.helpscout.net/conversation/1561866652/276589/
Related - https://secure.helpscout.net/conversation/1790422765/326752/
Temporary solution: https://docs.wp-rocket.me/article/1506-remove-custom-post-urls-from-purge
Related ticket: https://secure.helpscout.net/conversation/1824950567/333384/
This is for a custom post type created by the Divi Mega Pro plugin.
https://secure.helpscout.net/conversation/1839999608/336206?folderId=377611
Related: https://secure.helpscout.net/conversation/1861646403/339382?folderId=2135277
Related https://secure.helpscout.net/conversation/1885893114/343229/
Related https://secure.helpscout.net/conversation/1920201248/348460/
https://secure.helpscout.net/conversation/1944925281/354956?folderId=377611
https://secure.helpscout.net/conversation/1963318105/358804?folderId=3864740
As an update for this specific case and the new Preload:
- Warning in the logs is not present
- We're clearing the cache of
shop(archive for WooCommerce products) correctly - We're not changing the status of
shopin the database - We're adding the unnecessary entries (
shop/index-https.htmlshop/index-https.html_gzipshop-7/index-httpspage) to the database and setting their status to pending
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
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/
related: https://secure.helpscout.net/conversation/2004873613/367560?folderId=273766