wp-polyfill-formdata not found for subdirectory install

[bobbingwide]

In 5.0-RC2, without Gutenberg, using Edge, I get a 404 for /wp-includes/js/dist/vendor/wp-polyfill-formdata.min.js when loading a post with the File block.

With Gutenberg the script tags src parameter is fully qualified
e.g. https://s.b/oikcom/wp-includes...

With 5.0-RC2 it's not.

Here's some HTML from 5.0-RC1

<script type='text/javascript' src='https://q.w/hm/wp-includes/js/dist/vendor/wp-polyfill.min.js?ver=7.0.0'></script>
<script type='text/javascript'>
( 'fetch' in window ) || document.write( '<script src="/wp-includes/js/dist/vendor/wp-polyfill-fetch.min.js"></scr' + 'ipt>' );( document.contains ) || document.write( '<script src="/wp-includes/js/dist/vendor/wp-polyfill-node-contains.min.js"></scr' + 'ipt>' );( window.FormData && window.FormData.prototype.keys ) || document.write( '<script src="/wp-includes/js/dist/vendor/wp-polyfill-formdata.min.js"></scr' + 'ipt>' );( Element.prototype.matches && Element.prototype.closest ) || document.write( '<script src="/wp-includes/js/dist/vendor/wp-polyfill-element-closest.min.js"></scr' + 'ipt>' );
</script>

[ocean90]

45469.patch​ should fix this.

[swissspidy]

45469.diff​ takes a different approach by properly registering the scripts in the first place.

[bobbingwide]

I think I prefer @ocean90's.

[gziolo]

What about packages? They are registered exactly the same as vendor scripts:

<?php
$path    = "/wp-includes/js/dist/$package$suffix.js";
...
$scripts->add( $handle, $path, $dependencies, $version, 1 );

Shouldn't we ensure that the path is properly constructed for both types of scripts?

[swissspidy]

@gziolo You mean in wp_default_packages_scripts(). That should be covered by \WP_Scripts::do_item(), which automatically adds the base URL if it's a relative path.

With that being said, 45469.patch​ is more similar to \WP_Scripts::do_item() in that regard.

However, if someone uses wp_get_script_polyfill() with their own scripts, it would just needlessly append the base URL.

This could be solved by always assuming the src is a full URL (like 45469.diff​ does) or by using the same regex as \WP_Scripts::do_item().

Plus, we should probably add ?ver as well for cache busting.

See 45469.2.diff​ for another approach.

[gziolo]

@gziolo You mean in wp_default_packages_scripts(). That should be covered by \WP_Scripts::do_item(), which automatically adds the base URL if it's a relative path.

Do you see an easy way to extract shared logic into its own function? At least the following is almost the same for both functions:

<?php
if ( ! preg_match( '|^(https?:)?//|', $src ) && ! ( $content_url && 0 === strpos( $src, $content_url ) ) ) {
        $src = $base_url . $src;
}

if ( ! empty( $ver ) )
        $src = add_query_arg( 'ver', $ver, $src );

/** This filter is documented in wp-includes/class.wp-scripts.php */
$src = esc_url( apply_filters( 'script_loader_src', $src, $handle ) );

[ocean90]

45469.2.diff​ looks good to me.

[pento]

The copy/paste is kind of crufty, let's get that fixed up after 5.0. 45469.2.diff​ is the least invasive option for now, though.

[pento]

In 43960:

Scripts: Ensure sub-directory WordPress installs can load polyfill scripts.

wp_get_script_polyfill() bypasses WP_Scripts::do_item(), so didn't transform the script path into its fully qualified URL.

Props swissspidy, ocean90.
See #45469.

[swissspidy]

The copy/paste is kind of crufty, let's get that fixed up after 5.0.

Totally, that's what @gziolo and I have been chatting about as well.

A new prepare_src() method could be introduced for that. Can create a new ticket for this though.

[SergeyBiryukov]

In 44286:

Scripts: Ensure sub-directory WordPress installs can load polyfill scripts.

wp_get_script_polyfill() bypasses WP_Scripts::do_item(), so didn't transform the script path into its fully qualified URL.

Props swissspidy, ocean90.
Merges [43960] to trunk.
Fixes #45469.