Provide matcher for external URLs missing protocol

Attached patch provides simple matcher called "External" that does a str_starts_with($string, 'www') check and suggests adding "https://"

This idea seems very reasonable as an enhancement for content editors who aren't experts in HTML/HTTP, and doesn't seem like it would add much complexity to the functionality. I'll review further!

The patch works fine for 6.1.x.

The last submitted patch, 2: 3423212-1.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

I'm wondering whether the current implementation, which will only suggest external URLs if the string starts with "www," could be broadened to cover more scenarios. (What if someone types "example.com"?)

What about the following logic?
1. If the string starts with http or contains ://, do not suggest anything.
2. If, on the other hand, after prepending https:// to the string, the result validates as a URL, suggest adding https://

This proposal is captured in the merge request.

It would also be good to add test coverage...

Test coverage added! (Note that tests are currently failing on HEAD with Drupal 10.2.3, due to 🐛 Add test coverage for rel and target settings Fixed ; that is unrelated to this proposed code change.)

I first looked into using filter_var, but the main reason I used a simple str_starts_with is because I couldn't get filter_var to ignore the protocol, but I guess slapping the protocol in front and then matching is a much better approach.
The current approach does however fail with unicode TLDs like Brahmic, Cyrillic, Arabic, Hebrew, Chinese, Greek, etc. (see https://onlinephp.io/c/7d21f extracted from https://en.wikipedia.org/wiki/Internationalized_domain_name), but I guess those URLs are unlikely to start with "www" anyway.

The current approach does however fail with unicode TLDs like Brahmic, Cyrillic, Arabic, Hebrew, Chinese, Greek, etc.

Yes, I'd read about that shortcoming of PHP's filter_var, too. I might suggest we leave that as a potential enhancement, rather than work on logic to handle unicode TLDs here. We could add a @todo inline to document the limitation?

Oh yeah, I didn't mean it as a blocker, I was just trying to justify my arguably poor implementation 😅
This is already a great improvement and I don't see anything that would warrant blocking it.

Automatically closed - issue fixed for 2 weeks with no activity.