pjv

i tried it with proxy set to yes.

and the plugin did recognize the HTTPS host as a subdomain.

but it still only sets logged-in cookies for the HTTPS host when the HTTP host is being proxied by cloudflare.

i have inspected the cookies that are set. with the HTTP host bypassing cloudflare, the plugin sets logged-in cookies for both the HTTP and HTTPS hosts. when i put the HTTP host behind cloudflare, it only sets logged-in cookies for the HTTPS host.

there are no changes whatsoever in the URLs between these two cases. the HTTPS host is always configured to bypass cloudflare. the only thing that changes is whether or not the HTTP host is being proxied by cloudflare.

so now i am in production, behind cloudflare, and i am back to subdomain: no, and only getting a cookie (i believe) for the secure host and not sitewide. so i don’t appear as logged in (no admin bar) on the http host.

the problem i now see, i believe identical to @onerock, is not the hostname problem that i solved on my test platform. it is directly and repeatably the result of running the site behind cloudflare. if i have the http host being proxied by cloudflare, then the plugin gives me subdomain: no and i get no admin bar after logging in. if i bypass cloudflare for the http host, i get subdomain: yes and everythign works as expected.

among other things, cloudflare works as a reverse proxy. mike, do you think that changing the proxy setting in the plugin to auto or yes would have the right effect here? what does that proxy setting do?

+1 for being able to set an image max-width | max-height

[great plugin – thanks!]

yup, thanks. had that setting.

fixed my final issue above by turning on the option in the redirect plugin to “Allow a POST or GET “redirect_to” variable to take redirect precedence” and then re-writing the code that generates my login link to look like:

<a title="Login" href="'. wp_login_url($_SERVER["REQUEST_URI"]) .'">Login</a></li></ul>';

SO… the only thing left unsolved in my posts in this thread is why the plugin would not save the [variable]http_referer[/variable] string with the brackets when i tried to do that and i had to go into the db directly to save that string.

i went into the db directly and changed the string in there to [variable]http_referer[/variable] and then it kind of worked.

logout is working perfectly, leaving me logged out on the same page where i clicked the logout link.

login is still not working for me even with the fixed URL string. no matter what page i login from, it tries to redirect to me to https://mysite/wordpress/ which is a 404.

i think it might be because my admin and my login form are on a different subdomain (accessed via SSL) than the referer page and i am also using another plugin, “wordpress HTTPS” to manage those redirects.

hi peter,

sorry if this is dense, but are you saying to paste literally [variable]http_referer[/variable] into the URL box?

or are we supposed to substitute something arbitrary where it says “variable”?

when i tried pasting the exact string above and then clicked the update button, the plugin gave me the alert “Successfully updated URL for “all other users””, but the string in the URL box changed to variablehttp_referer/variable – note lack of brackets, and the redirect went to a 404.

ahhh so.

now i get it. thanks for the explanation.

got it.

thanks for taking the time to write that explanation up.

maybe i’m not taking something into account.

do you mean that for the purposes of this plugin it wouldn’t work to call anything that looks like xxx.abc.def.gh (where xxx could be any arbitrary string) a subdomain of abc.def.gh?

in other words, if there is a hostname and then a dot and then some arbitrary domain name string and you are comparing that to another host that is identical except for the hostname and dot, wouldn’t it always work to call the first one a subdomain of the second for the purposes that this plugin serves?

sorry if i am being dense.

fwiw, there’s a lot of protective code in the function, but WP Super Cache pretty much does this.

see the function prune_super_cache() in the file wp-cache-phase2.php

sorry then. whatever is causing your Subdomain: no must be a different problem than what i was seeing.

this isn’t a real solution, but you can hack the plugin to force it to treat the URL as a subdomain. i don’t know what kind of side-effects this might have…

in the file wordpress-https/lib/WordPressHTTPS.php, line 205 should look like this:
$subdomain = false;

i think that if you change that to:
$subdomain = true;

then it will always treat the secure URL as a valid subdomain (whether it is or not).

might be worth trying that, then re-saving the settings in the plugin’s admin page, restart services on the server, clear your browser’s cookies for your secure and non-secure domains and try it all again.

does your centOS box have curl installed?

can you run something like this from the command line on the server and get a valid http response?:

curl secure.mydomain.com

i think it was the combination of getting the hosts file right and then restarting that fixed the problem i was seeing. i don’t think it was just the restart because i had done a lot of tweaking and restarting with no effect until i got the hostname issue sorted.

i’d still suggest to mike that he re-think validating the subdomain URL by connecting to it with curl as part of determining whether it is in fact a subdomain. so many ways that could go wrong in terms of connectivity at the time of the check, whether the user has curl installed or not, etc. it seems to me to make more sense to determine if a URL is a valid subdomain of another URL on a purely lexical basis.

that said, this is a GREAT plugin, so thanks mike for putting it out there.

yeah, i understand the issue, but if there were some way to confirm that the command was only running on the cache directory… guess that could be difficult to do.

maybe force the user to enter the full path to the cache and also get the path to the nginx config from the user and then parse it to confirm that it has the same path entered for fastcgi_cache_path and then don’t show the button unless the user checks a box that says they understand the danger and know what they are doing.

probably still pretty dangerous and not worth people yelling at you.