Multisite

WordPress multisite returns https link on front end website creation

With the WPMU Dev pro sites plugin,  you can create a front end signup form to enable users to register and create their own website. If you have some of those websites not on SSL, but the signup website is SSL, you might get the problem that  the url that is generated by the signup function generates an https url, even though the website is not SSL.

This is caused by the fact that this plugin, and probably many others like it, use wp_get_sites() to return the siteurl. This function in turn uses the set_url_scheme() function to determine if the url should be returned with SSL or not.

It appears that if the user is currently on SSL, this function will return the url with https. And that results in a failure if there is no SSL certificate on that domain. Luckily the set_url_scheme function uses a filter that allows us to override the result. I’ve written a short function that simply looks for the blogid based on the domain, then requests the siteurl. If the siteurl starts with http, the siteurl will be returned.

This function is not meant for multisite setups with subfolders, only for subdomains or domain mapping.

 You can add this function in the functions.php of your theme file.
add_filter("set_url_scheme", "rsssl_check_protocol_multisite", 20, 3 );

function rsssl_check_protocol_multisite($url, $scheme, $orig_scheme){
    if (is_multisite()) {
    //get blog id by url.
    //make sure the domain is with http, e.g. http://domain.com
    $domain = str_replace("https://","http://",$url);
    //remove http:// from the domain. e.g. domain.com
    $domain = str_replace("http://","",$domain);
    $blog_id = get_blog_id_from_url($domain);
    // exit if no blog id was found.
    if ($blog_id==0) return $url; //no blog id found
    
    //request the blog url and return it. If it is http, the returned url will now also be http.
    $url = get_blog_option($blog_id, "siteurl");
  }
  return $url;
}

Related Articles

11 Comments

  • Matt

    Hey Rogier – this fix works great for the prosites registration issue you mentioned, but as a side effect, it causes the Media Library to spin forever and never load on the newly created subdomain sites 🙁

    • Matt

      Here’s an example of the error I’m seeing in the console: XMLHttpRequest cannot load https://domain.com/wp-admin/admin-ajax.php. No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://subdomain.domain.com’ is therefore not allowed access.

        • Matt

          Thanks Rogier. Do you know if there is a “safer” way to handle this besides enabling CORS? IE> additional .htaccess rules?

  • Rolf

    Hi Rogier,

    Have this issue with a Multisite using Let’s Encrypt SSL on the main site and on some of the subdomain sites but not on all subdomain sites. And because it’s Let’s Encrypt it has no wildcard license so every new site will by default be without an SSL license.

    The option to create new blogs publicly is enabled. This means new users can register and create their own subdomain site but as soon as they log in on the main site and navigate to their My Sites page (or use the admin bar left drop down menu link) to go to their new site, they will be faced with this very same issue: the links are https while their site is still on http. The browser freaks out about insecure access and people get scared and come to me asking if their site was hacked or something.

    What I’m saying is that has nothing to do with any other plugin like Pro Sites or Domain Mapping. This happens just the same on a Multisite with plugin-less domain mapping.

    I ended up creating a filter very similar to yours as there seems to be no other way except modifying WordPress core code. But I find it a bit hacky (and sad!) to have to force-revert the process that made WordPress decide to switch the http URL to https in the first place. So a week ago I created a track ticket on https://core.trac.wordpress.org/ticket/42080

    Hope this gets picked up some day…

    • Mark Wolters

      Hi Rolf,

      this is indeed something that has been bugging us as well, let’s hope the ticket gets picked up so we don’t have to develop any more workarounds 🙂

      Mark

  • Jim Nelson

    Thanks Roger. I just discovered an issue that is exactly the opposite as you describe, and I wonder if your hack will help, or if there is another solution.

    I have purchased the Premium Really Simple SSL Multisite plugin, and we do run Pro Sites supporter platform. We have a wildcard SSL certificate, with https forced on all subsites. Our issue, however, is that WordPress sends new bloggers their username and password (on screen) and in the Welcome Email using: “Login Here: BLOG_URLwp-login.php”

    The problem is, that BLOG_URL is being sent with http and not https, and Really Simple SSL is not converting it when visited. What you write here makes it sound like this may be a WordPress issue. Please advise if I should open a support ticket instead.

    • Rogier Lankhorst

      Hi Jim,

      In this case I think it should be solved by enabling the .htaccess redirect. If you do this, either per site or networkwide, these requests should get redirected to https as well. Let me know if this works for you.

      • Jim Nelson

        Thanks for the quick response. Enabling the .htaccess method, does allow users to successfully log in when sent the “http” link to their dashboard. This appears, however, to be drastically slower than the 301 Redirect. It literally took 15+ seconds for the subsite/domain.com/wp-login.php to load, and more than 30 seconds to be redirected to the dashboard.

        This is probably why I set up the 301 redirect in the first place. Our network has 1500+ sites, if that means anything…any other recommendations? Should I open a support ticket? I notice in the Really Simple SSL Netowork Settings that only the most recent 90 sites are listed with http (and a green checkmark) while all previous sites are listed with https – so something clearly happened in a recent update.

        Thanks!

        • Rogier Lankhorst

          Hi Jim,

          Yes, I think we’d better continue this in a support ticket. Otherwise this comment thread might become too long 🙂

          Thanks.

Leave a Comment