mvied
Forum Replies Created
-
I don’t know about the current version, but the development version will work for you. Enable Force SSL Admin and Force SSL Exclusively and only your admin panel will be secure. All links to the front-end will be HTTP.
The Force SSL Admin bug doesn’t happen to me. The code that throws the error looks like this.
if ( force_ssl_admin() || force_ssl_login() ) { $errors[] = '<strong>SSL Admin</strong> - FORCE_SSL_ADMIN and FORCE_SSL_LOGIN can not be set to true in your wp-config.php.'; ...So the only way the error would show up is if WordPress is returning true for either of those built-in functions. So, you must have one of them enabled somewhere.
I think I might have already figured this out. Give my development version a shot.
In this thread a user mentions adding
ErrorDocument 404 /index.phpto your .htaccess. Give that a shot. I’ve never had any experience with dealing with these Shared SSL’s, so I’m just guessing.Forum: Plugins
In reply to: [WordPress HTTPS (SSL)] [Plugin: WordPress HTTPS (SSL)] WordPress HTTPSWhen I Network Activate, the plugin is enabled for all the sites. Furthermore, the plugin does not appear in the Plugins list for the subsites for me to do anything with.
I’ve never really used the Domain Mapping plugin. In the current version, the plugin is not running its installation process for each subsite when you do a Network Activate. This will be fixed in the next release. It will be out within a week if you’d like to wait.
Try the development version if you’re going to be trying soon.
This issue should be resolved in the latest release.
This should be fixed in the latest release. I found the filter for WordPress’ rewrite rules and that allowed me to add a filter including the extra path information, causing the pages to now be found.
Hey Daniel, could you test the development version and confirm that it also works as intended? I’d hate to push it out and have this issue reappear. I only mention it because I’ve specifically worked on that part of the code.
When you’re using an SSL Host that doesn’t match your Site URL, the code never verifies that you’re hitting the site over HTTPS from that host. It assumes that if your SSL Host doesn’t match your Site URL, there’s probably only one URL you can hit that site securely with, so it doesn’t bother verifying. If you’re SSL Host doesn’t match your Site URL and the page is HTTPS, you’re good to go. No redirect.
I’m guessing
http://team.example.org/2012/07/01/test-foo/works as intended?I could add in a check pretty easily, but to date there’s never been a reason to.
Hmm, that doesn’t make any sense. In my development version, I ensured that when you Network Activate, the plugin is properly activated for each subsite. I think the issue is that the plugin just isn’t installing for each site.
Secure Front Page should not make insecure content errors go away, but rather I think saving the settings is making it work.
If you do want to use the Secure Front Page option for each subsite, you’ll still have to go enable that option for each site.
Not really, that’s just confusing.
You mentioned blog.example.org and team.blog.example.org in all your screenshots, and then you make a cURL request to
https://team.example.org/2012/07/01/test-foo.What?
Make sure you close your browser to ensure there are no issues with browser caching.
I can’t guarantee it’ll be fixed when I release the next version, and I probably won’t push out a new release for a while.