multisite configuration

[yangkennyk]

I have the setup working with the primary site but it seems like the dev server isn't loading scripts/styles on sub sites in my multisite set up.

how can I set it up so it loads my multisites as well?

[yangkennyk]

the issue seems that webpack is trying to load from the sub folder domains and can't connect

the main site loads fine with https://mylocalhost/wp-content/themes/mytheme/dist/app/main.js?ver=1.0.0

but when I go to a subsite it 404's https://mylocalhost/subsite/wp-content/themes/mytheme/dist/app/main.js?ver=1.0.0

I think I just have to tweak the nginx or proxy rules but can't quite seem to figure it out.

I'm using local by flywheel as my dev server.

[TullariS]

Hey @yangkennyk

I'm having the exact same problem. I believe the issue should be solved on the dev server code (probably pass a regex distPublicPath instead of a string).

In the meantime, I've come up with a workaround. Hope this helps you too:

1. Set the distPublicPath back to undefined
2. Make a class to extend WPackio\Enqueue and instance that class instead
3. Add the following method to your class:

public function getUrl( $asset ) {
    $url =  parent::getUrl($asset);

    if(is_multisite()){
        $currentUrl = get_site_url();
        $baseUrl = get_site_url(BLOG_ID_CURRENT_SITE);

        if($currentUrl !== $baseUrl && strpos($url, $currentUrl) === 0){
            $url = $baseUrl . substr($url, strlen($currentUrl));
        }
    }

    return $url;
}

[swashata]

@TullariS great workaround. Does it work on both development and production? I have totally forgotten how WordPress plugins_url works for multisite. Would love to have you digging around it a bit 😄

[TullariS]

Ah that's a good point.

The default rewrite script does allow for plugin/theme assets from being server both on a base url (http://site.com/wp-content/...) or one of the sites of the network (http://site.com/wp-content/blog/...). As long as this isn't changed, it should work on both development and production.

That being said, this solution is not ideal, but it does help out during development. Maybe after you are done, comment it out. Hopefully once this issue is addressed (within the development server script) we can get rid of it altogether.