Entering a link URL in ckeditor is not consistent with entering a link URL in a Drupal URL field, leading to data entry errors.
Suppose I want to link from page http://www.example.xyz/a/b/c/d to http://www.example.xyz/e (and correspondingly from https://www.example.xyz/a/b/c/d to https://www.example.xyz/e and from http://example.xyz/a/b/c/d to http://example.xyz/e). (These are all examples - don't try to click them.)
When you are presented with an URL field in Drupal, here's how you enter that link:
e
When you are presented with an URL field in ckeditor, here's how you need to enter that link:
/e
If instead, you forget that you need the beginning slash, and just enter
e
Instead of going to
http://www.example.xyz/e or
https://www.example.xyz/e or
http://example.xyz/e
it goes to
http://www.example.xyz/a/b/c/e or
https://www.example.xyz/a/b/c/e or
http://example.xyz/a/b/c/e
which doesn't exist.
It would be much better if ckeditor in Drupal treated URLs the same as Drupal URL fields.
Comments
Comment #1
twodThis is how URLs work everywhere, you must enter the leading / if you want it to be relative to the domain and not the current document location.
Drupal does not really have any URL fields in Core, it explicitly allows inputs of "paths" only - for things like path aliases. With most modules I've seen, unless you're explicitly entering a full absolute URL, anything looking like paths is always prepended with Drupal's base path. CKEditor does not care about the fact that Drupal knows how to turn paths relative to its own installation directory into either full absolute URLs or domain relative internal paths. CKEditor just sees a path when given a path, and will write a path to the generated markup.
We can't change how CKEditor interprets paths or URLs in Wysiwyg module anyway. You'd need some plugin which either replaces or extends the link dialog or some part of the markup generating code.
For linking to Nodes, Views, Panels, or other internal or external paths, I just use LinkIt (with its various extension modules) together with Pathologic.
I configure Linkit to always output the URLs as [unaliased, if possible] domain relative paths like "/node/123" or "/some_view" and have Pathologic treat "/" as an alias for the current domain and it'll render any domain relative path as fully aliased absolute URLs.
Wysiwyg module already does the only thing it can do, which is to set the CKEditor baseHref setting so any relative paths used inside the editor are fetched relative to the current URL rather than what the CKEditor library's best guesstimation is (which is nothing if JavaScript optimization/aggregation is enabled).
Comment #2
charles belovThank you for the recommendations; I'll check them out. One of them should certainly improve the consistency with which staff adds internal links.
That said, I'm not sure what you mean by "Drupal does not really have any URL fields in Core, it explicitly allows inputs of 'paths' only - for things like path aliases." Suppose I, as admin go to https://[myDomain]/admin/structure/types/manage/[myContentType]/fields and add a new field of type Link. Then, as a content creator, I fill in that field with an internal path, I'm supposed to leave off the leading slash.
Comment #3
twodThe Link module adds that field type.
The Link module works pretty same way as Drupal Core though since it just passes what was entered into the
l()function. If it appears to be an absolute external URL, it's not altered. If not, it's expected to be just the path part of an internal URL (everything after your Drupal install root aka the "base path"), then Drupal prepends the base path (which is usually just a "/" unless Drupal was installed in a subfolder) before rendering the link.CKEditor does not know about this behavior at all. It just uses the link href as it was entered.
Comment #4
charles belovRight, but if Link behaves the same way as Drupal core, and Drupal core doesn't work if you type the "/" at the beginning, and ckeditor doesn't work properly if you don't, then that's a usability issue. In any case, I will investigate whether those two modules alleviate the usability issue.
Comment #5
twodStill, there's not really anything we can change about it to make it any better without breaking basic linking capabilities since the editor allows you to link anywhere, while Drupal usually requires internal paths relative to its root for internal use only.
Comment #6
charles belovI suppose it could be an option. That said, you're right, we do have links which are internal to the site but which are outside the Drupal path, and changing it would break that.
Comment #7
twodAn option would be fine, if we could do it. But I don't know how to make any changes to how CKEditor does this without actually modifying CKEditor itself.
If we were to provide an option to change this, it would need to be done by Wysiwyg changing CKEditor's configuration options, or possibly by bundling a native plugin for CKEditor, so the user would not have to [re-]apply any manual file modifications when installing or upgrading the editor library.