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

7 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.

      • Rogier Lankhorst

        Hi Matt, maybe you can fix this by adding a cors header: http://enable-cors.org/server.html. In apache this would look something like this:
        Header set Access-Control-Allow-Origin “*”

        • 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

Leave a Comment