Thank you.I'm still testing this, but I suspect it's related to 301 permanent redirects implemented by s2Member. My research shows that some versions of Safari will cache a 301 redirection, even though WordPress/s2Member sends
no-cache headers before the redirection.
This is unexpected behavior, because most browsers will respect no-cache headers, and NOT cache the redirection. However, a gray area emerges on this according to
the specs, so we may need to seek an alternative solution; in order to avoid this possible bug in Safari.
In fact, some articles I researched mention that Safari might even cache this into memory;
making it difficult to clear with common techniques ( i.e. Safari -> Empty Cache ).A possible solution.90% Resolved ( pending a full resolution though )
Please create this directory and file:
/wp-content/mu-plugins/s2-hacks.php
- Code: Select all
<?php
add_filter("ws_plugin__s2member_content_redirect_status", "content_redirect_status");
function content_redirect_status($status = 301){ return ($status = 302); }
?>
* But please note. This has a potentially harmful side effect. s2Member sends a 301 redirect status ( by default ), in order to avoid duplicate content issues with search engine spiders/crawlers.
By using a permanent redirect ( 301 status ), s2Member tells search engines NOT to index protected pages of your site, which would only redirect to the Membership Options Page anyway. This is why 301 redirects are recommended for protected pages that are redirected.
If you use a 302 redirect instead, you might avoid this Safari issue; but Google might try to index all of your protected URLs then, which would only lead a search engine to the same page over and over again ( i.e. your Membership Options Page ).I'm open to suggestions/feedback on this topic please.See Also:
http://stackoverflow.com/questions/2954 ... 1-redirect