url fieldtype bug when a '%' caracter is included

[antpre]

Hello,

Running into a probleme. Any help would be appreciated.

I have a url fieldtype. When I insert urls with a '%' symbol in it I get a :itemUrl: Error found - please check that it is a valid URL

The url is a valid url. Once saved all the % are stripped out from the url and replaced by a spaces.

This is running on PW dev version 2.6.21 and php 5.4.42 (I was on a earlier version of php, I then up dated it to 5.4.42 to see but didnt change anything)

The funny thing is that I have an other test site running on PW 2.6.1 where this problem doesn't occur.

Any Idea

Thanks

[Macrura]

AFAIK you can't have a % sign in a URL, did you mean %20 are replaced with spaces (%20 is an encoded space)?

can you post the URL you are trying to paste in?

The specification for URLs limits the use of allowed characters in URLs to only a limited subset of the US-ASCII character set: "...Only alphanumerics [0-9a-zA-Z], the special characters 

 $-_.+!*'(),

   and reserved characters used for their reserved purposes may be used unencoded within a URL.

[antpre]

Thanks for your answer. your are rigth spaces are repalced  by %20.

Its actually a link to a mp4 file in an amazon S3 bucket.The file name has spaces in it. When I copy the url with cyberduck it replaces the spaces by %. (in the url given below i ve removed the domain name).

s3.amazonaws.com/1-talk/140629_PP%20Birmingham%20820710%20extrait-11.mp4

So far I had no problem with that.

I use it in an other installation of PW (latest stable version) where it works. but in the latest dev version it doesnt.

When I paste the url in the url field type and save the page with pw2.6.1 : I have no error message and the url in the edit page keeps the %. When I inspect the code of the page the url appears with the %. And the link works (actualy when i click on it then it appears with space I guess the browser converts the % into spaces). 

<source src=s3.amazonaws.com/1-talk/140629_PP%20Birmingham%20820710%20extrait-11.mp4 type='video/mp4' />

with pw26.21 : When I save the page I get an error message and the % in the url are replaced by spaces. When I inspect the code of the page. The url appears with spaces but it is considered as a link until the first space,rest of the url is not considered as a part of link (not in blue and underlined). therefore the link doesnt work.

<source src=amazonaws.com/1-talk/140629_PP Birmingham 820710xtrait-11.mp4 type='video/mp4' />

Hope my explanations are clear..

[LostKobrakai]

You need to use quotes if you've spaces in the attributes value.

[antpre]

Thanks a lot. With quotes it woks well.

I m still wondering why it was working without quotes in pw2.6.1 and why it is not working without quotes pw2.6.21. Is it intentionnaly done or is it a bug that appeared in bettween (in that later case i should then repport it on github)

In some other CMS (drupal for instance) in the admin interface (edit page) this is working without quote like in pw2.6.1....

[LostKobrakai]

You need those quotes no matter which CMS you use. That's part of the html5 specs. What could be different is that the url is outputted unencoded instead of encoded, where the latter one wouldn't have any spaces in itself. 

[SiNNuT]

I can only test this in a recent dev version so i'm not sure about prior behavior but i can confirm the behavior that antpre describes. When given an encoded url (for example with %20 and %2B) InputfieldURL will complain that it is not a valid url and seemingly automatically rawurldecode's the string, after which you can save the page. So %20 is turned into a space and %2B into a +.

I'm no expert on this subject but it seems strange that InputfieldURL considers encoded URLs as invalid and instead turns them into URLs with unsafe characters (i.e. an empty space). What is strange that according to antpre older PW versions did not have this behavior. I can see that there have been some changes recently but i can't figure out if this has anything to do with this 'issue'.

If this is intended behavior it would be nice if someone more knowledgeable could explain why.

Before save:

After pushing save, the encoded characters are automatically decoded: