BUG: frontpage cache is often lost

[dima-stefantsov]

I've had this bug on different sites for a long time. Now my situation was dire enough (~30 sec per page render) to force me debug it.

Bug: frontpage cache is lost, forcing re-render often.

How to reproduce: disable cache timeout (doesn't matter, just for convenience), enable preload mode with no cache expiration. Enable cache rebuild (important).

Make some or all pages... Mobile github lost my report text. In short words, cache it, invoke cron, frontpage cache lost.

Wrong logic in marking 'to remove dir'.

Please fix.

[Sophist-UK]

See Automattic/wp-super-cache#98 for my analysis of the whole cache invalidation issue.

[dima-stefantsov]

It is not connected, except for general idea "wow, this code is bad".

[dima-stefantsov]

#25581 same issue. Wow, it's exact location is reported in 2015. Still no fix. Looks like will have to edit inline, disable updates.

[Sophist-UK]

There are actually several longstanding issues about cache invalidation.

Considering that this plugin is authored by the developers of Wordpress, you might think that support would be somewhat better.

[dima-stefantsov]

Unlike other plugins like WPFC, WPSC actually works. In many cases. This is good enough already.
Editing it inline will work for few things that need to be fixed for my case.

If you have advice what caching plugin will work at least as good as WPSC, but also have good code, I'd love to hear it.

[peterbowey]

I have also experienced this front page cache loss / drop on different sites for a while via WPFC. If the site is accessed enough the cache logic seems to hold, then drops later. It has bearing on a static front page along with cache logic firing a drop. Still a great tool in WPFC

[marcomarsala]

Seems enabling direct cache files for home page (/) solves the issue.

But another different issue arises: #25558

[javorszky]

Ran into this bug myself as well. The debug log tells me that the supercache is not found for the home page, but prior to refreshing the page, I'm staring at the file on the FTP server (refreshed, in case it was an FTP cache issue).

So something clears the file before WPSC wants to look for it.

Other pages cache normally from the few I randomly checked.

Currently trying to reproduce this on a local site. I'll post findings if I have news.

[donnchawp]

@javorszky - give the code here on master a spin. I'm running it on my blogs and I fixed and merged the issue with the front page in Automattic/wp-super-cache#175.

[javorszky]

@donnchawp not sure that applies, as the front page is latest posts, not static page, and I'm not updating any content between refreshes / cache clears.

[javorszky]

Managed to reproduce the bug locally. Tried it with both master and 1.4.9 on wp.org repo (btw you don't have a 1.4.9 version tagged on Github).

It's caused by the slash check. With the slash check on, the front page would never stay in cache. With it off, front page is cached as well.

$wp_cache_slash_check = 1; //Added by WP-Cache Manager is causing the headache.

[javorszky]

Though I may have spoken too soon... sigh, further investigation is needed, bear with me. I might be running into different issues.

[javorszky]

Okay, I'm not going mad. If slash check is set to 1, it works. However running a cache check resets it to be 0.

[javorszky]

Which... is because it looks at the permalink structure, whether the last character of the permalink is a slash or not. Which causes problems on the index page, as that's, from what I can tell, will always be /, so the last character of that uri is guaranteed to be /.

Even if the permalink structure is set to be http://sitename.com/%post_id% (note the missing slash at the end of it).

In the majority of sites I've seen that's not a problem because the request uri and the home uri are the same.

Unless, of course, the site is in a subdirectory, so the siteurl has a subdir on, the home doesn't, which means that in the code right here

1. home uri and request uri are not the same, so this part evaluates to false
2. slash check is 0 because the last character of the permalink structure is not a /, so the second part evaluates to false
3. slash check is 0, but the last character of the uri is actually a /, so this is false too

Which means that the home page is guaranteed to drop the cache every time.

[marcomarsala]

The bug happens even if the site is in the root directory. Il 21/02/2017 00:44, Gabor Javorszky ha scritto: Which... is because it looks at the permalink structure, whether the last character of the permalink is a slash or not. Which causes problems on the index page, as that's, from what I can tell, will always be /, so the last character of that uri is guaranteed to be /. Even if the permalink structure is set to be http://sitename.com/%post_id% (note the missing slash at the end of it). In the majority of sites I've seen that's not a problem because the request uri and the home uri are the same. Unless, of course, the site is in a subdirectory, so the siteurl has a subdir on, the home doesn't, which means that in the code right here<https://github.com/Automattic/wp-super-cache/blob/master/wp-cache-phase1.php#L210> 1. home uri and request uri are not the same, so this part evaluates to false 2. slash check is 0 because the last character of the permalink structure is not a /, so the second part evaluates to false 3. slash check is 0, but the last character of the uri is actually a /, so this is false too — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#25566>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFGhVpFqy6GVuq-pqi1Ky4cC8MR-qkh8ks5reiV5gaJpZM4KCbxI>.

[talgalili]

Could this issue be related to this:
#25563
?

[JJJ]

Unless I'm misunderstanding, I can't see any good that would come from slashed/unslashed URLs being treated uniquely, and the software should be smart enough to guess this based on environment variables without user intervention.

At a glance, the current slash/no-slash logic seems overly complex.

Can we run the requested URL through user_trailingslashit(), or just always use the unslashed version of the URL everywhere by passing it through untrailingslashit()?