After further testing on a multisite installation that was using domain mapping on MOST sites, I found that it was not forcing HTTPS on domains that were not being mapped. Here is a usage example:
- initial login to multisite – “https”/OK
- navigate to a site post list – “https”/OK
- click “view” on a post (staying in same window) – “http”/OK
- hover over “Edit Post” link in nav bar – “http”/NOT GOOD. Clicking on this link results to a login page because we have not yet been authenticated using “http” because our initial login used “https”.
After further testing I confirmed that this plugin was working as expected for sites going through the domain mapping plugin and NOT working on sites still using the subdomain and not being mapped.
We may have a use case that not all people to. Most of our sites are on existing domains so we use the subdomain as development while we are building the site. When the site is ready to launch, we add the domain mapping to the site settings. Even so, we have four sites that are internal to our team and they will never be domain mapped.
This list shows the states or sites can be in:
- never using domain mapping
- no domain mapping while building the site; applying domain mapping when site is ready to publish
- always using domain mapping for newly purchased domain names
For cases 1 & 2 we needed another solution. We found that by setting
true, this solved the problem. Now all three states above are properly switching from HTTPS to HTTP and back again.
This is what worked for us.
- The topic ‘Solution for sites on a network that don't use domain mapping’ is closed to new replies.