Purging Memcached on DreamPress

vps

#1

We just had a run-around trying to get CSS edits to propagate on a DreamPress site with Memcached. The old version of the CSS file kept showing up in the web browser view (tried numerous browsers on different computers to rule out browser caching).

Purging the Varnish cache and putting Cloudflare into Development Mode didn’t help. There were no other caching plugins except the Dreamhost-installed object-cache.php

In the end we rebooted the VPS and that cleared it.

We think it could have been Memcached that was the culprit. Does this cache CSS files? If so, how to we flush them from its cache?


#2

Memcahed doesn’t cache CSS, but Varnish, Cloudflare, and Google Pagespeed do.

Was this CSS a .css file or something else?

What other plugins were you running?


#3

Yes, it was a .css file.

Pagespeed is not active on this domain.

Our previous big suspect was BWP Minify as this is obviously rewriting the CSS. Purging its cache seemed to make no difference so we deactivated it then removed it.

We had the same problem again today - the new CSS file present and verifiable via ftp, but the old CSS file still in effect when browsing the site. We purged the Varnish cache several times and viewed the site at resolve-to.www.siteurl to rule out Cloudflare. Viewing the CSS file directly in the web browser (again via resolve-to) still showed the cached old version. After an hour or so, the new CSS finally showed up but we can’t think where the old CSS had been cached during that time.

Here’s a list of the plugins. The only one we can see that might touch the CSS is WP Accessibility, but I gather that modifies the DOM using Javascript, so it shouldn’t have had any effect when we viewed the CSS file in the browser.

Akismet
BackupBuddy
BE Subpages Widget
Broken Link Checker (set to run only below server load 0.3)
BWP Google XML Sitemaps
CMS Tree Page View
Dynamic Widgets
Editor Theme Edit
Genesis eNews Extended
Genesis Featured Widget Amplified
Genesis Latest Tweets
Genesis Layout Extras
Genesis Shortcodes
Genesis Simple Edits
Genesis Simple Hooks
Gravity Forms
Hotfix
Image Widget
InfiniteWP - Client
Installer
Login LockDown
MailChimp Campaign Archive
NextGEN Gallery by Photocrati
NextGen NivoSlider
Page Excerpt
Page Excerpt Widget
PS Auto Sitemap
Really Simple Twitter Feed Widget
Redirection
Relevanssi
Simple Social Icons
Symple Shortcodes
TablePress
Theme-Check
TinyMCE Advanced
Types - Complete Solution for Custom Fields and Types
Varnish HTTP Purge
Video User Manuals
WP-Piwik
WP Accessibility
WP Views


#4

BWP Minify does create a cache…

What css file are you editing?


#5

Yes, we’d removed BWP Minify previously to rule it out as the culprit, although it’s rather persistent and we had to reboot to make the default CSS start loading instead of BWP Minify’s cached version.

Anyway, this thread’s getting a bit too old and the trail has gone cold. I’m now starting to doubt that we’d really ruled out browser caching. I’ll start a new thread if we have the problem again, thanks for looking at it.


#6

Next time, if you see it, instead of a reboot, try naming the object-cache.php file in wp-content to .old - see if that works. That will be the fastest way to see if it’s memcached or not :slight_smile:


#7

Thanks for that timely hint, I’ve had to rename it this morning on another site to deal with another issue: Inability to get to the WordPress Dashboard following the 3.8 update. Any attempt to load a dashboard page just gives the “No Update Required” screen gets stuck.

Renaming object-cache.php gets around the problem, but it reappears as soon as I restore the name.

How do I flush the cache?


#8

You don’t have access. Can you open a ticket for this and ask them to restart Memcached? I’ll ping the tech who’s working on the deployment to see if he can see why this happens!

I THINK it’s part of a known bug in WP, which is fixed going forward past 3.8, but would still be a weird gaff on the 3.7.1 -> 3.8 upgrade.


#9

Thanks. I opened a ticket yesterday.

It only seems to have affected one of a dozen sites.


#10

I don’t see any sites on DreamPress associated with the email you’re using in the forums, so I can’t go check for myself. Did you previously have a custom PHP.ini setup for your site?

Oh! If you know command line, try renaming that object file back and type ‘wp object flush’

That should force WP to flush it.


#11

The support ticket is #6080515 so you can check the history.

We haven’t had a custom php.ini on that site, but I notice that there’s an extra line in the phprc file that differs from our other Dreampress sites. The other Dreampress sites just have this line:
extension=xcache.so

… but the problem site also has this line:
extension=memcache.so


#12

Well that shouldn’t be there! However you had an even more fun issue.

CloudFlare cached that page. THAT’S why you kept seeing it.

I flushed the cache, and set it up so WP knows that you’re using CloudFlare (See http://wiki.dreamhost.com/DreamPress#Can_I_use_CloudFlare_and_Varnish_together.3F )

You should be good to go now.


#13

Thanks. Can I suggest you add that wiki link to the Dreamhost Panel domain config screen next to the Cloudflare checkbox?


#14

Suggestion taken and put in our to-do list :slight_smile: