sll552
Custom button URL custom separators
I wanted to change the custom button's behaviour to search for the currently playing song on spotify. So I changed the URL in the settings to this: https://open.spotify.com/search/[TrackTitle]%20[Artist] The problem is that if the track title's or the artist's values contain spaces then the spaces turn into "+" signs and the spotify search includes these plus signs (see screenshot) and so it doesn't find the correct song. I know that this is the correct/default behaviour and that this works for some or most websites.
It would be great if there was a setting for changing the "+" signs into any other string, for example "%20" so the spaces stay as spaces in the URL. Or you could just point me to the line of code where this is set and I can change it manually.
I found issue #178 and set a virtual tag like this: ###<Title>\%20<Artist>
But it still doesn't work like in this example:
###some\/text with whitespace -> some/text%20with%20whitespace
The whitespaces still turn into + signs.
Does spotify handle %20 correctly?
Technically everything works as intended because + is defined as URL encoded whitespace. I use the standard C# URL encoder which works according to standards.
If spotify does not handle encoded URLs correctly that's unfortunate but I do not want to break the encoding because one site doesn't know how to parse their URLs correctly.
It's the same on deezer.com too. It isn't actually as bad as I thought at first because spotify and deezer still find the correct songs. The only downside is that you can't copy the text from the search bar and paste it in a text without manually replacing the + signs.
I will take a look, maybe there is an URL encoder that does exclusively use percent-encoding. This should help with compatibility
could you try this https://ci.appveyor.com/api/buildjobs/rb1tqknriy60bnqi/artifacts/DiscordBee-Release--404.zip ?
I changed the encoder. C# (or more dotnet) has a few different ones that also work differently. I originally used the one that was recommended in the docs, but the new one seems to be the most reliable one and is generally recommended by devs. This change should not break anything so it will be included in the next release. Until that you can keep using the version I sent you, but the link will expire in the near future.