CCBill links with encoded '&' don't work

[Toby]

cd34 posted the following in a blogging forum thread, but the ramifications are widespread enough that I felt it needed more exposure.

http://www.greenguysboard.com/board/...19&postcount=5

In lay terms, if your CCBill referral links use & in place of just the & the CCBill cookie identifying the affiliate does not get set.

Some web editors have a habit of encoding ampersands and other special characters as you type them, as that is the correct way to code if you want your pages to validate.

I did a search through the hundreds of galleries I've made over the last couple of years, and I did find several dozen with encoded referral links.

I will also start doing a spot check on sponsor hosted galleries to make sure those links do not contain encoded ampersands.

Hopefully someone from CCBill will see this and bump it up the line to the right people to find a resolution on their end. I would guess that fair number of affiliate sales are going uncredited due to this issue.

[Jim]

Toby
That is interesting and important information.
Thank You

[Greenguy]

That's a problem that's been around for YEARS - I remember MaxCash's sites way back in the day had the "&" problem.

[Emerald]

Thanks for that info Toby - I always wondered why my web editor would change & to &amp - would drive me nuts .. I'm pretty sure I changed alot of them to look exactly like the sponsors ref link... but I am sure there are still a lot of them floating around with the &amp in them ... grr just what I needed today.. to look thru my codes.

[MrYum]

I first noticed this about 5 years ago when I got into the biz and was using Dreamweaver as an editor. Damn thing was constantly changing affiliate links

That issue was one of the things that got me to start hand coding...no more wysiwyg editors for this porn slinger. And no more issues with affiliate codes getting fucked up either

[urb]

Don't code with a WYSIWYG editor...

Code by hand using something like this http://www.textpad.com/

[lassiter]

Originally Posted by urb

Don't code with a WYSIWYG editor...

Code by hand using something like this http://www.textpad.com/

I've coded everything by hand using TextPad since I started in the biz. It's totally awesome.

[urb]

Originally Posted by lassiter

I've coded everything by hand using TextPad since I started in the biz. It's totally awesome.

And it's free.

Although it is worth buying a licence. Features include...

• Search & Replace
• Instant upper case / lower case / sentence case convertion
• Good spell checker

There's a lot more in there too, and it won't alter your code like most editors do (including Notepad).

[MrYum]

Yup, text editors are your friend

I've been using NoteTab since dumping DW 5 years ago.

[virgohippy]

Holy shit! You mean I'm losing money!? I've got a lot of links to fix!!! |shocking|

Thanks for pointing that out Toby.

I use DW. I just checked, and I notice it only encodes links I've edited in some way.

I really like using DW though... I'm going to see if I can't turn that auto-encoding &'s off.

[Greenguy]

I use Namo & it's friendly to the link codes with "&" in them (for the most part - lol)

[MrMaryLou]

Wasn't Front Page the one that always messed the codes up?

[ponygirl]

Originally Posted by Toby

I've been using DW since it was first introduced. The last two versions (MX 2004 and Studio 8) have been far better about when it automatically encodes as you type, usually only doing so if you are typing plain text in design view.

that's what I thought. I have MX & was told never to do any coding or moving things around in design view

Originally Posted by MrMaryLou

Wasn't Front Page the one that always messed the codes up?

Front Page is a nightmare lol

[Robbo]

Originally Posted by MrMaryLou

Wasn't Front Page the one that always messed the codes up?

Front Page would even double fuck you in that you could change a code and when you looked at it again in the web view it would change the codes back again!

[BOSS]

Would like this confirmed...cause maybe i am loosing money

[Toby]

Originally Posted by BOSS

Would like this confirmed...cause maybe i am loosing money

Did you read the post I linked to by cd34? How much more confirmation do you need?

[digifan]

Good post... I remembered I saw it somewhere and found it, see
http://www.dwfaq.com/Tutorials/Misce...s_encoding.asp

At least, I cannot blame myself for doing sites in a plain text editor.

BUT
if you are using scripts, you have to check the url encoding option or they break at the & , it has happened to me with my very first copy of smart thumbs. The links worked from the gallery preview area and I forgot to click all of them when output to the index.shtml.

[Jicky Jack]

Yes, I learned that hard way also... I went 0 for 2 months with Lady- Sonia.. until John looked at my traffic... I was using "front page" & arles to make galleries... Live and Learn! After removing the "amp" code things went back to normal!

[HarryM]

Is this happening with any other sponsors or is it just ccbill?

[Toby]

As far as I know, this is just a CCBill issue.

[johnnybg]

cd34 saved a lot of money and pain for many of us with this information. Thanks for the heads up Toby!

[FiReC]

I believe you are spreading bad information here. In your test you sent a get request with the html entity in the request. When a browser sends the request I believe it decodes the link before it sends the get request. I tried it out with firefox and the web developer plugin and the cookie still gets set with the ;amp in the source.

Now for scripts with header redirects, you would want to be careful, but no need to change ;amp to & in your regular html.

[cd34]

In Firefox 1.5.0.6 with cookies set to 'Ask Everytime'

if I key the link in directly into firefox, & will not set the cookie
If I key the link in directly with & rather than &, it will set the cookie
If I cut and paste a link from a page set with a doctype of transitional, it works.
If I cut and paste a link on a doctype set with strict and the url not contained within CDATA (in other words, a page that won't validate) , the cookie is not set.

Additionally, if the link is coded through a script and sent as:

<a href="test.php?blahblah=1&j=http://refer.ccbill.com/cgi-bin/clicks.cgi?CA=xxxxxx-0000&amp;PA=xxxxxx">test</a>

<?php

header("Location: {$_REQUEST['j']}");

?>

it will not set the cookie because the location header that 99% of the tradescripts are using doesn't de-entify before sending to ccbill.

IE exhibits some odd behavior depending on which version you use. 5.5 does not deentify before sending in my tests. 6.0 does most of the time, but, failed once. I believe ccbill should set the cookie each time regardless of whether there is already a cookie present for that master account number, but, that isn't what I observed in one of the tests I did above. And after it happened, I couldn't duplicate it.

According to the RFC, the browser is supposed to deentify when going to a url, but, clearly when you cut and paste a url into firefox, there is no way for firefox to guess what action it should take.

Personally, I wouldn't want to rely on the browser guessing at what is supposed to happen.

[FiReC]

Just to clarify you are talking about browser problems deentifying when copying and pasting entities directly to the address bar and not when links are clicked on a page?

[cd34]

if a surfer right-clicks on a url on a page and pastes it into their browser, depending on a few different factors, they can get the entified or deentified link.

Since there is some inconsistency there, or, when used in trade scripts, etc, it just seems to me that better safe than sorry would be the rule of thumb. Especially since IE 5.5 also seems to exhibit the behavior even on clicked links.