[wp-trac] [WordPress Trac] #42730: Allow wp_enqueue_scripts() for URLs with parameters

WordPress Trac noreply at wordpress.org
Wed Nov 29 12:07:27 UTC 2017


#42730: Allow wp_enqueue_scripts() for URLs with parameters
---------------------------+-------------------------
 Reporter:  MattyRob       |       Owner:
     Type:  defect (bug)   |      Status:  closed
 Priority:  normal         |   Milestone:
Component:  Script Loader  |     Version:
 Severity:  normal         |  Resolution:  invalid
 Keywords:                 |     Focuses:  javascript
---------------------------+-------------------------

Old description:

> I have noticed that when using `wp_register_script()` and
> `wp_enqueue_script()` functions that the URL of the scripts is escaped
> before output.
>
> This causes issues if the URL contains parameters, for example
> `https://api.ipify.org?format=jsonp&callback=getip`. This gets turned
> into `https://api.ipify.org?format=jsonp#038;callback=getip` and results
> in failure of the script.
>
> I think I've tracked this down to the `do_item()` function of the wp-
> includes/class.wp-scripts.php file. In here the `script_loader_src `
>  is called on 2 occasions, once the returned value is left unescaped and
> once it is passed through `esc_url()`. It is the latter application of
> the filter that escapes the ampersand and breaks the URL to the
> javascript file.
>
> Should the call to the `esc_url()` be removed to allow parameters in the
> URLs or is there another way to '''enqueue''' such scripts that I have
> not yet found (currently I'm just hooking to wp_head and echoing the
> script).

New description:

 I have noticed that when using `wp_register_script()` and
 `wp_enqueue_script()` functions that the URL of the scripts is escaped
 before output.

 This causes issues if the URL contains parameters, for example
 `https://api.ipify.org?format=jsonp&callback=getip`. This gets turned into
 `https://api.ipify.org?format=jsonp#038;callback=getip` and results in
 failure of the script.

 I think I've tracked this down to the `do_item()` function of the wp-
 includes/class.wp-scripts.php file. In here the `script_loader_src` is
 called on 2 occasions, once the returned value is left unescaped and once
 it is passed through `esc_url()`. It is the latter application of the
 filter that escapes the ampersand and breaks the URL to the javascript
 file.

 Should the call to the `esc_url()` be removed to allow parameters in the
 URLs or is there another way to '''enqueue''' such scripts that I have not
 yet found (currently I'm just hooking to wp_head and echoing the script).

--

Comment (by SergeyBiryukov):

 Replying to [comment:2 MattyRob]:
 > It seems my library is queuing correctly - it just looks weird in the
 source when you check back to make sure it's queued right.

 Right, the encoded ampersand won't work in the address bar, but should
 work as expected in the page source.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42730#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list