This very simple patch lets you add external URLs to your menu or wherever, 'cos I patched url() itself.

Please consider for 4.6.

CommentFileSizeAuthor
#4 externalurl_1.patch480 byteschx
#3 externalurl_0.patch571 byteschx
externalurl.patch448 byteschx

Comments

morbus iff’s picture

Too naive, IMO. Needs ftp, nntp, irc, aim, blah blah blah.

morbus iff’s picture

Oh, and mailto.

chx’s picture

StatusFileSize
new571 bytes

and e2dk or whatever. A path is external if a) it begins with mailto: b) method: followed by a slash. method is loosely defined as a sequence of any characters but slash. This will evaluate a Drupal path foor:bar/this/that external. However trackerpage/http://whatever has a slash before the : so it will be an internal URL.

chx’s picture

StatusFileSize
new480 bytes

Oh, bad patch version :( again :(

asimmonds’s picture

I'm fairly certain external URLs already work in with url() if you have Clean URLs enabled.

IMO http://drupal.org/node/10888 is a cleaner solution for people who can't use Clean URLs.

syscrusher’s picture

I don't know if this will help you, but here's some with a pregexp patch that I wrote to handle this problem for a contrib add-on (field_url.inc) for the CVS version of Flexinode. Perhaps you can adapt this to work in your situation:

function flexinode_field_url_format($field, $node, $brief = 0) {
  $fieldname = 'flexinode_'. $field->field_id;
  $output = drupal_specialchars($node->$fieldname);
  if (strlen($output) && ! preg_match('%^(\w+://|\w*/)%',$output)) {
    $output = 'http://' . $output;
  }
  return $output ? '<a href="'. $output .'">'. $output .'</a>' : '';
}

The regular expression works with any arbitrary protocol spec, because it will match any "word class" character. So http, mailto, ftp, irc, and so on will all be matched properly.

People who helped test this for me as I contributed to the Flexinode team found no bugs; everyone who tested it reported that it worked as intended, though of course I can't say it has been tested with every conceivable URL.

I hope this is useful to you; if not, I apologize for the bandwidth consumption.

--Scott (scott at 4th dot com)

TDobes’s picture

This is a duplicate of the full URL patch... please review and/or add to that patch.

Bèr Kessels’s picture

I'm not sure if i like handling external urls trough l().
IMO they should be handled trough a welink interface. Something in lines of /weblink/goto/345 but then much simpler.

That way its far more future proof. For example, third party modules would then be able to track (or limit) outgoing urls much better. With your proposal they still have hack the l() function.
Also, your l9) does not allow for: feed:/ mrml:/ rm:/ or whatever other fancy "procol thingies".
l() should be used for internal urls, external stuff must be handled by a module.

stevryn’s picture

And if someone doesnt want to track urls? And wants the external link to go directly to the external page...how does one do this.
since updating to 4.6 all my links created with flexinode first take you to the node page, THEN you have to click the link to go to the intended page.

I have a block of links created with flexinode, and also use the taxonomy-dhtml module. It frustrates users to click what they THINK is a link to documentation, only to find they have been directed to a page with the true link instead.

The bookmark module links DIRECTLY to the url, I would like the same behavior for all my link lists.

Bèr Kessels’s picture

Please lets not mingle these two issues.
* allowing outgoing links in core.
* allowing tracking/hooking of these links

Allthough the latter is only possible when the first has been developed with teh latter in mind.

But both have *nothing* to do with enforcing tracking. we should *allow* modules to track all links, so that modules have an *option* to track them. No-one sad they will always be tracked

stevryn’s picture

I think tracking is a good idea in various cases, dont get me wrong, but if it means my outgoing external links go to the node page first then to the intended site, I dont need it. Perhaps I am just doing something wrong. I cannot figure out how to stop the link from going to the node, instead of the intended page. From what I have looked through, it appears that the flexinode url field & weblink url field are part of the "body". When displayed in a block or in taxonomy dhtml menu, they use the node id as where it gets directed to, as opposed to the url. Now in the case of bookmarks, there is a url field, and it is what is used to direct the user to. I have very little php knowledge, so this was just a "guess" on my part after looking through the tables in the db.

stevryn’s picture

From a "user" point of view (my staff's that is :) ) They want to click, and go directly to the external site. Not click, get redirected to a page with the intended link, and have to click again. Prior to my upgrade, it worked fine. I dont know what happened. What I do know is many people including myself get really annoyed with having to traverse long menus and endless link clicks to get to where you want to be.

Bèr Kessels’s picture

stevryn, Your issue might be valid, but has really nothing to do with this issue.

I suggest you post a new issue in the flexinode project.