Cidram: Endurance Page Cache

Created on 19 Feb 2018  路  17Comments  路  Source: CIDRAM/CIDRAM

Please use this template when reporting bugs, problems, issues, etc.

Server information.

CIDRAM version used (if known, please also include the exact commit hash).

1.4.1

Signatures version (if known).

PHP version installed (<?php echo phpversion(); ?>).

7.1.4

Issue

Fatal Error on website: https://loschaos.com/pics/Endurance-Conflict2.jpg

Expected behavior

Issue with fatal error on new site

Actual behavior

Hi - Starting up a new website and the host has caching as a part of the plan. After running for a day I got the fatal error shown in the screenshot. At the point where you see the screenshot if I tried to access the site the block for China would display for me, along with the error code below the CIDRAM block banner. I am not in China - I am in the US.

I disabled the server cache (endurance-page-cache) and all started functioning normally again.

Is there an issue with CIDRAM and endurance which I believe is Varnish caching?

(I have long used W3 Total Cache with CIDRAM with no issues)

I am busy building the site right now so I have not messed with it again, but if this server caching will speed up the site I will want to investigate it again in the future.

Anyway, wanted to drop in here and say hi! Will be strange not having the forums for support. This is nice鈥揹on't get me wrong鈥搄ust does not have that homey feel. Will you be setting up a forum elsewhere?

Cheers!

Bug Won't Fix Compatibility
Source
picture 100percentlunarboy

All 17 comments

Is there an issue with CIDRAM and endurance which I believe is Varnish caching?

I'd actually never heard of, seen, nor worked with Endurance before, prior to it being mentioned here, so I'm not familiar with its code, but based on what you've written, and on the screenshot you've included, this definitely looks like a compatibility issue between CIDRAM and the caching mechanisms used to me, so for now, until I've looked into this further, I'm going to go with a yes.

In particular, in regards to the screenshot:

At the point where you see the screenshot if I tried to access the site the block for China would display for me, along with the error code below the CIDRAM block banner. I am not in China - I am in the US.

It looks like the IP blocked in the screenshot is 123.126.113.135, which belongs to Sogou, a Chinese search engine (a little different, but similar to Baidu), and the original request that triggered the block (i.e., what was cached; not your own request) was sent from their crawler. So, even if we were to humour the idea of you connecting via China, it would still be highly unlikely that you'd be connecting via the same IPs used by their crawler, so definitely, what we're seeing in the screenshot is a request from someone/something else (their crawler, in this case) being blocked, cached, and then subsequently served up to someone else (you, in this case), which we obviously don't want to be happening.

I'll track down a copy of Endurance and take a closer look at its code tonight or tomorrow, to get a feel for how it works and to try to figure out exactly what's happened here, to see what can be done about this issue.

I am busy building the site right now so I have not messed with it again, but if this server caching will speed up the site I will want to investigate it again in the future.

For sure, and makes sense. :-)

Anyway, wanted to drop in here and say hi! Will be strange not having the forums for support. This is nice鈥揹on't get me wrong鈥搄ust does not have that homey feel. Will you be setting up a forum elsewhere?

Possibly. No immediate plans for it, but I know what you mean about the feel. Haven't quite planned that far ahead yet, but we'll see what happens, I guess. In any case, good to see you here and thanks for reporting the issue. :-)

Maikuolan picture Maikuolan on 19 Feb 2018

Issue / bug reporting should still and always happen where the development happens, and that is here ;-)

DanielRuf picture DanielRuf on 19 Feb 2018
👍1

Quick question @100percentlunarboy: Are you on Bluehost, by any chance? Just doing some more investigating of the issue here, and finding quite a lot of issues, not the same, but similar, posted elsewhere, relating to the Endurance plugin, most of them posted by Bluehost customers (just wanting to make sure I'm not barking up the wrong tree if I follow up on these leads). Cheers. :-)

References:

Maikuolan picture Maikuolan on 20 Feb 2018

Looks like a bug in Endurance cache. I would label it as wontfix

DanielRuf picture DanielRuf on 20 Feb 2018

Hi. I am on Hostgator. They mention this when talking about their system: "All Cloud Sites packages come with a distributed Varnish caching solution so that your static content loads quickly and frees your compute resources to focus on loading the dynamic content." It uses "endurance-page-cache.php" in a the following directory directory: /wp-content/mu-plugins If you enable it in your server control panel it adds these lines to the .htaccess:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^/wp-content/endurance-page-cache/ - [L]
    RewriteCond %{REQUEST_METHOD} !POST
    RewriteCond %{QUERY_STRING} !.*=.*
    RewriteCond %{HTTP_COOKIE} !(wordpress_test_cookie|comment_author|wp\-postpass|wordpress_logged_in|wptouch_switch_toggle|wp_woocommerce_session_) [NC]
    RewriteCond %{DOCUMENT_ROOT}/wp-content/endurance-page-cache/$1/_index.html -f
    RewriteRule ^(.*)$ /wp-content/endurance-page-cache/$1/_index.html [L]
</IfModule>

One thing I was wondering about, or at least is a red flag for me, is running varnish on a SSL server. I ran across this article: http://davidbu.ch/mann/blog/2015-03-20/varnish-and-https-apache.html

I wonder if this is part of the problem? The screenshot of the error was from a site that has a ssl cert installed. I will try enabling the cache on another site I have that is still waiting for the cert to get installed and see if it errors out too.

100percentlunarboy picture 100percentlunarboy on 20 Feb 2018

One thing I was wondering about, or at least is a red flag for me, is running varnish on a SSL server. I ran across this article: http://davidbu.ch/mann/blog/2015-03-20/varnish-and-https-apache.html

I don't think it would necessarily make any difference for CIDRAM, whether you were or weren't using SSL. I am curious though, from what I've seen thus far of Varnish/Endurance, how it'd deal with caching for pages after modifying content (e.g., if you edit a post at your WordPress site, how long it'd be before the edit is reflected in the cache, and whether the cache actually expires at all)? I don't have enough experience with it to say there'd definitely be any problems there, but anyhow, it's a question that comes to mind.

At least, judging by the rewrite rules cited above, I don't think it'd serve any cached pages from logged in users, the admin dashboard, form post requests and so on (would be a very big security problem if it did), so aside from the compatibility problem with CIDRAM, and possibly the problem I mentioned above regarding modified page content, it should be reasonably problem-free to use the plugin, I imagine.

Anyhow, no luck coming up with any viable solutions yet. Based on the way that Varnish/Endurance pulls and writes to its cache, there's definitely a compatibility issue between it and CIDRAM there, and I think there'd need to be changes made to Varnish/Endurance in order to fix it. As much as I don't like doing so, I might need to mark this as wontfix, I think; Not sure how we could fix it from the CIDRAM end. :-/

If we do mark this issue as wontfix, I'll also add a note to the documentation about incompatibility between CIDRAM and Varnish/Endurance. Might ask a few people I know first though, before marking and closing this, in case any of them have any ideas we haven't thought of yet.

Maikuolan picture Maikuolan on 23 Feb 2018

Hiya.

Since my one issue I posted here I have not seen it happen again. Both of the sites I have it running on are now under SSL and nothing yet.

Have you checked with the developer of endurance cache? They are on Github too and it looks like they are pretty responsive to questions:

https://github.com/bluehost/endurance-page-cache

What I am wondering is if its a combination of Varnish and endurance cache? Varnish, as I understand it, is server-side caching. In the HostGator control panel, I have an option to turn it on/off and set the expiration. That's the only settings for that. Endurance is a plugin HostGator installs. Endurance has the following options: Assets Only - Level 1, Normal (level 2), Advanced levels 3 and 4. Nowhere did I find any descriptions of the functions.

Could it be an issue when the two are combined? Not one or the other?

Would you consider it sake to use CIDRAM with Varnish and no Endurance cache?

If you think it's a big security issue I will probably just disable it. Thought it would be valuable to report it to you as this endurance cache is installed and activated by default by Bluehost and Hostgator (cloud hosting).

Thanks!

100percentlunarboy picture 100percentlunarboy on 23 Feb 2018

I think this is the script in mention, along the line 370 that caused error:
https://github.com/bluehost/endurance-page-cache/blob/master/endurance-page-cache.php#L370

Not sure why it doesn't work, though.

dev-101 picture dev-101 on 23 Feb 2018

Oh, got me by a minute :)

Anyway, you should stay away from EIG hosting, a lot of people have a lot of issues with all of their companies they've bought. Just search for some experiences, reviews etc. Find a proper hosting ;)

dev-101 picture dev-101 on 23 Feb 2018

I have had any problems with my web hosting.

100percentlunarboy picture 100percentlunarboy on 23 Feb 2018

I think this is the script in mention, along the line 370 that caused error:

Yep. Same issue has been reported to the dev by another user via https://github.com/bluehost/endurance-page-cache/issues/31 (Dec 6, 2017; no response yet).

My immediate thought when I saw the error was is_user_logged_in() being called too early in the plugin execution, being based in /mu_plugins and all that (common problem/oversight with plugins loaded early like that), but it seems the specific call that causes the fatal error is tied to the shutdown action hook, which usually executes when everything has finished already and WordPress is getting ready to end processing and flush output, so it should already be defined by that point in the execution; unless the call to the cache itself somehow bypasses loading parts of the WordPress core that would normally be loaded by that point, such as the function that PHP is complaining about not being defined (if I was the dev for Endurance, and assuming he hasn't already done so, that's what I'd be checking up on next, I think).

Maikuolan picture Maikuolan on 23 Feb 2018

PS, kind of off-topic, and doesn't help with the issue at hand, but after googling a bit more about Endurance, to (mostly unsuccessfully) try to find out more information about why there isn't a single mention of it at all anywhere in the official WordPress plugins repository, and more information to try to understand some of the very negative comments I saw on the Endurance issues page, I eventually stumbled across these; just sharing them here because they might be of interest to those participating in the current issue discussion:

Disclaimer (legal + for the benefit of possible future readers): I'm merely sharing some links here of things I found while searching on Google. I haven't written any of the content that the links point to, I'm not responsible for said content, I don't profess the veracity of said content, and I'm not implying anything about anyone nor anything by sharing them, nor suggesting any particular action of any kind.

Maikuolan picture Maikuolan on 23 Feb 2018

I agree that its odd that there is no documentation on endurance cache script when you consider it must be installed on thousands of sites as its auto installed. I have decided to disable it for that reason alone. Very strange indeed.

I do feel, however, that a lot of issues people have in the dark arts of web hosts is directly related to how much time they want to dedicate to making the best website they can. It takes a lot of effort. If you place a site on a shared host and don't optimize it and it will be slow. Take the same website and run it through Google pagespeed insights as many times as necessary to get rid of as many issues slowing down your site as possible, and then load a "good" caching program and a plugin to optimize all CSS and javascript, and run it through Insights again and you will have a fast website.

It took a lot of time to get my site to this point:

https://loschaos.com/pics/pagespeed.jpg

Not all scores for individual posts score this well but the site is fast and responsive. For this particular site there is not even any cache program running - just the plugin called auto-optimize, a script that "aggregate, minify and cache scripts and styles, injects CSS in the page head by default (but can also defer), moves and defers scripts to the footer and minifies HTML." I think in the case of this website the theme is so well coded that it runs fast. It's my belief that people that experience tons of problems with a site on a shared host and do want to take the time and effort to fix them through their own efforts should be on managed hosting.

Anyway, I digress.

Back to my theme that websites take a lot of work to maintain. If you do not review your security logs, keep your software up-to-date, and make it your goal to make security a priority there is a good chance you will be hacked. I burn through a lot of time doing this and its why I found SpambotSecurity and eventually CIDRAM.

I value the time and effort you guys put in to maintain CIDRAM. That's why I don't bring up anything without first researching the problem at hand. For example, I had already read all the articles linked to in this series.

I brought up this issue because of my belief that doing so could help other people.

100percentlunarboy picture 100percentlunarboy on 23 Feb 2018
👍1

Take the same website and run it through Google pagespeed insights as many times as necessary to get rid of as many issues slowing down your site as possible, and then load a "good" caching program and a plugin to optimize all CSS and javascript, and run it through Insights again and you will have a fast website.

This is often not enough. I often do WPO at work.

DanielRuf picture DanielRuf on 23 Feb 2018
👍1

I agree that its odd that there is no documentation on endurance cache script when you consider it must be installed on thousands of sites as its auto installed. I have decided to disable it for that reason alone. Very strange indeed.

Yeah.. It definitely doesn't inspire much trust towards it. I'm a fan of documenting packages, work and so on regardless, but in particular, I think it's important to have documentation available for a thing for users to access if it's a thing that's going to be installed automatically by a hosting provider. Even if the thing is generally benign, possibly useful, and done with good intentions, not having documentation for it doesn't look good for it nor for those installing it automatically. :-/

(PS, if documentation for it does actually exist, and I've just failed to find it, and someone reading this knows where to find it, pointing it out to us would be helpful).

Back to my theme that websites take a lot of work to maintain. If you do not review your security logs, keep your software up-to-date, and make it your goal to make security a priority there is a good chance you will be hacked.

Definitely. :-)

I value the time and effort you guys put in to maintain CIDRAM.

..and happy to hear it. :-)

I brought up this issue because of my belief that doing so could help other people.

Definitely, bringing these issues up is always helpful, and I'm happy that you've done so. Although I suspect it'll end up being a wontfix, I'm hoping I might hear some ideas from some people I've asked about this elsewhere, so either way, I think we should keep this open for at least another day or so. In any case though, it's good to know about these problems, and if there doesn't turn out to be an easy fix, like I mentioned before, I'll still add a note about it to the documentation, so the issue here remains constructive regardless.

Maikuolan picture Maikuolan on 23 Feb 2018

Also, tagging @MikeHansenMe in case he wants to share any input regarding the issue at hand.

Maikuolan picture Maikuolan on 23 Feb 2018

No luck with attempting to seek advice from elsewhere, unfortunately.

Documentation has been updated to reflect the discovered incompatibility.

Marking as Won't Fix and closing.

Maikuolan picture Maikuolan on 26 Feb 2018
Was this page helpful?
0 / 5 - 0 ratings

Related issues

eurobank picture eurobank  路  7Comments
Dibbyo456 picture Dibbyo456  路  7Comments
Dibbyo456 picture Dibbyo456  路  6Comments
eurobank picture eurobank  路  8Comments
Maikuolan picture Maikuolan  路  5Comments