Enhance "Insert/edit link" to predict user's intent

[itsalltech1]

Steps to reproduce:

1. Create new post
2. Add some text and highlight the text
3. Click the new link button in the toolbar to bring up the Insert/edit link box
4. In the URL box, remove the default "​http://"
5. Enter in a URL, without the "​http://" at the beginning
6. Click "Add Link"
7. Click on the link button in the toolbar again and check the URL that you just created - it begins with /wp-admin for some reason

Expected results: The URL without ​http:// will still bring you to the correct webpage

[azaozz]

So you delete the http:// part of the URL on purpose and expect it to still work? Why?

[nacin]

I consider this to be a legitimate bug. The expected behavior would be to not prepend anything, even if we have a malformed URL.

[nacin]

Looks like this is the issue of browser DOM behavior:

if ( e = ed.dom.getParent(ed.selection.getNode(), 'A') ) {
	// Set URL and description.
	inputs.url.val( e.href );

Still fixable.

[itsalltech1]

Replying to azaozz:

So you delete the http:// part of the URL on purpose and expect it to still work? Why?

If you delete the ​http:// part in your web browser, does the URL still work? Last time I checked, yes, it does. And what if a writer copy+pastes that URL without an ​http:// into the editor? What happens in that case?

This is definitely a legit bug and should be fixed eventually.

[SergeyBiryukov]

Replying to itsalltech1:

If you delete the ​http:// part in your web browser, does the URL still work? Last time I checked, yes, it does. And what if a writer copy+pastes that URL without an ​http:// into the editor? What happens in that case?

Note that links without http:// are relative, so even if wp-admin is not prepended in the Insert/edit link box, that same link on the front-end will look like this:

http://mysite.com/2011/07/sample-post/www.google.com

[azaozz]

Replying to nacin:

Looks like this is the issue of browser DOM behavior:

Correct, and it depends on the browser used. I'll see if there's a way to avoid this.

Replying to itsalltech1:

If you delete the ​http:// part in your web browser, does the URL still work?

You mean in the browser URL/search bar? Entering a link in HTML document is different from pasting it in the browser search bar. If you enter partial link in a hand written HTML document would you expect it to work? That's why we have the http:// pre-filled in there.

[itsalltech1]

Replying to azaozz:

Replying to nacin:

Looks like this is the issue of browser DOM behavior:

Correct, and it depends on the browser used. I'll see if there's a way to avoid this.

Replying to itsalltech1:

If you delete the ​http:// part in your web browser, does the URL still work?

You mean in the browser URL/search bar? Entering a link in HTML document is different from pasting it in the browser search bar. If you enter partial link in a hand written HTML document would you expect it to work? That's why we have the http:// pre-filled in there.

In the address bar of a web browser, the page will load without using "​http://" Some web browsers will add in ​http:// for you if you didn't put it in, others (for example, Chrome), will remove ​http:// from web addresses automatically. If you're using Chrome and copy+paste a URL from the address bar to the insert link in WordPress, the ​http:// won't be included - you would have to type it in by yourself.

What I suggest is: make it so that you can't remove the ​http:// from the link editor. If you copy+paste a link that includes ​http://, remove it since WordPress already has that. Or, make it so that "​http://" is not highlighted automatically when entering the link editor. Or, just fix the bug directly.

[azaozz]

Replying to itsalltech1:

Unfortunately that will limit the users. Forcing http:// to the front of everything entered there is not a good idea. What if the link is to a secure web site (https://) or the user enters a relative URL?

Replying to nacin:

I consider this to be a legitimate bug. The expected behavior would be to not prepend anything, even if we have a malformed URL.

Actually don't see this. In IE9, FF and WebKit (win7) all entered URLs remain unchanged.

[SergeyBiryukov]

Replying to azaozz:

Actually don't see this. In IE9, FF and WebKit (win7) all entered URLs remain unchanged.

Reproduced in Firefox 5.0/Windows. If you just insert link into the post, the URL remains unchanged, however if you click “Insert/edit link” for the second time, in that window it will be prepended with http://example.com/wp-admin/.

[itsalltech1]

This bug is definitely reproducible in Chrome and Safari.

[SergeyBiryukov]

According to TinyMCE docs, it shouldn't convert relative URLs to absolute when convert_urls is set to false. I wonder why that doesn't work in this case.

[azaozz]

Replying to SergeyBiryukov:

...If you just insert link into the post, the URL remains unchanged, however if you click “Insert/edit link” for the second time, in that window it will be prepended with http://example.com/wp-admin/.
According to TinyMCE docs, it shouldn't convert relative URLs to absolute when convert_urls is set to false. I wonder why that doesn't work in this case.

Probably because the 'wplink' plugin doesn't use the TinyMCE internal methods when editing a link. Will look into it.

[SergeyBiryukov]

Looked into advanced/js/link.js and used ed.dom.getAttrib(e, 'href').

[itsalltech1]

Did that patch work for you? It didn't work for me...still seeing it attached to the /wp-admin address

[SergeyBiryukov]

Yes, it works for me in Firefox 5.0 and Chrome 12.0. Note that in order to use development scripts like wplink.dev.js, you need to add this line to wp-config.php:

define('SCRIPT_DEBUG', true);

​http://codex.wordpress.org/Editing_wp-config.php#Debug

[itsalltech1]

I must be doing something wrong because I had that enabled and I applied the patch, but the issue is still there. I noticed that, when switching to the HTML editor on the new post page, it correctly displays the link (just without the ​http:// part). However, the TinyMCE link editor and the actual post when published display the wrong link.

I'm on WordPress 3.2.1 - does that change anything?

[SergeyBiryukov]

Replying to itsalltech1:

I'm on WordPress 3.2.1 - does that change anything?

Probably not, I've tested the patch on both 3.2.1 and 3.3-trunk.

[SergeyBiryukov]

Until azaozz or another lead dev gives feedback, could we please leave the tag on for proper workflow?

If someone has a different/better solution, feel free to propose.

[WraithKenny]

Just as a note: in Chrome, when copying "www.site.com" from the address bar, the paste will contain "​http://" it's just visually hidden in the browser's bar.

Patch works as expected.

Please see ​http://dev.kenpress.org/2011/07/link-testing/ for a thorough test and results.

Patch does fix the bug nacin pointed out (changing original values). I haven't encountered problems switching between the Visual Editor and HTML.

itsalltech1: I not sure I understand your issue.

1. It sounds like you want <a href="www.example.com">Example Site</a> to work in WP, HTML, and the browser, but it's still an error in all 3. The href="www.example.com" part is always wrong unless you intend to link to a directory named www.example.com on your own site.
2. But perhaps you mean <a href="http://www.example.com">www.example.com</a> to work, in which case (and any case), That does currently work.
3. I believe what you really want is for WordPress to accept and recognize www.example.com as an external url, and convert that into a proper external link while still hiding the protocol everywhere in the UI. This is hard because of the problem of guessing and assuming the user's intent. Did the user really mean to link to a local folder or not? Taking the input literally is the best way to go. Having said that, there is UI feedback for that case: The Link box is pre-populated with http:// as a clue that the protocol should be there.

[WraithKenny]

Since the bug on the ticket is different then the bug fixed by the patch, should the patch be moved to a new ticket?

This ticket itself sounds like either invalid or enhancement. The enhancement would be to attempt to do like Chrome (too problematic by itself), a UI enhancement, or both.

A line of text showing the calculated url, marked up perhaps where the entered data is in bold/dark and the rest in grey. Immediate feedback on the error would then be made apparent.

Also, a check box to distinguish external links from relative, in which (now knowing user intent) would make the Chrome-like (assumed protocol) enhancement possible.

Recommendation: Move the patch to a new ticket (or just committing it), and marking this one as a UI enhancement.

[azaozz]

In [18474]:

Fix URL in wp-link when editing, props SergeyBiryukov, fixes #18149

[azaozz]

Replying to WraithKenny:

This ticket itself sounds like either invalid or enhancement.

Tend to agree with "invalid" except for the URL fix when editing a link.

[itsalltech1]

Replying to azaozz:

Replying to WraithKenny:

This ticket itself sounds like either invalid or enhancement.

Tend to agree with "invalid" except for the URL fix when editing a link.

OK. I don't understand why you have been so against this issue since the beginning. It is certainly a legitimate bug (as others have noted in this ticket) and should be fixed. I'm going to continue to remove the "has-patch" as this issue does NOT have a fix yet.

This isn't a backend issue with WordPress - it's front-end UI and every WordPress user can run into it.

[WraithKenny]

First, removing "has patch" is fine, as the patch fixed a different bug and has nothing to do with your issue. No one put "has-patch" on the ticket to persecute you in any way. It merely marked that there was some code that fixed some bug. It was only applied once. "Others have noted in this ticket" that the fixed bug was a bug, not that your issue itself was a bug. The comments above do list some reasons as to why this ticket could be considered invalid.

I've tried to help and figure out your issue, even listing out 3 possibilities. Please see my list above.

At the core of your issue is that "http://" (or at least "//") is required in a very technical way for the actual technology of the internet (browsers, web protocol, etc.) to work. It has nothing at all to do with WordPress itself. It's absolutely not, in any way, a WordPress bug. As far as I can figure, your issue is a enhancement request.

A possible enhancement to requested is something like the following, "Please include something in WordPress that will protect Users from User Error" as not including "http://" in a link is, in fact, User Error.

Having said that, I've actually been working on a patch that would enhance the feature to address what I assume is your issue. See my proposal above.

If you reread the comments on this ticket you will see that implementing this kind of enhancement is more difficult than it appears. Dealing with user intent, as mentioned above repeatedly, is problematic in ways you don't seem to appreciate. Usually, it is so problematic that it can't be implemented without hurting user experience for everyone else, or it's too burdensome to maintain the added code.

WordPress is built by volunteers. You've asked volunteers to do work writing code to help you out, as you haven't submitted any code, or even suggested an implementation. I've attempted to do so. What I'm trying to say is please use a courteous tone when asking favors.

I can only spend time working on this during lunch breaks and after work as I'm only a volunteer.

After you respond, please remove the "reporter feedback" tag. If I or someone else gets a working patch, I'll reapply the UI or UX feedback and Dev feedback tags as appropriate.

Please also note: Chrome doesn't need the "​http://" specifically because it doesn't have to guess user intent: URLs are always external in that case.

[d4web]

This is a legitimate problem. The "Insert/Edit Link" feature should not alter the original saved URL value.

Currently, a relative path such as "/page/sub-page" is being automatically changed to "​http://domain.com/page/sub-page" when the "Insert/Edit Link" feature is clicked.

Please implement patch in next release if not already done so.

[SergeyBiryukov]

The patch is already committed to trunk, so a relative path is now preserved. The rest of the ticket (dealing with user intent) is an enhancement.

Version number is used to track when the bug was introduced/reported.

[Ipstenu]

I spent the train thinking about this one.

In order to have a patch auto-insert ​http:// to all URLs, we'd have to either make sure the grep checks for <something>.<something> OR completely give up on the concept of using relative URLs.

For .com blogs (and even other managed blog setups), that's a perfectly simple answer. There's nothing installed on your site except WordPress because WP is the be all and end all of your site. But .org doesn't hold by that lockdown so we have to consider the possibility this would break sites if enforced. Also how would it work for people who want to manually create internal TOC with a link of #foobar (obviously the answer there is 'They use HTML and manually insert the URLs' but is that the best answer?).

I think that relative path is a good point for now. See how it plays out in the real world with 3.3 before making a call that has that far reaching implications.

[jane]

We should respect what the user types. Having ​http:// in the field already is a clue to the user that we need the protocol to be explicitly stated. If they delete it, I would expect it to form a link relative to that piece of content, not to wp-admin.

[azaozz]

Wontfix based on the last two comments. The later discovered problem with relative URLs was fixed in [18474].

[SergeyBiryukov]

#25001 was marked as a duplicate.

[iseulde]

Replying to jane:

We should respect what the user types. Having ​http:// in the field already is a clue to the user that we need the protocol to be explicitly stated. If they delete it, I would expect it to form a link relative to that piece of content, not to wp-admin.

I don't agree. Often the user doesn't know they have to add http:// to make their link work. (Yes, even university students.) They don't know what protocols and relative links are. In most cases they'll copy paste a link form the browser over the http:// suggestion and that works fine because the browser adds the right protocol. But next time they copy paste a different link that doesn't have a protocol, they copy paste it over the http:// suggestion and the link breaks. I've seen this countless times. They don't check their links, so they don't notice it. Maybe someone who does notice is good enough to tell them or leave a comment, but most of the time it just stays broken.

Feel free to close this ticket as wontfix again, I just wanted to give it another chance. It seems there's no way to enforce protocols (any protocol) so that there's still the option to insert a relative link. What about a warning? Or what about a checkbox "this is a relative link"?

[knutsp]

I have to agree with avril here. I see a lot of broken links like ​http://mysite.com/example.com/article-name/

A checkbox with label like "Allow relative URL", and if not ticked then http:// or https:// should be prepended when needed, or a warning with Ok/Cancel should be issued before the link is accepted/rejected.

[helen]

Replying to knutsp:

A checkbox with label like "Allow relative URL", and if not ticked then http:// or https:// should be prepended when needed, or a warning with Ok/Cancel should be issued before the link is accepted/rejected.

The chances of somebody who doesn't know that they need a protocol before a non-relative URL understanding what "Allow relative URL" means seem extremely low.

[knutsp]

Replying to helen:

Replying to knutsp:

A checkbox with label like "Allow relative URL", and if not ticked then http:// or https:// should be prepended when needed, or a warning with Ok/Cancel should be issued before the link is accepted/rejected.

The chances of somebody who doesn't know that they need a protocol before a non-relative URL understanding what "Allow relative URL" means seem extremely low.

They doesn't need to know. It should be unchecked by default. Then WordPress may add http://, or issue a warning, for those who doesn't know what they are doing.

The checkbox will only be there for those who know they want to add a relative URL, without the need for a protocol prefix. It may also add the phrase "Leave unchecked if you don't know what this means". With the box checked the add ink feature will work as before.

[helen]

If we need that much explanatory text, then it is not a solution. Going to go ahead and call a checkbox not a viable option. By all means, brainstorm, but perhaps down a different path, like detection or something.

[knutsp]

I don't think the explanatory text to the checkbox is needed at all. I mentioned it to make a point. Users usually doesn't select options the don't understand, but leave it as is.

Without a checkbox, it will be hard to detect or guess if a link like foo.bar is a host name or a local path.

Another way is simply doing it like the WordPress (removed) Link Manager - Add new Link already does this, by not allowing relative URLs without a protocol (scheme component). http:foo and http:/foo is accepted as a valid relative, and root relative, URLs by browsers I know.

In Link Manager input foo automatically becomes http://foo upon save, but http:foo is accepted as is. At some point in WordPress history someone made a decision about this. May still be good.

[iseulde]

I think the chances that somebody needs a relative url are extremely low as well. I actually don't see any reason why anyone would use these. The chances of somebody accidentally submitting a relative url are much higher.

I'd use something like '^(' + allowedprotocols.join('|') + '):|^#' and if it doesn't match show a warning or automatically add http://. What about //? :)

[Ipstenu]

Why not have it grab whatever the default protocol for the site is? That is, if the site's https, use that.

[SergeyBiryukov]

We could probably always add the protocol if it's missing, unless the link starts with /. So if you want to add a relative link, it must be relative to the root.

[iseulde]

Good idea, then we could match links starting with a dot as well.
So if it doesn't match '^([a-z]+:|#|\\?|\\.|\\/)', add the current protocol.
And if anyone wants to link to page, they should use ./page instead.
The only thing that goes through now are links with a port number, so not sure if it's best to check against [a-z]+ or whitelisted protocols.

[WraithKenny]

I think prohibiting "Document relative" links in this particular UI widget is the right way to go. If it is needed, it can be added, just not through this widget.

WordPress has a list of approved protocols in the kses somewhere. We could use that (or the simpler above js methods) to detect if the link is an absolute link, and check for "/" and "#" for root relative links and anchor links. If a link is none of those, prepend double "/".

I would advocate using the double "/" 'protocol relative' linking scheme as it effectively does the same thing as grabbing the current protocol, except it does it dynamically on the client side. It's more robust, dynamic and stable then injecting it into the content.

[iseulde]

#28565 was marked as a duplicate.

[iseulde]

​https://wordpress.org/about/philosophy/#majority

[ryan]

Some conversation here: ​https://make.wordpress.org/core/2015/03/02/this-week-in-4-2-march-2-8/#comment-25337

[iseulde]

I'll try to make anther patch which will allow you to change it back if our guess is 'wrong'.

[azaozz]

In 31602:

wpLink:

• Prepend '​http://' to pasted URLs.
• Do not prepend it when typing an URL.
• Do not prepend it when pasting the same URL for the second time (trying to correct wrong guess).

Props iseulde. Fixes #18149.

[azaozz]

In 31606:

wpLink: fix the logic for prepending http:// and trim the input.
Props iseulde. See #18149.