Saving Settings does not work for custom login site

Little update: after hacking it into the DB the entry does not disappear in the settings when I change other settings! But the initial entry isnt possible.

Because of time differences, I am just seeing this now. I will investigate and report back here as soon as I have any useful information.

Thanks for the interest!

I just checked on my Test Network site. Both Network Activating the plugin and Activating it just on the Site I was testing on. I actually get two error messages — the same error twice — when I enter the “Custom Login page?” checkbox and leave URL blank. Likewise, I get two warnings — the same warning twice — when I enter the “Custom Login page?” checkbox and enter a valid URL:

“Landing Location changed to “Omit”, recommended for Custom Login pages. See Advanced Settings to Override, but please read Warnings first.”

I am using WordPress 4.1.

Only thing I can suggest at this point, to let me re-create your problem, is to get a list of all your plugins that are activated for the Site where you are testing, and which ones are Network Activated and which are Site Activated. I’m not going to worry about Themes as I’m not aware of any that effect the Admin panels.

I should also warn you that I’m away for a large chunk of the day today, so I’ll respond when I can.

Hi jonradio,

wow fast reply! I’m impressed. No worries everything works fine now. I just wanted to be sure it’s not a general issue. At the moment I can’t test some things (enabling debugging etc. – because its on production). But I will setup a copy on a test environment to get more details. But that will take some time (day or two?).

I will come back to you.

Thanks!

Thanks for your help on this! I’ll do my best to work with you to solve it.

OK I found out, that this “not saving but” is related to bigger problem (now for me) with W3 Total Cache. I will let you know when I found out more.

But another “issue”: Can you please let a user free chose the login page? Because I wanted to redirect to another page in my network for this purpose but it only accepts the actual domain as base.

Thanks!

Thanks so much for the update!

Good idea on the Login Page. Since most Admins would want me to make the “same site” check, my plan would be to add an Advanced Setting that removes the restriction but defaults to “same site check”, rather than not checking for everyone.

My Sites are not high traffic, so I never use Caching. What little Caching I had looked at for plugin problem reports never seemed to cache WordPress Admin panels, so that would have really caught me by surprise, too.

Hi, unfortunately I can’t give you more feedback regarding the W3 Total Cache problem because we couldnt yet figure out what exactly the problem source is. But it is running – therefore we dont touch it at the moment on production. We first need to solve the Total Cache problem – maybe an update will solve it (it seems to have the “bigger” problem with another plugin – not yours).

But I recently wanted to add a new site to the network – also with private site protection. There I had the problem, that even when I used the same configuration like for the first private site, the site wasnt protected. Is the Multi-Domain feature supported by your plugin? Because the first private site was just a subdomain of the subdomain for the wordpress network (sub.sub-wp-network.domain.tld) – but the second is mapped via WordPress MU Domain Mapping to another subdomain (sub.domain2.tld). Can this be the problem?

I’ll need some time to create exactly that situation on one of my test systems: sub-subdomain aliased to another subdomain. Based on my knowledge of the code, I would guess that this setup would be a problem with Visible Exclusions but NOT with overall privacy of the site. As I say, I need to test to know for sure.

I’ll reply here as soon as I have my test system set up in this way and have done some testing on it. I am already half way there as I have WordPress MU Domain Mapping already working on my test system.

The good news is that I was able to re-create this problem on a new test system that I built for this purpose. The bad news is that I’ll have to do quite a bit of digging to figure out why my plugin is not working as it should in this circumstance.

I would estimate that I’ll have a new version out with a fix for this in about 24 hours. I hope that this will meet your needs. This is an unusual problem.

I got waylaid by an emergency problem with another plugin, but I did more testing of your reported problem. And I now believe that this problem only appears to you, but would not appear to the general public who have never logged on to your site.

You are seeing this because WordPress considers sub.sub-wp-network.domain.tld and sub.domain2.tld as two different domains. And keeps track of your login status separately on each.

To verify this is true, please logoff and then remove all the cookies in your browser for sub.sub-wp-network.domain.tld and sub.domain2.tld

As soon as I did that, everything worked perfectly.

Obviously, if I’m wrong about this, please let me know.

Hi, thanks for checking! Your are right. I deleted the cookies after configuring private site – then it started working like it should!

Strange is that I checked it in Incognito/private mode in chrome and it did not work. So I tried the following (using two browsers for having cookie separation):

I logged in via Chrome and removed the private site (disabled it). Now I deleted all cookies in firefox and navigated afterwards to my not protected subdomain (sub.domain2.tld). Now I switched to chrome and enabled private site again. After going back to firefox and refreshing the website, it still shows up. It seems that ANY cookie (not only for logged in users) prevents from being protected. So everybody who accessed the website and got a cookie can still see the website.

So protection is widely available here but with some limitations. But it shouldnt be a problem with a new site – only if you turn it on after some while.

Thanks for the follow-up and additional information.

All I can add, at this point (i.e. – I don’t have any ideas for a solution), is that this appears to a be a problem solely when WordPress MU Domain Mapping is being used. I have never received reports of this being an issue without the WordPress MU Domain Mapping plugin.

I should also mention that WordPress cookies do expire in a fairly short period of time, so the problem would likely disappear quite quickly.

Again, just my thoughts on the subject.

OK valid point. Its only a session cookie. Thanks!

Version 2.14 resolves the issue described above as “Can you please let a user free chose the login page? Because I wanted to redirect to another page in my network for this purpose but it only accepts the actual domain as base.” A settings has been added to allow this.