/?redirect_to=random&post_type=product also querying Trashed products

I tried on my server and cannot reproduce it. A product that previously appeared in the result disappeared after I trashed it. Could it be an issue with caching?

What do you see when you add &rutpdebug=2 to the URL:
/?redirect_to=random&post_type=product&rutpdebug=2

There should be something like: ["post_status"]=> string(7) "publish". Do you use a special form of trashing product, which doesn’t use the WordPress post status but another marker? Is it possible that another plugin modifies the post query so that ["post_status"]=> string(7) "publish" disappears?

Debug mode is on. We will only display the resulting URL, without redirecting.

We use redirect_to=random.
Query parameters:
array(7) {
  ["fields"]=>
  string(3) "ids"
  ["ignore_sticky_posts"]=>
  bool(true)
  ["order"]=>
  string(4) "DESC"
  ["post_status"]=>
  string(7) "publish"
  ["post_type"]=>
  string(7) "product"
  ["posts_per_page"]=>
  int(-1)
  ["suppress_filters"]=>
  bool(true)
}

We found 60205 matching post(s) in the cache.
We picked a random post.

————————————————————-

This is showing that only published posts are being queried. Also the total number of posts 60205 is the number for published posts.

Here is our random product URL https://bit.ly/3nCS6xP

Every now and then it generates a 404 error as it redirects to something like /?post_type=product&p=21561. Upon checking the id 20561 and others like this we found they were all trashed.

But in this case it is redirecting to a product that is in trash

Debug mode is on. We will only display the resulting URL, without redirecting.

We use redirect_to=random.
Query parameters:
array(7) {
  ["fields"]=>
  string(3) "ids"
  ["ignore_sticky_posts"]=>
  bool(true)
  ["order"]=>
  string(4) "DESC"
  ["post_status"]=>
  string(7) "publish"
  ["post_type"]=>
  string(7) "product"
  ["posts_per_page"]=>
  int(-1)
  ["suppress_filters"]=>
  bool(true)
}

We found 60205 matching post(s) in the cache.
We picked a random post.

=> The resulting URL is: https://salescanner.com.au/?post_type=product&p=99283

For more help visit the documentation.

I tried on your site and it always says “We found 60205 matching post(s) in the cache.” Actually, the cache should be renewed after 60 seconds (by default), showing a message that the database was queried.

If I try with cache completely turned off

https://salescanner.com.au/?redirect_to=random&post_type=product&cache=0&rutpdebug=2

I find less posts: “We found 55695 matching post(s) in the database.”
This means that for some reason your cache doesn’t expire. So the cache is not up to date with the current state of the database.

When I manually add an expiry time, then it doesn’t work with the default of 60, but it does work with other times and the cache expires.

I have no idea why 60 causes the transient to not expire. Maybe there was a bug in a previous version that saved it with an expiry time of 0 (=infinite). You could delete that transient – starting with “chatty_mango_rutp_post_ids” – manually and check then with debugging enabled if the cache will rebuild. Alternatively, you could set the seconds in your link permanently to anything else than 60:

https://salescanner.com.au/?redirect_to=random&post_type=product&cache=59

Or you define the constant if you cannot modify the URL.

Thank You. This seems to have solved the issue.