mvied

The plugin is looking for wp-pass.php. I’ll get a fix out in the next version. Thanks.

The proxy setting is for bad proxies that don’t properly set the X-Forwarded headers. That is all. You would know if this was the case because nothing would work properly without that setting on Yes.

I don’t know what you’re talking about with “cleaning up” but you’re probably experiencing redirect caching issues in Google Chrome, not your server.

You’ve already identified the code that determines if the site a subdomain or not. The subdomain check is done upon installation/activation and when the settings are saved. The code simply isn’t working in your setup for one reason or another.

After researching this issue, I came to the conclusion that the best way to handle these situations is to manually set the cookie domain in the wp-config.php. Change it to ‘.yourdomain.com’ to get a site-wide cookie set.

I am currently working on improving this part of the code and will eventually remove the need for cURL requests to validate the cookie domain.

You didn’t actually say what’s happening, just that it’s ‘not compatible.’ That doesn’t help me. I’m assuming you’re getting redirect loops because WordPress HTTPS has Force SSL Exclusively enabled and Jigoshop’s settings are forcing everything to be secure. This causes WordPress HTTPS to always redirect to HTTP and Jigoshop to always redirect to HTTPS. Disable Force SSL Exclusively or add ‘/’ as a URL Filter to secure all of your pages.

The whole point of the caching plugin is so that you don’t have to load WordPress every time a page is hit if there have been no changes to that page. Therefore, the plugin does not even run when a page is being pulled from the cache.

You’re going to have to use rules in your .htaccess to force pages to HTTPS.

Determining if two domains truly share a common domain by only using string comparisons is not possible. When comparing two domains, it’s likely that pieces of the domains will match. It’s impossible to determine if that commonality is really a shared domain without knowing all possible top-level and second-level domains. That would require maintaining arrays of top-level and corresponding second-level domains in the code to check against. Due to the rapid change of domain name rules, it would be quite tedious to do that. For example, .uk has many, varying second-level domains.

You can use the feed_link filter built in to WordPress. You can place this in your theme’s functions.php or in a custom plugin if you want the ability to turn it on and off.

function http_feed( $url ) {
    return str_replace('https://', 'http://', $url);
}

add_filter('feed_link', 'http_feed', 10);

If you’re using a subdomain, you should be logged into both using a domain-wide cookie. Enable debug mode and check your browsers console for the debug output. Look for a line that says “Subdomain: Yes/No”. If it says no, try re-saving the WordPress HTTPS settings and see if it changes. If it says Yes, there’s a bug of some kind.