Investigate compatibility with WPML, Polylang, etc

[westonruter]

When a translation plugin forces the home_url() to have a language-specific prefix, this could cause problems for the start_url in the web app manifest and also the service worker URL.

See https://wordpress.org/support/topic/compatibility-with-wpml-70/

[westonruter]

This came up again with the WPGlobus plugin: https://wordpress.org/support/topic/does-not-display-9/

The start_url in the manifest is incorrectly using a locale-specific subdirectory, and the service worker is incorrectly being installed from that subdirectory as opposed from the root.

[westonruter]

One possibility would be to use the site_url() as opposed to the home_url(). But this may have other unintended consequences (like pointing to another domain entirely). We could discard the hostname, however. What we need is to identify the path to the root of where WordPress is installed. We need to take care for subdirectory installs and subdirectory multisite configurations.

[westonruter]

Perhaps instead of home_url() a safer bet would be to use wp_parse_url( site_url( '/' ), PHP_URL_PATH ).

[westonruter]

No, that won't work either. When WordPress core is installed in a subdirectory that is different than the site root, this would result in something like /wordpress/ being the path.

[westonruter]

Perhaps what is needed is the logic from get_home_url() but omit the apply_filters( 'home_url', $url, $path, $orig_scheme, $blog_id ). For example:

$url = trailinglsashit( set_url_scheme( get_option( 'home' ), 'https' ) );

[westonruter]

@lkraav Would you give this fix a try: #266 (comment)

Instead of bypassing the home_url filter, the easier (and safer) fix seems to be to consistently use the relative scheme when invoking home_url() for both the script src and the service worker scope.

[westonruter]

Apparently it's still not working properly with Polylang: https://wordpress.org/support/topic/nothing-has-changed-after-installation/