WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 8 months ago

#18149 reopened enhancement

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

Reported by: itsalltech1 Owned by: azaozz
Milestone: Awaiting Review Priority: normal
Severity: minor Version: 3.1
Component: Editor Keywords: 2nd-opinion
Focuses: Cc:

Description

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

Attachments (1)

18149.patch (667 bytes) - added by SergeyBiryukov 3 years ago.

Download all attachments as: .zip

Change History (51)

comment:1 follow-up: azaozz3 years ago

  • Keywords needs-patch removed
  • Milestone Awaiting Review deleted
  • Priority changed from normal to lowest
  • Resolution set to wontfix
  • Severity changed from normal to trivial
  • Status changed from new to closed
  • Type changed from defect (bug) to enhancement

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

comment:2 follow-up: nacin3 years ago

  • Component changed from General to Administration
  • Keywords needs-patch added
  • Priority changed from lowest to normal
  • Resolution wontfix deleted
  • Severity changed from trivial to minor
  • Status changed from closed to reopened
  • Type changed from enhancement to defect (bug)
  • Version changed from 3.2.1 to 3.1

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

comment:3 nacin3 years ago

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.

comment:4 in reply to: ↑ 1 ; follow-up: itsalltech13 years ago

  • Keywords 2nd-opinion added
  • Severity changed from minor to normal

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.

comment:5 nacin3 years ago

  • Keywords 2nd-opinion removed

comment:6 in reply to: ↑ 4 SergeyBiryukov3 years ago

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

comment:7 follow-up: azaozz3 years ago

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.

Last edited 3 years ago by azaozz (previous) (diff)

comment:8 in reply to: ↑ 7 itsalltech13 years ago

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.

comment:9 in reply to: ↑ 2 ; follow-up: azaozz3 years ago

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.

Last edited 3 years ago by azaozz (previous) (diff)

comment:10 azaozz3 years ago

  • Keywords close added; needs-patch removed

comment:11 in reply to: ↑ 9 ; follow-up: SergeyBiryukov3 years ago

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/.

comment:12 itsalltech13 years ago

  • Keywords needs-patch added; close removed

This bug is definitely reproducible in Chrome and Safari.

comment:13 SergeyBiryukov3 years ago

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.

comment:14 in reply to: ↑ 11 azaozz3 years ago

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.

SergeyBiryukov3 years ago

comment:15 SergeyBiryukov3 years ago

  • Keywords has-patch added; needs-patch removed

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

comment:16 itsalltech13 years ago

  • Keywords needs-patch added; has-patch removed

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

comment:17 SergeyBiryukov3 years ago

  • Keywords has-patch added; needs-patch removed

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

comment:18 follow-up: itsalltech13 years ago

  • Keywords needs-patch reporter-feedback dev-feedback added; has-patch removed

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?

comment:19 in reply to: ↑ 18 SergeyBiryukov3 years ago

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.

comment:20 SergeyBiryukov3 years ago

  • Keywords has-patch added; needs-patch removed

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.

comment:21 SergeyBiryukov3 years ago

  • Milestone set to 3.3

comment:22 WraithKenny3 years ago

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.
Last edited 3 years ago by WraithKenny (previous) (diff)

comment:23 follow-up: WraithKenny3 years ago

  • Cc Ken@… added

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.

comment:24 WraithKenny3 years ago

  • Component changed from Administration to UI
  • Keywords ux-feedback added

comment:25 azaozz3 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from reopened to closed

In [18474]:

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

comment:26 in reply to: ↑ 23 ; follow-up: azaozz3 years ago

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.

comment:27 in reply to: ↑ 26 itsalltech13 years ago

  • Keywords has-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:28 WraithKenny3 years ago

  • Keywords dev-feedback ux-feedback removed
  • Severity changed from normal to minor
  • Summary changed from Removing "http://" in Insert/edit link causes incorrect URL to Enhance "Insert/edit link" to predict user's intent
  • Type changed from defect (bug) to enhancement

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.

comment:29 d4web3 years ago

  • Keywords has-patch 2nd-opinion dev-feedback added
  • Severity changed from minor to normal
  • Type changed from enhancement to defect (bug)
  • Version changed from 3.1 to 3.2.1

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.

Last edited 3 years ago by d4web (previous) (diff)

comment:30 SergeyBiryukov3 years ago

  • Keywords has-patch dev-feedback removed
  • Severity changed from normal to minor
  • Type changed from defect (bug) to enhancement
  • Version changed from 3.2.1 to 3.1

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.

comment:31 SergeyBiryukov3 years ago

  • Keywords ui-feedback added; reporter-feedback removed
  • Milestone changed from 3.3 to Future Release

comment:32 Ipstenu3 years ago

  • Cc ipstenu@… added

comment:33 ericmann3 years ago

  • Cc eric@… added

comment:34 Ipstenu3 years ago

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.

comment:35 sabreuse2 years ago

  • Cc sabreuse@… added

comment:36 follow-up: jane2 years ago

  • Keywords ui-feedback removed

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.

comment:37 azaozz22 months ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

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

comment:38 SergeyBiryukov8 months ago

#25001 was marked as a duplicate.

comment:39 in reply to: ↑ 36 avryl8 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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"?

Last edited 8 months ago by avryl (previous) (diff)

comment:40 SergeyBiryukov8 months ago

  • Component changed from UI to Editor
  • Milestone set to Awaiting Review

comment:41 follow-up: knutsp8 months ago

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.

comment:42 in reply to: ↑ 41 ; follow-ups: helen8 months ago

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.

comment:43 in reply to: ↑ 42 knutsp8 months ago

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.

comment:44 helen8 months ago

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.

comment:45 knutsp8 months ago

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.

comment:46 in reply to: ↑ 42 avryl8 months ago

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 //? :)

comment:47 Ipstenu8 months ago

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

comment:48 SergeyBiryukov8 months ago

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.

comment:49 avryl8 months ago

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.

Last edited 8 months ago by avryl (previous) (diff)

comment:50 WraithKenny8 months ago

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.

Note: See TracTickets for help on using tickets.