I noticed that when $source refers to a relative URL, the value retur…

[davejesch]

…ned from parse_url() is false. This causes a Deprecated warning message to be displayed when strpos() is called a few lines later. This change avoids that issue and reduces non-fatal messages from being displayed.

[afragen]

What about changing isset( $parsed ) to ! empty( $parsed )?

[norcross]

how about adding an http (or https) on the URL if it’s missing, then proceed as it is now?

[davejesch]

An example of a URL that's causing this is:
///wp-includes/js/jquery/jquery.js
It's not a missing protocol, just a relative URL - no host name specified. So prefixing with http(s) won't change anything.

empty() returns a true on empty strings as well as integer, float and string '0'/zero values. So it's a bit inaccurate in some cases. If, somehow, the domain name is '0' (unlikely, I know, but...) it'll think it's empty when it isn't. That's why I'm suggesting the change submitted. :)

[norcross]

is this potentially happening anywhere else? (maybe stylesheets as well)

@johnbillion thoughts?

[davejesch]

Yes, it looks like it could be happening in block_style_load() as well but I haven't seen any deprecated warnings in the log file from that.

[johnbillion]

Where are those three leading slashes on the URL coming from?

[davejesch]

I don't know. It could be from the theme (Astra on this test site). I didn't dig too deep on that since it's not affecting the call to parse_url() itself.

[norcross]

ok i'm aware this is over a year old and i'm gonna blame the pandemic.

doing some quick testing, i'm finding that a relative URL correctly using two slashes (//wp-includes/..) will give me a string i can check for. but one with three slashes (///wp-includes/js/jquery/...) returns false, since it can't be parsed.

so was that 3rd slash a typo, or was that actually the attempted URL to load? because wp_enqueue_script wouldn't even load that file correctly.