Support for internal URLs

Maybe a field-level option to simply disable the checking would be more appropriate? The current validation is largely in place to prevent mistakes (and therefor dead-links). I kind of think taking the validation out makes this module a little too much like any other field. If you don't want any validation, you might as well make two textfields and a checkbox in CCK seperately.

Maybe we could provide additional validation which allows internal links? Internal links will still have some kind of pattern to them. They still can't include certain characters and you might want to prevent people from starting the URL with a slash ('/') so the Drupal links are valid. What do you think?

How about the following GUI: Add a new category in the 'Data settings' fieldset for 'Validation' with the following options:

Validation
[x] Validate internal links (a Drupal path)
[x] Validate external links (beginning with http:// or another protocol)
[x] Automatically prepend 'http://' to external links without a protocol
If no checkboxes are selected, no validation will be preformed

The last checkbox is a killer I know. Because we'll have to check for a domain name or www before prepending the http://. But I know if we took out this feature, another 5 people are going to ask next week where it went and want it back. In terms of making things easy for the end-user, I think that this feature prevents a minor annoyance.

Feel free to change the arguments for the validate_link function and add to the return array to accomplish these ends.

I think allowing for internal links is important. After some discussion on the dev list about how to handle greggles' use case in other content, I settled on what has now become the Path Filter module. This filter converts things like internal:node/123 into the proper URL.

For consistency with Path Filter, I would vote for allowing internal:node/123 style URI's to be used in Link fields.

Nice, sounds great. It'd be a piece of cake to validate also. I'd recommend that we do not store the 'internal:' part of the URL in the database though, just the path. I'm not sure if you can use other languages with path filter module, but I imagine some users will want to type 'internal' in a different language.

Sounds like it's time for another DB column :). Probably a one bit integer in the node_field_link_data table would do the job. Although it's a little more work now, but down the road it'll be easy to change the syntax (or allow different languages). So on insert, str_replace(t('internal:'),""); and on edit add it back to the default value of the field.

Is this being carried out? It is very necessary functionality in my view, without it links cannot be moved between domains without breaking, which means if you want any sort of test or development environment, you can't use CCK link.

While on the subject of the link.module, I would like to see the ability to add a class to a link, maybe using a check box to say "Add class to link" and then a text box to enter the name. This would allow different types of links to be created depending on content type, same with menu items as well (but I've already raised that as a feature request for menu)

There's been a lot of activity on the link.module front in the past few days. The patch KarenS put up makes link module utilize CCK's DB schema much better. I think this is still an important feature, which now should be easier to implement (I think). I'll have a look at implementing this feature soon.

I revisited all the suggestions made thus far for internal links. Once I implemented preliminary version of the 'internal:' link function I found that both data entry and implementation were a little screwy. Instead I found a little more complicated link checking is really all we need (removing it altogether works also, but I prefer this solution).

Here's the new behavior:
URLs that begin with a protocol OR domain will always be taken as external links so:

Valid External Links:

http://drupal.org
http://drupal.org?param=true#main
drupal.org
drupal.org?param=true#main
<code>

Valid Internal Links:
<code>
sites/drupal.org/themes/favicon.ico
node/5
node/5?param=true#main
<front>
<front>?param=true#main

The one restriction we have is that the first argument or directory of an internal link cannot contain a period. A URL like something.mysite/subdirectory will not be accepted as a valid url, but something/mysite/subdirectory will be rendered as an internal link.

Try out the latest 4.7 development branch or download the nightly snapshot:
http://drupal.org/files/projects/link-4.7.x-1.x.tar.gz

If everything looks good I'll mark as version 1.3.

I haven't looked at the code, but I assume the internal links get run through l() or url() before being passed to the theme functions for output?

The only potential drawback I see to this approach as opposed to using "internal:some/path" is that is impossible to distinguish between a drupal path (which should be run through url()) and a pure relative URL (intended to be put directly in the href attribute). Essentially this approach assumes you never want the latter. I can't think of a reason you would, but I thought I'd mention it just in case.

In fact, both types of links (absolute and relative) are passed through l(). Absolute links are unaffected, while relative links are converted to absolute and assigned any appropriate alias. The output link will always be a complete URL, ready for insert in a <a> tag.

Guys? I tried installing the development module and node/xx links are not still valid. Any guidance you could offer?

Hi, I get the following error message when trying to add node/77 to a CCK link:

• warning: mysql_real_escape_string() expects parameter 1 to be string, array given in /usr/share/drupal/includes/database.mysql.inc on line 350.
• user warning: Duplicate entry '0' for key 1
  query: INSERT INTO node_content_online_seminar (field_registration__information_url, field_registration__information_title, field_registration__information_attributes, vid, nid) VALUES ('node/77', 'Register online', '', 0, 0) in /usr/share/drupal/includes/database.mysql.inc on line 121.

Is anyone able to offer some assistance?

fadeout32: Try running update.php as the database schema has changed. If your problem persists please open a new ticket, thanks!

This functionality has been added in the 1.3 release (both 4.7 and 5.0)