pjv

ignore the post just above. i re-started nginx and php5-fpm on the server and quit and re-started the browser and now everything is working fine. so the original problem does seem to have been the isValid() function returning false because i had forgotten to enter the hostname for the secure host into the test server’s host file. i hope that helps someone else.

continuing to work through this issue, i have one new update. in trying to determine why the plugin was not seeing secure.wr-test.local as a subdomain of wr-test.local, i dug down until i found the function isValid() inside of Url.php. when i read through the code in there, i realized that it was returning false because i am running all this on a test server and i had neglected to include the hostname secure.wr-test.local in the hosts file on the test machine, and it obviously does not resolve by dns.

as an aside, it seems a little strange to me to verify a subdomain by doing a curl on it. wouldn’t it make more sense to decide that secure.wr-test.local is a subdomain of wr-test.local purely on a string comparison basis?

anyway, now that i added that host to the hosts file, re-saved the settings in HTTPS admin, and cleared all the cookies and then re-logged in, the debug log now looks like this:

[BEGIN WordPress HTTPS Debug Log]
Version: 3.3.0
HTTP URL: https://wr-test.local/
HTTPS URL: https://secure.wr-test.local/
SSL: Yes
Diff Host: Yes
Subdomain: Yes
Proxy: No

but i still have the same issue. the cookie being set is not for the whole domain, but only for the secure.wr-test.local host. i still am not logged in on the insecure site front end, and i can also see in safari that there are only cookies stored for the secure.wr-test.local host and none for wr-test.local.

i am highly motivated to get this working and would be happy to test and report.

probably this is lack of php script knowledge, but is there no way to execute something like rm -r * at the os level in the cache directory?

i don’t know php at all, but in a python script you would be able to do something like that pretty easily.

i’m seeing the same issue with version 3.3.0, trying to do the same thing. i have a non-multisite install of wordpress and i need to run the admin on a secure subdomain.

when i activate and set up the plugin with the secure subdomain specified and both SSL admin and exclusive SSL options checked, much works as expected. when i go to the login page and the admin panel, it all redirects to the secure subdomain (secure.wr-test.local). when i click the “visit site” link, i get re-directed to the non-secure main domain (wr-test.local).

[and btw, i was having trouble with the preview button sending me to a 404 as mentioned in several other threads and i was able to fix that issue by putting “preview=true” into the URL filters box]

here is what doesn’t work as expected:

after logging in and then clicking on the “visit site” link, while browsing the site on the main non-secure domain, there is no admin bar at the top (i.e. i am not logged in on the non-secure host).

i am using nginx to serve this site. i have two virtual hosts set up: wr-test.local is listening on port 80 and secure.wr-test.local is listening on port 443

here is the debug log (subdomain remains “No” after re-saving HTTPS settings):

[BEGIN WordPress HTTPS Debug Log]
Version: 3.3.0
HTTP URL: https://wr-test.local/
HTTPS URL: https://secure.wr-test.local/
SSL: Yes
Diff Host: Yes
Subdomain: No
Proxy: No

at the top right of the “post” screen in the admin there is a little tab that says “screen options” hit that to pull down the screen options tab and then uncheck HTTPS.

Thanks,

I would be very happy with either:

1. some documentation that tells me how wordpress.COM associates jetpack site data with a particular site URL and how that interacts with the login credentials used to connect to wordpress.COM from the jetpack plugin so that I could have some idea what to expect when i do things like set up a test site by copying my production database to a virtual machine.

2. some way to tell Jetpack and wordpress.COM “Just kidding”, or maybe more to the point: this is a test site, please treat it as such and then do the “right thing” in terms of how it stores and associates data in the wordpress.COM database.

I see that there is another thread about this same issue here which has been marked as resolved, though it does not appear to actually be resolved.

Jetpack has huge, systemic effects on how a site works. People who are running busy commercial sites cannot afford to just throw a plugin like that into their production environment without first making sure that it won’t disrupt the site’s functionality.

The inability to test Jetpack is a total showstopper.

I also don’t understand why this is marked resolved. edwinvanolst’s hack notwithstanding, there is still no proper way to test jetpack prior to putting it into production.

I started another thread about the same issue with a little twist here.