Does the plugin set the cache control header?

Interesting thread! I tried to manually add that line, but it doesn’t solve the issue I temporarily solved with htaccess the other day. What really surprises me is the traditional login works just fine: why a caching issue is solved by the traditional login and not by the link users receive by email that fundamentally does the same things in another way?

@m_uysl Both things! But I must say I did many other things before giving up when I found the htaccess solution (that’s just a temporary patch). Problem with the htaccess is it solves the admin bar issue but it creates an additional Cache Control header for logged in and logged out users: I removed the no-store part and it works anyway, so when you’re logged in basically the broweser doesn’t care too much because the headers added by WP for logged in users are the same I add, so apparently there is no conflict between the two. I’ve had no spare time, so I could not find at least a way to unset the header when the user logs out (I have this header always set, a thing that I don’t like too much. I made a quick test with Apache variables but it didn’t work. I’ll try when I have nothing else to do) 🙂

Another strange fact is the wordpress_logged_in cookie is set when logging in with the link, so really I don’t know what’s going on (I deactiveted anything I could deactivate and tested with incognito, removing cookies, forgetting website, next step is calling an exorcist) 😀

Anyway, I don’t think this is a plugin issue at all, there must be something at some level that prevents the plugin from doing its work, that’s it.

• This reply was modified 7 months, 2 weeks ago by islp.

Ok, a couple of tests.

Browser is Firefox (I found the general behavior is the same for Chrome-based browsers too), incognito mode and after erasing any previous trace of the website too (cookies, files, etc).

1.

For this first test, I commented out my rule from the htaccess (this means the user trying to log in with link will NOT see the admin bar: it will appear only if he manually moves to another page).

Load home page (not logged in):

• header Cache Control present, its value is: max-age=2592000 (I suppose this is directly set by the hosting OR is a new WP header for non logged in users);

I move to the login screen:

• header is now Cache Control: no-cache, must-revalidate, max-age=0, no-store, private (this is WP’s)

I request the link, copy it from the mail and paste/enter in the address bar:

• Cache Control header of wp_login is: max-age=2592000
• Cache Control header of the home page (where I redirect_to when I log in from the wp_login screen): max-age=2592000 (and wordpress logged in client cookie is set)
• no admin bar is shown;

If from here I move to any other page, Cache Control changes to: no-cache, must-revalidate, max-age=0, no-store, private and the admin bar is visible.

If I logout, the final Cache Control is max-age=2592000.

2. For this second test, same browser conditions as above, but I place my rule in the htaccess.

Load home page (not logged in):

• header Cache Control present, this time its value is: no-cache, must-revalidate, private (this is the value set in my htaccess file);

I move to the login screen:

• there are two different Cache Control headers now: no-cache, must-revalidate, max-age=0, no-store, private (WP) and no-cache, must-revalidate, private (htaccess);

I request the link, copy it from the mail and paste/enter in the address bar:

• Cache Control header of wp_login is: no-cache, must-revalidate, private
• Cache Control header of the home page (where I redirect_to when I log in from the wp_login screen): double headers, as above;
• the admin bar is visible;

If from here I move to any other page, Cache Control: double headers as above.
If I logout, the final Cache Control is no-cache, must-revalidate, private (one single header).

If you have in mind other tests, let me know (eg. with nocache_headers(), that was not present in the tests here)

@m_uysl It doesn’t make a difference, as you suggested. As soon as I have some time, I will try to go deeper. 🙂

@m_uysl maybe I found something.

Only for this website I use a membership plugin (WP-Members). The plugin lets you hide content, so that only logged in users can read it. For ten years the plugin duplicated the login screen, providing its own login screen. Last week the website owner asked me to remove this second login screen because users are less and less capable of using websites (according to him) and this double login could confuse them. I removed the second login screen this way:

add_filter('template_redirect', function () {
    // if the content is blocked by the plugin
    if (function_exists('wpmem_is_blocked')) {
        if (wpmem_is_blocked() && ! is_user_logged_in()) {
            // don't cache headers
            nocache_headers();
            // redirect the users with the redirect_to in the url
            wp_redirect(wp_login_url(get_permalink()));
            exit;
        }
    }
});

This thing perfectly works when the redirection is from a protected content (the user finds the protected content, automatically is redirected to the standard login, he logs in and automatically goes back to the previously protected content finding it unprotected).

But, when you login from the standard login screen and redirect_to value is the home page url, some conflict happens with your plugin.

The conflict is eventually “patched” by converting this code to this (for sure not perfect and still untested):

add_filter('template_redirect', function () {
    if (function_exists('wpmem_is_blocked')) {
        if (wpmem_is_blocked() && ! is_user_logged_in()) {
            nocache_headers();
            wp_redirect(wp_login_url(get_permalink()));
            exit;
        } else if (!wpmem_is_blocked() && is_front_page()) {
          // maybe add !is_user_logged_in  
          nocache_headers();
        }
    }
});

Before testing for front page, I tried to GET ‘magic-login’ or check for the referrer but your wp_safe_redirect doesn’t send any referrers.

This “thing” works without editing the htaccess.

For sure it lacks other controls and at the moment I have no idea if it could really be the definitive solution (that is: I don’t know if it is efficient and if there are other aspects to consider).

• This reply was modified 7 months, 2 weeks ago by islp.
• This reply was modified 7 months, 2 weeks ago by islp.
• This reply was modified 7 months, 2 weeks ago by islp.