DreamPress Varnish caching conflict with plug-ins

#1

Hi,

Since upgrading to DreamPress, Varnish caching has not worked due to a conflict with 2 of my plug-ins, Easy Digital Downloads (EDD) and Wordfence. My understanding is that these are widely used plug-ins.

I reported to DreamHost support previously, and they said they would work with EDD to find a solution.

I followed up with EDD yesterday, and the main author said: “I worked with Mika today to work it all out. They are updating some of their server configs but it should be good to go as soon as they deploy their update.”

Can you please let me know when this update has been made? I am eager to see how DreamPress performs with the caching working, especially since it’s been almost a month since I upgraded to DreamPress.

FYI, I was told by DH that Varnish is not currently compatible with Wordfence, which I find surprising/disappointing since Wordfence worked fine with W3 Total Cache and since it appears to be a very popular plug-in.

Thanks,
Tyler

#2

Our internal ticket has a note to tell you ASAP once we have a solution for EDD. We ARE working, directly, with the plugin author and yes, he gave us A possible fix for our severs, though we’re still testing to make sure it’s absolutely right before we deploy. I mean, hi, you’d be really pissed if we didn’t test and broke your site :slight_smile:

The technical reason this is not a super fast fix is that it’s a complicated problem. EDD sets a cookie on every page load, regardless of if you have any content in your shopping cart or not. One option, the one Pippin suggested, is to change our config to detect the cookie and, if the cart is empty, ignore it. Another, the one WE suggested back, was to not set the cookie unless there’s something in the cart :slight_smile: But. We want to make sure that even if we do the server config, we don’t do it in a way that cripples your shopping cart. And generally we don’t like to test this stuff on a customer’s live site unless we have to!

Keep in mind: As soon as someone adds an item to the shopping cart, Varnish will stop caching. So even when we do resolve this, you’re never going to have the zippiest experience for shoppers when you use caching with shopping carts :frowning:

WordFence outright sets your site as NOCACHE which Varnish reads and says “Oh, you don’t want to cache? Okay, I won’t cache.” The reason W3TC works with it is that it’s making a static file of your content, which is not the same kind of cache. There’s absolutely nothing we could do to fix that one :frowning:

#3

Ok, thanks Mika! I just thought I’d stay on top of this because DreamHost support (Chris J.) told me this past Tuesday it could “take months,” which really is too long to go without caching (or EDD). Sounds like you guys are close! :slight_smile:

My site is actually pre-launch, so if it might be more efficient to test on my site sooner, just let me know what I can do. Otherwise, please keep me updated! I would like to engage some prospective clients after the holidays, so if it is all possible to get this fixed asap, that would be ideal so my website speed makes a good impression.

Regarding Wordfence, they told me:
"The only time we send do-not-cache headers is when:

  1. We send a 503 message saying access temporarily limited. (Happens when someone gets blocked)
  2. For a specific URL which is used to log human visits. This URL starts with /wp-admin/admin-ajax.php.
  3. When we serve the “You have been locked out” page if a user is locked out from login.
    All other pages will behave as per normal."

So, it appears there’s a disagreement / miscommunication between Wordfence and DreamPress. Any further thoughts on this? EDD is more important to me than Wordfence, though, so please keep that higher priority. I do like how Wordfence is a free and popular WP security plug-in, but if you have any other suggestions for security plug-ins, that would be helpful.

Finally, I’ve been having a separate issue this past week. The timing seems to have started around the WP 3.8 upgrade. In short, my WP panel has been buggy, with multiple plug-ins not correctly activating/de-activating and me not being able to change their key settings. WP will say a message as if my change worked properly, but plug-ins will not have changed. Sometimes persistence or activating/de-activating in different order will do the trick. I never had any problems like this prior to a week ago.

This is a real issue, since I use plug-ins for important things like backup and restricted access, and I’m no longer able to get them working properly. I’ve tried flushing the Varnish cache, re-installing WP 3.8, switching themes, and deactivating all plug-ins (I even deleted Wordfence). I have not been able to isolate or fix the problem.

One WP expert suggested to “check your Varnish VCL script for possible issues.” Can DreamPress help me with that?

Thanks!
Tyler

#4

We’re ‘close’ but honestly this isn’t a fast fix. I told Chris to tell you months because I felt it was more important to be realistic to you than give you false hope. If we have a breakthrough I will be pleasantly delighted. I really don’t want you to think we’re >this< close because we’re not. We know what’s wrong, we know ‘how’ to fix it, but we don’t have a way to apply it without breaking other things yet.

WordFence, when I installed it on a plain vanilla DreamPress instance, sent no-cache on every page load if the user was logged out. So … I don’t know how they tested that, but I can only tell you what I saw. :confused: I went and installed it, again, on a site with no other plugins and every logged out user got NoCache. This may not be by intent, it may be an accidentally clash with DreamPress, but since I got that right away when I installed it, I presumed it was by intent. They’re welcome to reach out to us if they want to test (I can set them up with a test box) at mika.epstein at dreamhost.com

The other issue is probably memcached (since you’re using our bog standard Varnish, and Varnish is disabled on wp-admin pages). I ran a memcached flush but I noticed you have W3TC installed. You may want to deactivate that OR turn off/delete our caching plugins. In your wp-content folder is a file named object-cache.php and that may need to be removed (or renamed object-cache.php.old) to prevent clashes like that for as long as you’re using W3TC.

#5

Thanks for the updates regarding the EDD and Wordfence conflicts. I will pass on your info to the Wordfence people.

Regarding the WP admin panel issue, it appears flushing the memcached worked! Note: I only re-activated W3 Total Cache a few days ago, so I do not think that was causing the issue (so, must have been the WP 3.8 upgrade?). I have W3 activated now, and everything seems to be working fine.

Honestly, I wish I came to you first, as I could have avoided a week’s worth of time and headache trying to get WP working properly again, including seeking support with my Headway theme framework, WordPress forums, and playing around with countless plug-ins and settings. This was in addition to multiple support e-mails with DreamPress, none of which included the memcaching solution (I was mostly told the issue probably had to do with my plug-ins or my theme). As feedback, please pass along this memcaching solution / your expertise to the DreamPress support staff.

#6

Well memcache was something we just sorted out as being a problem last week, so I can’t blame the support guys for not knowing :slight_smile: I only explained it to them … Wednesday? So a week ago, really. They now know about it, and have directions on how to diagnose, fix, and kick in the pants :slight_smile:

#7

Hi Mika – hope you enjoyed the holidays, and happy new year!

Any update or breakthroughs by chance on the EDD-DreamPress conflict?

Thanks.

#8

Guess which guys were out for the holidays?

No updates yet. The fix EDD gave us is ‘backwards’ to our setup. It’s one they use with another host, who ignore all cookies and allows some. We allow ALL cookies and ignore some. So for us, we have to reverse the code logic. Sounds easy, right? Not so much, since the code to do that requires some changes to our backend, and we have to do it in a way that doesn’t accidentally block the code.

That said, EDD said they’re working to get rid of PHPSESSIONS calls when the cart is empty, and when that happens, our issue would magically be resolved.

#9

Hi there,

I did some testing this evening and thought I’d reproduced the issue but turns out I was looking at the Request headers and not the response headers.

On a plain vanilla wordpress 3.8.1 brand new with new database I installed Wordfence using the standard add-new, search and install option. I activated it with defaults. Checked and there are no headers being sent that include no-cache. Here’s a screenshot of my Chrome debug data showing the request for test1.com (my test server as set in my hosts file) home page as sent by a logged out user.

http://postimg.org/image/ki3zddp2h/

Based on the response headers this looks like it would play very nicely with Varnish.

Please note that the source of the home page includes some javascript that points to the ajax handler and the src URL looks like this:

src="http://test1.com/wp-admin/admin-ajax.php?action=wordfence_logHuman...with some params.

There’s a session ID in there that changes and that request DOES return no-cache headers. Is this perhaps what you were referring to? To be clear, this is not the page itself, but it’s a component on every publicly visible page. This code is included in all pages and posts if the “live traffic” option for Wordfence is enabled and it is enabled by default.

Does that help?

#10

Hi,

Thanks for your post.

I’ve actually switched over WP Engine, which does not have a caching conflict with the EDD plug-in. They also have their own rigorous security systems so need for Wordfence any more (in fact I don’t believe they would allow it).