Community Support Forums

First off, great plugin.

We have ran WP and s2Member on our site for over a year now without to many issues.

But in the last month, Safari started having problems accessing member level content.

I've went through the disabling plugins, checking my if statements.

Here's our setup:

Version: 3.5.8
Stable tag: 3.5.8
Framework: WS-P-3.5
WP: 3.1.2 ( Just updated today )
Member Level Content controlled under one category.
Exec-PHP to run php at the content level content, pages and post.

Only on Safari, a registered uses, level 4 can log into our site. Once in, if they try and access member only content they are redirected to wp-login.php?s2member_seeking=post-#&s2member_level_req=4.

If the member logs in and before accessing member only content, they empty Safari's cache they will be allowed to access the member only content.

Again, I've disabled all other plugins, so I'm thinking it maybe something with s2Member.

Thanks up front for any help on this problem.
-Daniel

Hi Daniel.

Did you also try the TwentyTen theme? I don't know if your theme does any kind of caching that may be causing the issue?

I'll notify Jason about this problem you're having.

We do have WP SuperCache running, but we fixed that problem a while back by excluding the members only URL.
The theme we use does not cache html, it does howevery cache images.

And no I haven't tried another theme. The site has been using the same theme from the start.
I will try WP's default theme, tonight and post the results.

Thanks for the help.
-Daniel

Switch to Twenty Ten 1.2 theme. I'm still having the same problem.

Thanks
-Daniel

Hi Daniel. Have you seen this post regarding www vs. without?
viewtopic.php?f=36&t=1066

The fact that it's a browser issue, suggests that it's either a cache plugin causing confusion for you, or that it's a cookie issue, possibly related to the www issue I mention in that thread. Please report back if you can. I can confirm that all of my tests in Safari seem fine, but I would like to get to the bottom of this. Thanks in advance for your patience.

Jason,
Yes, I have read that post.
We use the host name www in all of our URLs.
WordPress address (URL): http://www.laramyk.com
Site address (URL): http://www.laramyk.com

I've removed all caching plugins. The weird thing is that it's just Safari.

Also, we have a testing site, we can do about anything you want.

Thanks for the help.
-Daniel

Thanks Daniel. I just created an account on your site with Username: jasontest
Please upgrade me to Level #4 and provide me with instructions on how to reproduce this in Safari. Also, can you please tell me which version of Safari this problem occurred with, and was this running on a Mac, or Safari for Windows?

Jason, I moved your account over to our test site.

You should have received an email with the password.

Safari 5.0.5 and 5.0.4 on OS X, have not tried Safari on Windows.

Thanks
-Daniel

Jason,
Login into the test site, access http://[Test Site]/welcome/ click on "You may now order online.".
On Safari it will redirect you back to the login screen.

Thanks
-Daniel

Update:
Testing different s2Member configureations.

I've changed s2Member's ACLs from Category to Page,Post with the key word all.
Under Safari I'm seeing the same results.

But one weird behavior is that the Login Welcome Page works as it should.
Thanks
-Daniel

I am seeing the same problem, also on Safari 5.0.5 OS X 10.6.7. Please see my detailed recreation scenario and comments here... viewtopic.php?f=4&t=6281

Simply... Any individual restricted page "touched" AFTER dumping the browser cache (Safari, Empty Cache...) but BEFORE login will not be accessible after log in. Those untouched will be accessible.

Let mew know if I can provide more details.

Another update:

I've updated WP Permalink Settings from Custom Structure "/%category%/%postname%/" to WP's default settings, p=123.

My testing shows Safari doesn't redirect under this config.

Can some one verify this?

Thanks
-Daniel

Pemalinks in my case are configured to use the default URL structure and exhibit the problem... e.g. /?page_id=239

See example links under "Platform" and "Configuration" at... viewtopic.php?f=4&t=6281#p13960

Investigating now.
Thanks for the details guys.

If you need anything just shoot an email.

Thanks again.
-Daniel

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.

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

Jason,
The hack worked for me.

Just a suggestion, way do a redirect in the first place. For us, I don't want Google to index my members only URLs.

Could you insert content into the request.

Let's say s2Member had a configuration option that would allow you to assign default content to be displayed when a user doesn't have the correct access level. This content could come from pages or post, even hand coded option in s2Member settings for each level.

For spiders/crawlers, write a robot.txt with your members only content urls not allowing them to be index.
Could s2Member write the file?

Thanks
-Daniel

In that hack, can't you check the browser used and only change to 302 if Safari?

Yes, perhaps that's what we need to do overall. Detect browsers vs. spiders/crawlers. Issue 302's to browsers, and 301's to spiders/crawlers. Is this a viable solution you think?

Yeah, since the content is the same, I don't see Google complaining about giving them something different than the user getting the result in their search engine.

But I'd still give the 301 to browsers that handle it properly, or would you rather prevent new unexpected behaviors as Safari's?

Gotchya. Yes, I'm thinking that it might be a good preventative measure overall. For instance, if this is happening in Safari ( i.e. WebKit ), then it could also be affecting some iPhones and some versions of Google Chrome, both of which are powered by WebKit like Safari is.

Ah, got it. I agree with you.

Changing the content redirect status as suggested from 301 to 302 RESOLVES the issue in my configuration... viewtopic.php?f=4&t=6281

Correct me if I am wrong, but with a status of 302, search engines and crawlers would simply index and reindex the MOP but still be unable to access restricted content.

Thanks for the response to a challenging issue.

Thanks for the follow-up.

tkittredge wrote:Correct me if I am wrong, but with a status of 302, search engines and crawlers would simply index and reindex the MOP but still be unable to access restricted content.

Thanks for the response to a challenging issue.

Yes, you are absolutely correct.

However, with 302s, I've seen spiders end up with a set of search results like this:

Code: Select all

Membership Options Page
http://example.com/protected-page-1/

Membership Options Page
http://example.com/protected-page-2/

Membership Options Page
http://example.com/protected-page-3/

Membership Options Page
http://example.com/protected-page-4/

Ultimately resulting in duplicate content warnings.

I think the detection of search engine crawlers/spiders should work nicely though. We'll get this updated in the next release. That way browsers get 302 redirects, but spiders/crawlers get 301 redirects.

I have read thru this thread and currently experiencing a similar problem with users in Safari. I've read about the negative effects on protected pages, but in my install of S2Member I'm only protecting file downloads. How will this hack effect my pages being indexed with Google?

Thanks,
AnnaSkye