Can't create an URL with a ^ caret in it.

OK that url is working right now. I don't see a reason for it to fail. This is the code that generates the error so I don't have to look it up later.

if (!valid_url($node->url, TRUE)) {
form_set_error('url', t('That does not look like a valid URL.'));
}

Thanks
Robert

Can't duplicate the error. I have tried in both Drupal 5 and 6.

Thanks
Robert

I entered that URL with no trouble. Could you, perhaps, have had a space at the beginning or the end?

Robert, perhaps we should add a trim() to the validation.

No, you didn't corrupt your database. You did find two typos in the .install file. I just committed the fix. It will roll up in the next -dev version (at Noon GMT).

However, uninstalling any module is going to delete any content that the module created, so all your links are gone.

If you want to manually fix the typos, go into the weblinks.install file:

1. Locate the line (around 86) that reads 'tid' => array('tid') and delete the whole line.
2. Go down to almost the end (around 250), and locate variable_get('weblinks_user_links') and change it to variable_del('weblinks_user_links')

My apologies for these errors.

TinyMCE (actually, any WYSIWYG editor) is known to cause problems and is almost certainly the problem here. They have documentation on how to disable TinyMCE on a field by field basis. Please try turning it off for Web Links.

Disable TinyMCE for dynamically named textareas

Also see my open issue there: #235598: How to disable TinyMCE on Title fields

Izzy,

The coversion to text areas happened in the beta version. It has been over a month since that change was made.

Thanks
Robert

PS. Nancy yea we should trim the URL just in case.

Trim fix committed to both branches.

Izzy, when we fixed #284463: URL length needs to be increased, it was necessary to change from a textfield to textarea; that brought any WYSIWYG editor into the mix. The Drupal developers are aware that these editors are a big nuisance to contrib developers and some work is being done to address it, but don't hold your breath for seeing it soon. See Wysiwyg API.

Sorry for interrupting!

I need to upgrade from weblinks 6.x -rc2 to rc3...so which tar should i use 6.x-1.0-rc3 or 6.x-1.x-dev released on Aug 27 to avoid the error that has been solved here.

The -dev version is the most current and has the fixes from #7 and #12. Please make sure you use update.php.

Unless something pops up I will doing rc4 on Monday. And that will likely be the last RC before release.

Thanks
Robert

We also have suddenly come across the "That does not look like a valid URL." problem when creating certain Weblinks nodes.
using Weblinks modules versions 5.x-2.0-rc3 and 5.x-.1.15

(although it does not seem to occur with an older version of the module 5.x-1.8 that I have used on a development server)
I have noticed that our issue does seem to revolve around certain non-alphanumeric characters (namely the "^" character) which seem to always trigger the error message.
I have tried with turning off the "Check if link is valid when entered" option and also disabling TINYMCE with no effect.
Any suggestions?

wyoshimu,

Are you using a full screen editor?

Thanks
Robert

@wyoshimu: Try the -dev version, please. You would not have seen this in 1.8 because the feature didn't exist then. However, we cannot do anything about TinyMCE, which seems to be unsupported. Please either disable it or use the information in the link above to turn it off for Web Links.

No sorry Nancy, the Dev version is not working either...
TinyMCE is off.
I even also tried it with a brand new empty vanilla database (drupal 5.6 and 5.10) so no other modules besides core are running.

I can send you a sample of a link if you would like...

Virtually all links are fine and it will allow the Weblinks node be created (valid or not valid URLs), except when the ^ character is in the URL.

wyoshimu,

Does update_status or Aggregator work on your site? My hosting provider had turned off outbound connections on there hosting sites at one point. I had to have my account added to a list of sites that could make outbound connections. We use the same method to get data as those two modules. Also I have found that IIS sometimes returns 302 even for valid links. Are you getting the same error this isn't a valid link? or has the error changed?

Thanks
Robert

I added the URL into the error message so it will kick back the URL to you in case something is getting inserted by something like full screen editor.

@wyoshimu: Can you test something for us with your complex URLs, please?

Go to approximately line 844 (in weblinks_validate), where you will find:

  $url = trim($node->url);

and change it to:

  $url = drupal_urlencode(trim($node->url));

We think the core "valid_url" test is choking on those unencoded special characters.

Sorry I am now getting an error message when I am trying to upgrade the php with any weblinks module greater than weblinks-5.x-1.15.tar.gz

"user warning: Unknown column 'last_status' in 'field list' query: SELECT url, weight, last_status, last_checked, click_count, last_click FROM weblinks WHERE nid = 2 AND vid=2 in C:\wamp\www\includes\database.mysql.inc on line 172."
"szAppName : mysqld-nt.exe szAppVer : 0.0.0.0 szModName : mysqld-nt.exe
szModVer : 0.0.0.0 offset : 002604e6"

...
so I haven't yet been able to test changing the $url = trim($node->url); yet.

Before my new crash oddity... I did manage to test Robert's URL feedback addition (once or twice) and the returned URL was exactly the same except instances of "&" were replaced with "<&amp;>". All instances of the ^ were still there.

OK, non-related errors sorted out (had to run cron before update).

I've tested your suggestion to change line 844 (in weblinks_validate) combined with Roberts additional feature to spit back the URL show me that it will change all the non-alphanumerics to their URL-safe counterparts (ie : becomes %3A, ^ becomes %5E) but unfortunately the changed URL still does not work (cut and pasted back to browser)
And same error message is provided.
"link", does not look like a valid URL.

Without the change in line 844. The URL that was spit back changed only some of the characters to their UNIcode counterparts (ie & to &amp;) but others stayed the same (ie ^). And the changed link (cut and pasted) once again did not function independently in a browser.
Error message is still same..
"link" does not look like a valid URL.

Here is an example of a link that I am attempting to link to...
http://thoth.lib.ucalgary.ca/uhtbin/cgisirsi/0/X/0/57/5/3?searchdata1=^C2671933&searchfield1=GENERAL^SUBJECT^GENERAL^^&user_id=WEBSERVER

PS It seems as though that link might get chopped off by the Drupal forum so here it is again in two lines.
http://thoth.lib.ucalgary.ca/uhtbin/cgisirsi/0/X/0/57/5/3?searchdata1=^C2671933&searchfield1=
GENERAL^SUBJECT^GENERAL^^&user_id=WEBSERVER
(sigh, if it isn't one thing... its another..)

Okay, thanks. Now we know that's not the problem. The RFC is not clear on whether a caret is legal in a URL, although I think it is. And you've given me a sample to work with. I suspect we have a core bug.

It is indeed core: #295021: filter_var() with FILTER_VALIDATE_URL accepts malformed URLs and rejects not all valid URLs

@Robert: do we want to try some kind of work_around?

@wyoshimu: Okay, I copied and fixed the patch from that issue. It looks good on my test sites. Can you please test it and let us know. We want to roll a new release if this takes care of your problem.

According to RFC1738, the URL you show is actually invalid.

Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs. The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text; the quote mark (""") is used to delimit URLs in some systems. The character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it. The character "%" is unsafe because it is used for encodings of other characters. Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are "{", "}", "|", "\", "^", "~", "[", "]", and "`".

All unsafe characters must always be encoded within a URL. For example, the character "#" must be encoded within URLs even in systems that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another system that does use them, it will not be necessary to change the URL encoding.

So what do we do now?

I guess we encode the string and if it still doesn't work then he will have to turn off validation. We will now need to make sure that we can turn off that check.

Thanks
Robert

I have tried every type of encoding I know about (and a couple I didn't) to no avail. And it seems the core developers are kicking back on this.

As I said we try and encode the imput and make sure it still works on standard links. If it doesn't work right we just do what we are doing right now. He will have to turn off validation since he is entering a none standard url. We might want to revisit the idea of not checking certain URL as well.

Thanks
Robert

running D6.4
I had same issues with not valid link, I tried the new releases..not work either..
Would not take a url even with the verify off. The listing was there, the row would expand, but no link would show. The node was created, and you could view it.

had to go back to weblinks-6.x-1.0-rc2...still with it...
I really like this module, works right out of the box, great for us newbee's

What was the URL?

if you are asking me it's on www.buckeyelake.org but like i said it's got rc2 installed.
i had to take the newer ones out so i could have the page up.

Well, what I really wanted to know was the URL that caused the failure. As we have pointed out there is a core bug here and we are trying to help the core developers get it fixed as well as trying to find a way around it that works now.

Thank you Nancy,
I've tested 5.x-2.0-RC6 on my development server and it seems to have everything in place for the complex URLs to be happy (or at least the complex URLs that I am using). It will take me a day or so to have it implemented on our live server but I think you have it solved.
If I could send a fruit basket down the hall to your desk, I would.
Thank you once again for all your brilliance.

@wyoshimu: Thanks for the update. Because of another issue report, can you, please, tell me which PHP version you are using?

No problem Nancy,
on my test server
PHP 5.2.5
This is the version that I had tested this morning and seems to have resolved the ^ problems.

I'll still have to confirm the version on the live servers though.

The 'Live' server is running PHP 5.2.6
Both were experiencing same ^ symptoms with weblinks modules 5.x-1.15 to 5.x-2.0-rc3 but have not been fixed with 5.x-2.0-rc6

^ isn't a valid char according to the RFC. We aren't sure what are going to do.

Well, it is valid - but it must be encoded. Unfortunately, I haven't found any encoding routines that actually do a caret.

The problem stems, apparently, from an incorrect understanding of the PHP urlencode() function in the drupal_urlencode routine. Urlencode is supposed to be run only on the query part of the URL, not the whole thing. So I changed the code to take the URL apart, encode the query string, and then put back together. Now we seem to be all happy.

Fix committed to both branches.