Sometimes blank white page

[Saboteur777]

If enabled (no ubercache, only regular cache, 86400 second) sometimes only blank white page is generated. After a refresh everything is fine, the requested page is loaded successfully.

Retour is enabled and used on the site, but not just the "retoured" content don't load properly but even paginated channel (e.g. 3rd page (/channel/p3)) won't work 100%.

[webremote]

I think it's the same as #22 / #27

i'm currently setting up a development environment with all those plugins to test against the htmlcache. leaving this open for now, hopefully soon with a fix!

[Saboteur777]

Hey, happy new year! :)

Any update on this? Waiting for the fix eagerly ;)

[webremote]

Thank you very much, best wishes yourself!!

I've been testing quite a few hours now, but the progress is terribly slow 👎

The develop branch has a few extra checks to see if the page is empty or if it's a redirect and I was working on the CSRF issue.

Checking if it's a redirect doesn't always seem to work due to incorrect headers (200 instead of 301/2), so it doesn't always know what to do..

Re-generating the correct cookie/token outside of Yii/Craft is harder to achieve then I thought. the amount of "pulling the hear out of my head"-moments has been too high compared to the actual progress 😛

[Saboteur777]

That doesn't sound great... 😿 What do you think will you find a solution for this?

[akukral]

I'm havin this same issue. I would love to get it worked out, as the plugin works incredibly well otherwise.

[davidhellmann]

Same Issue here, any progress? :/

[maxwellhibbert]

Me too. Any luck on a fix?

[maxwellhibbert]

I remember a plugin for EE that was similar to this. It relied on mod_rewrite to show the cached html file if it existed. Not sure if that's an option here, but that method worked without issue for me with EE.

[thisisjamessmith]

Same problem here. @maxwellhibbert Is there anything that makes you think the server rewrite method would fix this issue? I wouldn't expect it to help much, though I agree that it's a nicer way of doing it, as you can entirely bypass PHP. (Also tied into such a change would be @brettgullan's fork that creates the cache files in a nested directory format that matches the requested URIs (https://github.com/brettgullan/htmlcache). The EE add-ons are Mustash and CE Cache which both use that technique I believe (Mustash certainly does).

But since @Saboteur777 suggests that the problem exists without 'ubercache' switched on, then I'm at a loss to figure out what's going on. Maybe something to do with the output buffering (added by this pull request: #20) flushing too early? Who knows, it's really hard to debug since it doesn't happen all the time!

[tsawitzki]

+1 here

[jpoiri]

You can fix the issue by replacing the code for the Htmlcache_HtmlcacheService->checkForCacheFile function with the following:

public function checkForCacheFile()
{
    if (!$this->canCreateCacheFile()) {
        return;
    }

    $file = $this->getCacheFileName();
    if (file_exists($file)) {
        if (\htmlcache_checkCache(false)) {
			return craft()->end();
		}
    }
    // Turn output buffering on
    else {
        ob_start();
    }
}`

The problem occurs because the craft->end() function is called regardless if the htmlcache->checkCache() returns true or false. If the cache expires, the htmlcache->checkCache returns false so at this point we want to regenerate the cache file instead of killing craft request.