Allow relative paths with validation

I'm also in need of having relative URLs for a few of my link fields. I've traced this back to issue #1645640 (Commit b4919a62). It appears that while trying to add support for links to "<front>", the path/URL entered by the user is now run through url() with "absolute" hard coded to TRUE in the options array.

The attached patch makes this optional functionality. After applying the patch, there is now a "Absolute URL" checkbox on the field settings form. This is checked by default so as to not run the risk of breaking any existing 7.x-1.1 installs, but if you uncheck the box then the field will respect the format used to enter the link when rendering it (AKA if you type in a relative URL it'll render a relative URL, and if you type an absolute URL it'll render an absolute URL).

Here is a re-roll of the patch. It didn't apply cleanly since it looked like some lines moved since the previous patch was made. It looks like this should work, but I have some conflicting javascript validation getting in the way that I need to resolve before I can review this more fully. The new admin option worked though!

I fully endorse this new feature. Relative links are way easier to deal with in a situation with staging and production sites.

Erik.

A ZeroK patch is probably not helpful. Here is a better one.

The patch in #3 was rolled from the Drupal directory instead of the module directory. I have rerolled the patch against the latest git version.

The solution in this patch fixes the link path sent to l() to be relative instead of absolute. As a bonus, this will correctly add the 'active' class if the $path value matches the $_GET['q] value.

A long term solution would be to leave the heavy lifting to the l() function instead of coding it in _link_sanitize(). However, considering the magnitude of this change, the solution in this patch will do for now.

I've re-rolled this patch, against the current development branch, to minimize the changes while still implementing the fix/feature.

Previous patches above split out the link components and returned them as array keys. I assume the intention of this was to allow the extra keys to be passed as options to theme_link() or l() during render. The problem however is that this unnecessarily changes the data structure of each link item and may break custom usages of this module.

In re-rolling the patch, I've also

1. applied the 'absolute' setting to the URL created for the anchor title attribute.
2. removed the non-existent and unused url() option 'html' => TRUE,

I've tested this in a production site now that uses i18n and path based language detection.

The relative links only work properly when we return the link parts as array keys as the earlier patches implemented, rather than generating a link URL by calling url(). As a result, I've reverted to the method used in patches #1-4, re-rolled against the current development branch and tested extensively.

This patch works great. Thanks d.clarke erikhopp idebr.

Well, initially I had my doubts on this patch, but having tested it and played around with the results a little, it seems pretty clean. Nice work, folks.

I've applied the change and pushed into the 7.x-1.x branch.

I think this commit introduced a regression. See #2367069: Link 1.3 removes the query string from field tokens