Caching shopping cart using SSL

[Ipstenu]

Shortish version. If I activate this for my multisite, everything works except the shopping cart. That gets all weird and will show cached data, when it really shouldn't.

The whole site is https. Shouldn't that not be getting cached?

[tollmanz]

Thanks for checking out this object cache!

https will not affect the object cache. The object cache should work the same for https and http.

Can you tell me more about the issue? Which shopping cart are you using?

[Ipstenu]

Easy Digital Downloads.

When I went to the site with cache on, the cart said I had an item already in the cart (when I didn't). If I clicked on the cart to see what I had, it listed two books (nope, hadn't added anything).

When some people clicked add to cart it just went the the cart page and then said that the cart was empty.

So the problem is ... I think I don't actually WANT it to cache the cart stuff and it is. Actually scratch that, I KNOW I don't want to catch the cart stuff. I don't want shipping info and credit cards cached.

[tollmanz]

Yikes! This is really bad.

I can look at things from the object cache perspective; however, I really do not understand how the object cache would cause the issue unless the object cache is being used incorrectly. I will take a look and am also looping in @pippinsplugins so he is at least aware of this.

[tollmanz]

Have you removed this object cache for now? Just wondering if I should even try reproducing on your site.

[pippinsplugins]

@Ipstenu Are you using DB sessions or PHP sessions? Downloads > Tools > System Info and look for "PHP Sessions".

[tollmanz]

I took a look at EDD and there is very little caching going on, so I am surprised to hear that EDD + this object cache resulted in this bug.

Are you using a page cache too @Ipstenu?

[Ipstenu]

I removed the object cache. Since I'm in and out of the house this week, it seemed sensible to not break the store ;)

The only other cache I have running is Batcache and Pagespeed. Pagespeed is just set to compress the CSS/JS and images right now.

https://wordpress.org/plugins/batcache/

@pippinsplugins - There's no Downloads > Tools on 2.1.9 o.O However I think I'm using PHP Sessions, since I never put in this:

define( 'EDD_USE_PHP_SESSIONS', false );

I can if you'd like me to retest, now that I know how to reproduce the bug.

Tried that, as soon as I turn on the object-cache.php it happens again. FWIW, it happened with memcached redux too. I assumed it was something I did weird the first time and didn't have the time to debug.

[tollmanz]

Thanks @Ipstenu! My guess is that the page cache is what is causing issues. If one user added items to her cart and caused a page to generate with her items, it would poison the cache with her cart. I'm pretty sure batcache does not have special rules in place for EDD pages.

To help figure this out, can you see if you can recreate the issue without batcache?

[Ipstenu]

Tested. Confirmed. Same problem happens without Batcache active (it's an advanced-cache.php file, so I did the ol' rename thing). As soon as I turn on Object Cache, it shows me someone else's cart :(

[tollmanz]

Boo...thanks for checking. I'll have to try to recreate this myself to take a closer look. I'm not really sure at all what could be happening.

[Ipstenu]

Sure, let me know what server / php specs you need to know :)

[pippinsplugins]

@Ipstenu Is this on store.ipstenu?

[Ipstenu]

store.halfelf.org :) It's an alias for store.ipstenu.org though if that matters.

[webaware]

@Ipstenu (butting in here): can you be sure that no other caching is affecting this? e.g. fragment caching in your theme?

[Ipstenu]

To the best of my knowledge, StudioPress themes don't come with caching. I'm using Genesis as a parent theme.

PageSpeed has downstream caching, but that's disabled right now. Also it's ONLY doing images, css and js for https.

[webaware]

Actually, I heard that Genesis can support fragment caching, via W3 Total Cache at least. I know you're not running that, but I wouldn't rule out the theme here. Is it possible to try switching the shop to twentytwelve briefly to do a test?

I think the most likely scenario here, however, is crossover. Do you have other sites on this server that are using Memcache? If so, you need to set WP_CACHE_KEY_SALT in your wp-config.php files to ensure that each site stores things under their own unique keys. I usually go with something like this; add anything else you need to make it unique per site:

define('WP_CACHE_KEY_SALT', md5(DB_NAME . DB_HOST . $table_prefix));

(I guess $table_prefix isn't really needed for this drop-in, but I think it was for another drop-in so I've left it as part of my generic key salt in case I ever switch drop-ins for any reason)

FWIW, I can confirm that EDD + this drop-in works. I have it on a multisite and just ran through some tests, with no crossover. The theme used was the free Shop Front theme.

The fact that you get this problem both with this drop-in and with Memcached Redux says that it's not about the drop-in, it's about object caching and your config. I'd be surprised if it isn't as simple as the key salt.

[Ipstenu]

I have about 7 or 8 WP sites and other things on the same server. Two WP sites use this plugin. One is Multisite (including this Store) and one is not. The single site has been just fine as far as I can tell.

I put that code it but had the same issue, so I tried a different theme with the Salt in place. The cache 'held on' to the old theme. So yes, the cache isn't being invalidated, but it's not letting go when I swap themes. The CSS is getting flushed, so I know PageSpeed is behaving as I told it to, but I did all the usual tests with advanced-cache off and pagespeed off and TwentyFourteen and BOOM. Exact same thing :(

I did manage to dump the whole cache by restarting memcached and my nginx proxy (which btw isn't even running on https, it's only on for http, but better safe than sorry, right?) with both cache dropins off. From there, I reactivated 2014 without caching and it worked. Turned on caching, same error.

So yes, something's not letting go of caching, and I clearly have a conflict, but damn if I can see where.

[webaware]

Hmmm. It's starting to sound very much like problems with WP_Session; see this WooCommerce discussion for some background.

• Are you setting WP_SESSION_COOKIE anywhere? If so, are you including 'wp' in the cookie name?
• Could there be anything else messing with your cookies, like some nginx config? (I know, you said, but...)
• Do you have any other active plugins that define the class WP_Session?
• Do you have any other active plugins that write to options prefixed with _wp_session_?
• Are you doing anything interesting with table prefixes? (the object cache uses table prefix in its keys)
• Is this the primary blog or another blog on the multisite?

[if you're wondering why my interest, I'm also using EDD on multisite and plan to introduce object caching and nginx on that site soon, with some page caching, and later Pagespeed]

[Ipstenu]

1) Not that I know of.

2) I'm sure :) But again, not that I know of.

3) I did a grep and didn't find any

4) Same as 3, grep, nothing there.

5) Nope, table prefix is wp_

6) Subsite. It's a subdomain (store.ipstenu.org) mapped to a subdomain (store.halflelf.org) with an https plugin installed.

Active plugins:

• AdControl
• EDD
• EDD Purchase Gravatars
• EDD Stripe
• Genesis Simple Hooks
• Polldaddy
• WordPress HTTPS
• WP Menu Cart
• Yourls

Network Plugins:

• Pento's Auto Updates
• Akismet
• Comment Probation
• Fonticodes
• Impostercide
• Jetpack
• Jetpack Beta Tester
• Network Plugin Auidtor
• Oembed in Comments
• Register IPs
• Sitewide comment control
• New WPCOM smilies

All the Must Use plugins are small things to change favicons and such.

[webaware]

For about 30 seconds, I thought I was replicating your issue, until I realised I had two Midori windows open -- i.e. both had same session. I still can't replicate. Thought it might be WP Menu Cart but that's not it either. Sorry I can't help. Good luck tracking it down, it definitely looks like WP_Session somehow!

[tollmanz]

Hey @Ipstenu!

I'm looking into this now and cannot reproduce it.

I've been fixated on the shopping cart in the menu. It's not unheard of for menus to be cached as they can be a performance bottleneck. I have a few questions for you.

1. Is the problem that you are seeing only in the menu?
2. Is there any chance that the menu might be cached? This can be controlled outside the theme.

I'd be interested to know if the problem persists if you deactivate the WP Menu Cart plugin. I know that doing this might not be possible, but if you are wanting to try it, it would be great information.

I'm really just throwing darts in the dark at this point. It's really tough to get a sense of what is happening here.

[Ipstenu]

1. Nope, saw it in the cart itself too :(
2. I don't know. I'm not actively caching the html, beyond what Batcache disk but I tested it with Batcache off.

Yes, it happens without the menu plugin. In fact, I saw it without the menu at all.

At this point I think it's something with my server install of memcached :/

Sent from my phone

On Nov 28, 2014, at 5:38 PM, Zack Tollman notifications@github.com wrote:

Hey @Ipstenu!

I'm looking into this now and cannot reproduce it.

I've been fixated on the shopping cart in the menu. It's not unheard of for menus to be cached as they can be a performance bottleneck. I have a few questions for you.

Is the problem that you are seeing only in the menu? Is there any chance that the menu might be cached? This can be controlled outside the theme. I'd be interested to know if the problem persists if you deactivate the WP Menu Cart plugin. I know that doing this might not be possible, but if you are wanting to try it, it would be great information.

I'm really just throwing darts in the dark at this point. It's really tough to get a sense of what is happening here.

— Reply to this email directly or view it on GitHub.

[Ipstenu]

99.999% solved!

1) I had EDD_USE_PHP_SESSIONS defined in two places facepalm One was true, one was false. (It was in wp-config AND my mu-plugin for the store) 2) It's BatCache :(

I figured that out because once I fixed Item 1, the cross-polination issue stopped. But... The checkout page kept showing 0 while the menus were right. Buh? Then I flushed the cache (wp cache flush) and BOOM it all worked. Except the cache stuck again.

So doing the needful, I disabled advanced-cache, flushed my cache, and tried again. Everything works as expected.

Now it sucks I can't use it batcache with this, but clearly it was causing the cache to be held on too long.

whew Okay, so much happier now.

[tollmanz]

Awesome! Great work.

So, you can probably use this with batcache (or any full page cache) with the appropriate exceptions in place. Basically, you need to not cache any page that has a dynamic cart. Let's say that your checkout work flow includes a cart page and a checkout page, you should be able to run your full page cache on the rest of the site, but set up exceptions for those two pages. That said, I do not know much about EDD, so there may be more to the story.

In Batcache, if you find the line:

// Now that the defaults are set, you might want to use different settings under certain conditions.

you will see how to set up exceptions. You might be able to do something like:

// 1234 is the cart page ID
if ( 1234 === get_post_ID() ) {
    return;
}

This will keep the one page from being cached.

[webaware]

@Ipstenu Yay!

[webaware]

@Ipstenu this actually says to me that Batcache is not safe to use with WP_Sessions, period. Perhaps @pippinsplugins can confirm, or at least be aware. Mike Jolley specifically mentioned Batcache in his blog post about WP_Sessions, although it sounds like having _wp_ in the cookie name is meant to fix it. EDD does have _wp_ in its session cookie, and that's plainly not working here.

[Ipstenu]

Interestingly, it was only a problem with both Batcache and this plugin, which is weird to me. I ended up telling Batcache not to cache the store at all, to play it 'safe.'