URLs are not validated

Before adding tags read the issue tag guidelines. Do NOT use tags for adding random keywords or duplicating any other fields. Separate terms with a comma, not a space.

Descriptions of the Priority and Status values can be found in the Issue queue handbook.

Please take a look @ field_validation module. This may help you by checking input data.

It seems redundant to rely on another module for link validation in the link module, when the link module both provides a link validation option and exposes this as a field setting. It also does not seem unreasonable to expect the validation to enforce something like the URL being absolute vs. relative.

Adding another option to enforce external URLs would be desired. Right now a user can enter "://:" and this module considers that a valid URL.

It seems redundant to rely on another module for link validation in the link module, when the link module both provides a link validation option and exposes this as a field setting.

@ #2 : As I mentioned in many other issues already, my comment was not targeted to this one single case, but rather discussing the philosphy of modular frameworks as a whole. As mentioned already often enough, I am not a fan of duplicate code and duplicated maintainer power and effort. Try to imagine that everybody, who comes with another request for certain validation, will say what you sad. So your argumentation falls to short. Since this module is a community effort, feel free to provide a patch. Otherwise accept my community opinion, that I would rather take off validation completely from the link module and leave it to a module, which takes care of any field validation and has unlimited possibilities. There is enough to cover for a link field (especially for html rendering) and for its maintainers, which makes it meaningful as a extra field. Take a look at the next version of link module, which goes into core D8, many of the features are ripped off. I assume that there will be a central place in D8 core covering a lot of the D7 link field features, since those features are not interesting for the link field allone but many other fields too.

Are any of the module maintainers working active bugs in the issues queue? [...] I don't really see the point of using this Link module at the moment, since it's not really doing what it advertises. Thanks!

@ #3 : Wow. I was asked and I chimed in and went in the issue queue of link module last year and covered over 200 issues and provided many patches and commits and disucssions and support. That has caused an immense decrease of open bug issues and it has pushed the final D7 release of the (free available) module (Not a fairytale, @webchick gave me a special thank in an official tweet for that). I am not a developer in my job, so I do it for the health of the community. @jcfiala spend many years before to cover the most of the link modules issues in D6 and D7 and @sun and many others helped a lot over the years. I think such comments are not very helpful unless there are arguable reasons like missing commits of lang waiting RTBC patches and long term blocked final releases causing this assumption. Which is not the case here. Take some time and go to several issues on drupal.org. There are issues over 6 years old and 200 comments long. This one here has 4 comments. It is not fair to say this towards all the community effort, which they all have spend to a free available Drupal and to this module, before being compfortable with the issue queue in general by yourself. If you think, things are going to slow (what is ok if you think so), feel free to provide any code, support, hints, like others do (including me). My advice to use another module, was not meant like leaving the issue to others. It was a friendly advice and also time I spend friendly to you, and to explain why.

Thanks for your reply. I didn't mean to offend with my comment. I was simply asking if bug reports are looked because quite some time had passed before there was a response to this.

The issue has an opening date of April 22 this year, my first comment was 3 weeks later. This is not "quite some time" for an open source module used by 200.000+, a long issue queue and an agreement about community driven contribution here on drupal.org. Feel free to try patching and provide some more details about your set up to get deeper into this. I have a little bit doubt that this issue occurs on a regulary basis since this would hit all 6.x users very soon. Invite others (any friends?) of you in the Drupal world to join the issue, and lets see if we can get some energy from others to get into it.

And please use code tags to put your links examples in, to prevent real link conversion in the issue comments. I already did this for you in the starting post weeks ago.

I provided no patch because, as a maintainer of this module, your first comment implied that absolute vs relative validation was not desired within this module. I was just expression my opinion that I think it is a mistake. I believe it is a safe assumption that anyone who installs this module will be under the assumption that the validation options will actually validate for useful URLs vs technically valid URLs (or at least provide that as an option).

Link already has a link_validate_url function that is implemented which redoes a lot of what http://www.php.net/manual/en/filter.filters.validate.php handles. There's also https://api.drupal.org/api/drupal/includes%21common.inc/function/valid_u... which provides the functionality discussed in this issue thread. The latter option is what I used with a field validation hook. At best I consider this module incomplete, and at worse I consider it broken. I point back to my "://:" example -- this module considers that a valid URL.

I would agree that, at this point, removing all validation not related to sanitization from this module would make more sense then having a partially implemented validation function. Other options would be implementing module_invoke_all() and letting modules define their own validation routines.

This is not a knock on the work done for this module. It is just a differing of opinions about what this module should do out of the box.

If patches implementing this functionality will be considered for inclusion then I may provide one (for Drupal 7).

@ steven.wichers: Many of my comments above where not targeted to you. Please stop the backhanded soft offending against helpers in the d.o. eco system. Even if you say it is not a knock on the work done, which is, from my point of view, not possible to do, since this is the work of many and the community as a whole. I don't own the module, I only help maintaining it for the community. You (even if softly) insinuate wrong behavior of others to show how this was leading to yours, but this is simply incorrect and not helpful in the issue queue.

Some examples:

Please take a look @ field_validation module. This may help you by checking input data.

I provided no patch because, as a maintainer of this module, your first comment implied that absolute vs relative validation was not desired within this module.

Where is this implemented in my words? Nor do I say that I don't want any patches be provided here, nor do I criticize anyone for missing patches. I am even not in the position to say this. This is a community driven Open Source project. No explanations or complains needed from your side. I only inform about the way modules are generally provided on drupal.org to prevent any misunderstandings about support requests.

At best I consider this module incomplete, and at worse I consider it broken. I point back to my "://:" example -- this module considers that a valid URL.

200.000+ users and you think this module is broken. OK, Let's start from scratch: There are more than one module in this module. Version 6 differs from version 7 and even the sub versions differ a lot. I can't reproduce your ://: example for D7 version (validation fails) for example, and the URL validation is not the main functionality of this module from my point of view, as already explained enough. To say this module is broken would lead to a convention where most of the big modules in d.o. eco system (like views) are broken, since some of the promoted features don't work correctly under certain circumstances.

But if you still think this module is broken, I will invite jcfiala (the main contributor and maintainer of the link module 6 version) and we have to seriously consider to take off the final 6 release from the project page. Please provide more info's and explanations from your side why you think it is and I will invite the other maintainers and users of this module to discuss the further future of link module final release version 6 based on your argumentation.

In the meantime you are very welcome to provide patches against the 6 branch. In version 7 of this module your described scenario is not reproducible. This issue is for 6.x-2.11 version anyway.

This is not a knock on the work done for this module. It is just a differing of opinions about what this module should do out of the box.

Indeed. Because I think there IS NO module which should be able to do anything "out of the box" ... unless we all together do implement this feature or pay a drupal developer to do this.

Can we copy/steal from field_validation? I really don't want to install another module to make link module's validation "work". Plus it means all the regex can go away. I'm willing to provide a patch if there's any hope of it getting accepted.

See http://cgit.drupalcode.org/field_validation/tree/property_validation/plu...

Here's a patch that is loosely inspired by field_validation.

Let's run this against the right branch.

Apparently the testbot doesn't like that still. Re-uploading a patch.

This will probably also fail, but I'd like to see if the URLs that it testing aren't really valid URLs.

I'll note that urls are validated - they're just validated less than you want them to be. :)

Part of the problem is that we don't only have http urls. We have mailto: links, we have internal links (for example, to node/15), we could have irc, webcal, or telnet protocols. So it's important when adding new validation to watch out for things like this.

This will fail on two tests. Because they are not valid paths. Nothing exists at those locations. Instead of fixing the tests, I thought I'd post what I have right now and get some feedback. Is this going in the right direction?

Failed tests:

Test files/test.jpg is valid internal link.

Test /var/www/test is valid internal link.

Yup, it failed. A link to /var/www/test simply doesn't make sense. The other link does and I've provided valid tests for them.

re #23: The new validation is an addition to existing validation and is only run against links of type internal and external. For the most part, its a fairly simple thing to validate these. I paid special attention to make all existing links to pass tests. Except for links that I'd argue never should be considered links. See #24, where I disagree from existing support.

This patch seems to have solved the problem for me. Now "this is my invalid URL that's gotta fail validation" is recognized as an invalid URL. :)

Leaving this at RTBC. Only a minor change, see interdiff.

So, the failures in the tests on #32 are valid failures. Those URLs should never have validated. I'm torn, should I fix the tests or break the validation so these pass?

• www.example.com/{randomName}
• www.example.com
• www.example.com/
• www.test-site.com
• http://example.com/index.php?page=this\that

Issue in #32 fixed but calling link_cleanup_url().

This should fix all the tests now. Most are all resolved with calling link_cleanup_url(). I moved http://example.com/index.php?page=this\that to the invalid links test, since it isn't a valid URL.

Works well few minor items

Missing doxygen for parameters

 /**
  * Prepares the item attributes and url for storage.
  */
-function _link_process(&$item, $delta, $field, $entity) {
+function _link_process(&$item, $delta, $field, $entity, $instance) {

No doxygen for language parameter

function link_validate_url($text, $langcode = NULL) {

Otherwise works as advertised

Added doxygen. :)

I checked the 6.x-2.x branch and found its already validating the URL. Please reopen this if it is not working for you.

Upgrading from 7.x-1.3 to 7.x-dev broke a website for which I am responsible due to the change in URL validation logic. Specifically, relative paths to pages not served by Drupal fail validation. I had to disable URL validation as a quick fix, but obviously that's not ideal. I anticipate some other sites running into this problem. Specifically, a Drupal install that is one of multiple backends to a reverse proxy server (such as Varnish) is susceptible.

To reproduce:
1. Install Drupal 7 and Link 1.3
2. Configure a Link field with URL validation enabled.
3. Add content including a relative URL for that Link field (e.g. "my-great-page") where that relative URL will be served by a server other than Drupal (but at the same domain) due to a reverse proxy server sitting between the browser and Drupal that serves the path "my-great-page" from a server unrelated to Drupal.
4. Note that it is possible to do this.
5. Upgrade to the latest dev version of Link.
6. Edit the content containing the URL added to the Link field in step 3 (or repeat step 3) and submit the form
7. "... is not a valid URL" error message

I think I followed the correct procedure in changing this issue back to 7.x, but please let me know if that's not the case.

re: #45, it is normal to open a new issue and document your findings in it. Rather than re-open an old issue.

BTW, this doesn't minimize the problems you are having in #45. You can also relate the new issue back to here. Opening a new issue just keeps things cleaner.

An issue with a patch that reverts this feature has been opened in #2666912: URL validation rejects existing valid content after upgrade to 7.x-1.4. This really should be considered a whole new branch of the module (7.x-2.0-alpha1) since it breaks backwards-compatibility and does not provide an upgrade path.

I think there is a confusion related to the status of this issue (and I've spent some time to figure out what's happening here). I see the commit from this issue and I the status "Closed (works as designed)". The two things are mutually exclusive.
According to the history it was in "Fixed" status, but for some reason it was moved to 6.x version, then status was set to "Closed (works as designed)" and then issue was moved back to 7.x (but status was not changed).
So, I'm changing the status to "Fixed" to reflect real situation. It should be closed automatically in 2 weeks afterwards...