WStringer2

Looks like I found the problem. We have a “staging” server that our content creators use that has a different URL from our public facing site. Even though they share the same WP database, the server URL difference is enough to cause a problem with Elasticache.

If an editor purges a post from the staging server, it is not purged from the public facing site. If they login to the public facing site and purge a single post from there, it successfully purges. A total purge works successfully from either server.

Great news…thanks!

Good morning,

Any word on this? Let me know if you’re not able to replicate the behavior and I’ll see if I can spin up a new dev server that you can access.

Thanks!

Here’s a list of plugins that we have on the site, but keep in mind I’ve disabled all the plugins except for wpDiscuz and the problem persists. I’ve also tried it using the default TwentyFifteen theme just to make sure something in my theme isn’t causing the problem.

I’ve also discovered something that may help isolate the issue: the problem only occurs when there are no approved comments on a post. Here are a couple of unapproved comments.

Here’s what they look like on the post.

If I approve one of the comments, the other unapproved comment is then hidden. Here’s a screenshot of the same post w/ one comment approved.

Does that help at all?

Here’s a link to the screenshot:
clipboard

Thanks for the quick response!

Yes, I tried that. I tried it from Chrome incgonito, from Safari on my iPhone, and from IE…none of which have ever been logged in as Admin. I’ve also had a co-worker try it and it’s showing up for him as well.

It doesn’t track via IP Address does it? Our desktop machines would all show up as originating from the same IP.

Hi Sylvain,

I’m using Gravity Forms and “wordpress_forums” post works for me. The key is setting “Sender Email” and “Return path” to an SES verified email. Then setting “Reply to” to “headers” passes through the reply to email from the form.

Thanks!

Walt

You’re welcome Scott…thank you for the nifty plugin!

I think this works for the most part. We are having some issues where W3TC is serving images to desktops that were cached by mobile devices, so they’re grainy. This only happens from time to time though.

I’m not positive, but I’m pretty sure this issue could be solved by creating user agent groups in W3TC based on the user agents returned by your plugin.

Can you not just enable the “User Agent Groups” in W3TC? The default “low” and “high” groups should segregate a good deal of your mobile traffic, then you can add additional groups as you find the odd user agent that loads incorrectly. The end result should be that any mobile user agent uses separate W3TC cache files.

I know for sure that this works with older browsers where we have some IE-specific HTML. If an IE user happened to build the the cache it looked weird for all other browsers. Once we created the appropriate user agent group, this was no longer a problem. I’m hoping it works the same for mobble.

We just went live with this configuration this morning. We’re in a high-volume season so I should know fairly soon if it’s not working. I’ll post back in a few days if we have problems.

Thank you, thank you, thank you! We weren’t having the exact problem you described, but have spent hours investigating a weird redirect loop error on one of our SSL pages.

I can’t believe a single line of code was all we needed:
remove_filter(‘template_redirect’, ‘redirect_canonical’);

Thanks for taking the time to write this up!

Hi atvdev,

Thanks! Unfortunately versioning hadn’t been enabled on that bucket…doh!

It’s a fairly easy fix, and it’s unlikely to happen accidentally, but it is possible. We’re still not sure if it was just a weird image name that one of our editors added, or if it was done on purpose (our access logs were removed just as we started investigating….it was a comedy of errors!)

If you’d like details on how to reproduce the error just let me know. I emailed you last week so you should have my address.

Will do…thanks esmi!

Unfortunately not…I wound up not doing what I had wanted :/

FYI for future travelers, the issue was twofold: 1) look through wp_options and remove entries related to the pb_backupbuddy 2) remove the license key and regenerate it.

I recently had a problem with this as well. You might look through your theme for references to “wp-pass.php” and replace them with “wp-login.php?action=postpass”