Strange 302 Found redirect behavior with Comet Cache Autoptimize

Raamdev & co; I don’t see what AO could do to cause this, but do let me know if you think of something, I’ll be happy to help where possible if AO is somehow to blame.

frank

– renaming both Comet Cache and Autoptimize simultaneously: good, clean 301 –> 200 redirect from root URL name to full https URL

– alternately renaming Comet Cache and Autoptimize individually: no effect

I think these are the best clues. It seems extremely unlikely that two plugins developed quite independently would both contain something to cause the same problem. My deduction, therefore, is that it is much more likely that you have something else — one common denominator — running on your site which affects both plugins.

I think you need to focus on which other plugin (or other source) might be at the root of the problem here. For example, are you running an SEO plugin and, if so, what is it?

I think these are the best clues. It seems extremely unlikely that two plugins developed quite independently would both contain something to cause the same problem.

Yes, well. Here’s what I finally determined (I think): it was an obscure spider trap code snippet in my (child)theme functions.php file invoking “Googlebot” by whitelisting it that seems to be the culprit. And so at this point I find I can solve the problem equally well either by

(a) disabling both plugins and leaving the script snippet; or

(b) disabling/removing the script snippet

Because I value both plugins highly, I chose (b). Someone else faced with similar phenomena, perhaps not motivated to search further as I did, might simply elect to swap out the plugins.

My own main takeaway is that there’s some interesting interactive ecology among multiple players now possible in WordPress and that problems do not always reside in single agencies.

@saintandrews,

You overcomplicate; I prefer Occam’s Razor.

You had a conflict, and the code you removed conflicted with more than one plugin.

Plugin conflicts have been part of WordPress since it began, and the remedy remains the same. No new ecology at all!

And you can almost certainly recover the functionality intended by the obscure, conflicting script if you replace it with another well-coded plugin that doesn’t cause conflicts.

an obscure spider trap code snippet in my (child)theme functions.php file invoking “Googlebot” by whitelisting it

that’s … intriguing, can you copy/ paste that here to see to which extend it would collide with CC or AO? ??

Frank, I can, but I won’t. The author of the script in question has been a major contributor to WordPress for over a decade, has helped thousands of people, and his scripts are incorporated into a number of cutting edge security plugins even today. That that one particular snippet caused the phenomena I described could indeed simply be idiosyncratic to my situation. Remember, none of these elements involved invoked problems prior to my transitioning my blog from http to https, and the only problem which arose then was an endless redirect within the latter, for one particular search engine bot. Even so, I’ve already given sufficient pointers to the particular script in question for anyone interested in it per se – should they encounter this same problem.

Although KTS915 confuses listening to himself with Occam’s Razor (a rather different logical principle), had I actually followed Occam’s Razor I would have instead pursued the simplest answer – that both Comet Cache and Autoptimize were causing my problem – and I would have simply replaced them with alternatives, looking no further.

@saintandrews,

Occam’s Razor doesn’t mean you stick with the first symptom you find. It means you look for one cause, not two. So you’d eliminate one script, not two plugins.

But you knew that anyway, didn’t you!

KTS915, unfortunately, my problem was not one of trying to perform your understanding of Occam’s Razor in abstracto. My problem initially was rather one of trying to understand why two separate plugins were nevertheless performing as one when causing my problem and then, when both – not simply either one – were disabled, still performing as one and un-causing my problem.

My problem was not your abstract one of Occam’s Razor but rather my actual one of Sophie’s Choice, not an abstract choice between several and one but rather an actual choice between A and B.

Remember, my script snippet works fine and causes no problem when both-plugins-as-one are disabled and vice versa. So my choice was and remains the purely arbitrary, binary one of choosing whether to keep either the conjoined twins which, in my current situation, offer me marginal advantages via performance (in other situations those advantages could be far greater) or to choose the other, single script child which offers me marginal security advantages and to abandon the conjoined twins instead.

But nowhere in any of this do I see anywhere where you, by gratuitously adding a reference to Occam’s razor to some details I had already offered and thought about while simultaneously ignoring other, equally salient details, have contributed anything of value to my particular problem and its solution.

Frank, I emailed you.

@saintandrews,

Your initial response to experiencing this issue was to report that two plugins might have a problem. Mine was to suspect that there was another, common cause. On further investigation, you found precisely what I deduced right at the beginning.

After you confirmed what I thought, I told you how I’d done it. But apparently you’d prefer to adhere to reasoning that would have led you to disabling plugins you wanted to keep!

The problem with your reasoning throughout has been the common fallacy of the last activated plugin. That is, so many users think that, if things were running before a specific plugin was activated, then the problem that I am now experiencing must have been caused by the last plugin. But code doesn’t work like that.

In fact, it’s much more like a simple equation. Take, for example, 1+2+3=6. Does it make any difference if I write the first three numbers in a different order, e.g. 3+2+1? No, of course, not. The total is still 6.

The same is true of WP plugins. The order in which you install them doesn’t matter. The cumulative effect will be the same. So you completely miss the point by saying you had no problem before you installed either AO or CC. Your script still had an issue; it’s just that the issue was latent.

So Occam’s Razor is absolutely on point here: if several items in WordPress experience a problem at the same time, the likelihood is that there is a common cause, and that cause might have been lying latent on your site for months, or longer.

So assuming that a long-used plugin or script is fine just because you’ve had no problems until now is a big mistake. Learning to use good diagnostic tools (whether WP plugins or browser extensions) will help you much more effectively.