#22946 closed defect (bug) (wontfix)
Default filter erroneously turns FTP hostnames into HTTP links
Reported by: | DavidAnderson | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 2.0.4 |
Component: | Formatting | Keywords: | close has-patch |
Focuses: | Cc: |
Description (last modified by )
The function _make_web_ftp_clickable_cb in wp-includes/formatting.php is invoked upon any hostname matching "www." or "ftp." at the beginning. It pre-pends 'http://' and makes the link clickable (i.e. wraps it in <a href="">).
As a default that makes sense for things beginning www. - but not for everything beginning ftp.
In my case, I was using the plugin WP Better Emails, and sent out an email with this line (approx):
Here is the FTP server: ftp.example.com
WP, by default, "helpfully" totally mangles this into:
Here is the FTP server: <a href="http://ftp.example.com">http://ftp.example.com</a>
The recipient of my email now believes that I was sending him an HTTP link, and is confused that it does not work. But in fact I never sent such a link - that was WordPress mangling what I did send.
Sure, some FTP servers will also have HTTP listening. But by default WordPress assumes that they all do, which is crazy.
Proposed solution: on line 1471 of wp-includes/formatting.php (as found in 3.4.2), change:
$ret = preg_replace_callback( '#([\s>])((www|ftp)\.[\w\\x80-\\xff\#$%&~/.\-;:=,?@\[\]+]+)#is', '_make_web_ftp_clickable_cb', $ret );
by removing the "ftp" case, hence:
$ret = preg_replace_callback( '#([\s>])((www)\.[\w\\x80-\\xff\#$%&~/.\-;:=,?@\[\]+]+)#is', '_make_web_ftp_clickable_cb', $ret );
The function _make_web_ftp_clickable_cb should then be renamed by removing ftp_, since the case of turning FTP hostnames into clickable HTTP links would have been removed.
Attachments (1)
Change History (14)
#2
@
12 years ago
- Component changed from General to Formatting
- Description modified (diff)
- Version changed from trunk to 2.0.4
Related: [4011]
#5
@
11 years ago
- Keywords close added
This was added in [4011] and I can't find any other reports of this being an issue. I've looked at this bug before, and my conclusion seems to remain the same. It seems to me like it is better to assume that the server is accessible over HTTP than that it isn't.
#6
follow-up:
↓ 7
@
11 years ago
If the server is accessible via HTTP, why would the system administrator add "ftp." to the beginning of the host name? Normal convention is that "www." or more recently no prefix indicates HTTP whereas "ftp." suggests FTP.
The notes here and over at #23048 seem clear to me. I can prepare and test a simple patch if you like. No big deal, but as it stands the code results in irritating behaviour for users and the fix seems easy.
#7
in reply to:
↑ 6
@
11 years ago
Replying to mdgl:
Normal convention is that "www." or more recently no prefix indicates HTTP whereas "ftp." suggests FTP.
But subdomains also exist, and "ftp" is certainly a valid subdomain. Could represent something other than "File Transfer Protocol."
I'm fine with admitting my assumptions are wrong here, but it seems to me that there are three possibilities...
- ftp.example.com is a legitimate website
- ftp.example.com is an FTP server with an HTTP viewer
- ftp.example.com is an FTP server without an HTTP viewer
Now, I have no idea how common it is for an FTP server to serve up HTTP traffic, but it sounds to me more common than to not listen over HTTP at all. I did some cursory searches and couldn't find an FTP server that didn't serve up an Apache directory listing.
The status quo seems to cover the current state of things quite nicely. I mean, let's face it, public FTP doesn't exactly see mainstream usage these days. It's clunky and annoying to use. (One way to make it nicer to use is to allow people to at least browse it via HTTP — but I digress.) Maybe we could just not link them at all. I don't know. To be honest, I don't care much either way, and that's in part because going back eight years, no one else has reported this, either.
#8
@
11 years ago
My view is that the order of preference should be:
1) Do nothing
2) Link ftp. hostnames via ftp://
3) Link ftp. hostnames via http://
i.e. I think the present situation is the worst of the 3 options.
I don't think it's relevant that most hostnames will give you *something* back if you try to access the same host via http. I think that just indicates that IP addresses are a limited comodity and aren't being wasted. The choice of "ftp." in the hostname surely indicates *something* - and if it indicates anything, then it's indicating File Transfer Protocol.
To gather some data as to how other programs handle this, I typed in the name of my FTP server with no protocol (i.e. like ftp.example.com) into each of Chrome, Firefox and Opera. All three decided to use the FTP protocol (i.e. auto-converted to ftp://ftp.example.com).
#9
@
11 years ago
- Gmail on both Android and Desktop also follow the strategy of always prefixing with http://
- ftp.microsoft.com is a good example of a FTP-only server, while ftp.snt.utwente.nl was the first I found that does both.
- HTTP Viewers for FTP domains are a better user experience for most users
- Browsers don't do smart-detection of url's, they just automatically use FTP for a url prefixed with 'ftp.' which I find pretty bad UX.. they should at least re-try over HTTP if they've made that assumption.. but that's beside the point.
Coming into this I also agreed that the current behaviour is the best default, if it looks like a hostname and it's lacking a protocol, assume HTTP.
Based on browser behaviour though, I'm tempted to suggest that prefixing with ftp:// might be a better option - even if FTP is falling out of use in the modern web.
#10
@
11 years ago
- Keywords has-patch added
Patch added to convert apparent URLs beginning "ftp." to hyperlinks using FTP rather than HTTP.
In testing, I noticed that TinyMCE also converts such strings to hyperlinks automatically when you create or edit a post/page. For strings beginning "ftp.", TinyMCE creates a FTP hyperlink, the same as most browsers.
With this patch, WordPress now behaves more consistently when displaying comments.
#11
@
10 years ago
- Resolution set to wontfix
- Status changed from new to closed
Seems to be several reasons to close this ticket:
- make_clickable() is only hooked to the comment_text filter.
- Filters can be easily modified or disabled.
- The ticket describes a plugin bug.
- Linking to domain names is not incorrect.
- There are no comments above in favor of changes or the patch.
#12
follow-up:
↓ 13
@
10 years ago
- Milestone Awaiting Review deleted
If you don't want http://
to be prepended to an FTP-only hostname, just add ftp://
:
Here is the FTP server: ftp://ftp.example.com
#13
in reply to:
↑ 12
@
10 years ago
I think this misses the point... the filter is automatically making things clickable.
e.g. Someone poster on a site adds a comment "Hey guys, just use this FTP server: ftp.example.com".
make_clickable() will then, via the *default* filter, turn that into: http://ftp.example.com - and the people reading the comment will click and be sent to a website.
Commenters on a website can't be expected to know about the internal habits of WordPress in this kind of thing. WordPress should either not automatically make it clickable, or should assume that the ftp. is indicating the FTP protocol, not the HTTP protocol. A default assumption that ftp. indicates HTTP protocol just makes no sense.
I don't know but isn't the idea to turn sites whose name starts with the string "ftp." into clickable links using the
ftp
protocol (e.g.ftp://ftp.example.com
)? Most browsers seem to handle this kind of thing just fine.