Typing drupal.org or example.com as the link will result in
<a href="drupal.org>something</a>
That's an invalid link.
See above.
Default schemeless links to https:// using https://ckeditor.com/docs/ckeditor5/latest/features/link.html#adding-def...
Resulting UX:
Review.
Schemeless links get https:// prefixed automatically.
None.
None.
When typing URLs like "example.com/interesting-page", the missing protocol (https://) will be added automatically.
| Comment | File | Size | Author |
|---|---|---|---|
| #23 | link-default-protocol.gif | 77.5 KB | wim leers |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !6969
Comments
Comment #2
lee.cocklin commentedComment #3
anonThis is rather an issue of the default Drupal Link plugin. Linkit only extends that.
Comment #4
wim leersThanks, @anon, for moving this to Drupal core's issue queue.
This is clearly a usability problem. We could add some detection logic in
\Drupal\editor\Form\EditorLinkDialog::submitForm(), to automatically prefix the URL with a protocol:http://orhttps://. But which of the two? How can we reliably guess? Should we perform a request?The developer answer would be "just type the protocol", but that's of course not very usable. Not sure yet how to proceed here.
Comment #5
anonI didn't even think about the http vs https. That is a hard one.
Just to perform a request wouldn't be a 100% solution. Both protocol can exists at the same time, and even link to two different targets.
To force the user to add the protocol if the "link" seems like a URI is not an option either in my mind, as entity URIs actually can be something like /www.something.com as in (http:example.com/www.something.com)
Comment #6
wim leersAgreed with every one of your points!
Comment #9
ainarend commentedStumbled upon this today via a client request.
Could a possible solution be that we don't force either http or https, but we simply add '//' and making it a protocol-relative URL, so forcing the browser to use whichever protocol was used to load the page.
Just tested it and it resolved the issue of having /google.com links and now instead the browser itself managed to do the proper protocol detection and created a correct link.
This should fix the site builder/editor's problem for 99% of the cases if i am not missing something.
Comment #14
matroskeenMoving forward #9 would probably require #2744729: Link field should accept protocol-relative URLs.
Comment #17
aaronbaumanI think we're overthinking it here.
* There's a huge SEO penalty for http:
* Nearly every website will resolve over https
* When not a single browser requires users to type a protocol, this is already a significant usability problem
Seems like "default to https" would be a good enough solution for 9/10 cases, and if it doesn't work the user can manually enter http:// to fix it.
Comment #19
chucksimply commented#17 - exactly
Comment #20
gagarine commented"Let's overengineering" is the tagline of Drupal.
Comment #23
wim leersDefinitively outdated since #3306584: [11.x] Remove EditorLinkDialog, EditorImageDialog and EditorMediaDialog in Drupal 11.
But … also still an issue with CKEditor 5. I just tried it and was able to reproduce the same problem.
Fortunately, they have infrastructure in place that makes it easy to achieve this: https://ckeditor.com/docs/ckeditor5/latest/features/link.html#adding-def...
This is so absurdly low-hanging fruit that I immediately created a merge request and screencast for it. It's 2 lines of code. IMHO it doesn't even need tests, because the CKEditor 5 team obviously is testing this already.
Comment #24
aaronbaumanThat's great, thanks for the MR.
Surprised ckeditor doesn't have a default value in the first place, and agree that it would be silly to add test coverage for a 3rd party library.
Anyone know if there's a similar issue open for the link widget already?
That's another super annoying UX / validation constraint when protocol is missing.
Comment #28
nod_Fixing a 7 years old issue is nice, especially with a diff that's 4 lines
Committed e84fc60 and pushed to 11.x. Thanks!