[DesignerWiz]

In appreciation of each ABW members efforts that have molded this forum board to what it is today, I'd like to offer a free UNIX - PERL script tool to assist fellow ABW members in their current & future endeavors.

The Affiliates Link Masker Redirect Control Panel script .... pretty much does as it's title say's it is.

This compact script allows you to effectively mask where the outbound URL destination link goes to by pointing your affiliate links to an internal site destination (your server cgi-bin) that will then redirect to it's intended target destination after processing.

FEATURES:

Affiliate links that point to an internal URL destination (your server cgi-bin) will allow you to effectively hide some of the banned affiliate URL's that are commonly removed from the marketing pages by the visitors Anti-AD security programs they have running on their computer.

The Affiliates Link Masker Redirect Control Panel provides you with a password secured login area, click stats and referrer log.

The Affiliates Link Masker Redirect Control Panel will automatically add the '&afsrc=1' append tag that some parasite software agents stipulate must be present if you use a redirect script.
(in order not to overwrite your affiliate cookie ... yeah ... errrmmm)

HOW DOES IT WORK:

Login to your control panel and enter the URL to mask into the 'Add URL' box, then simply enter a unique ID: name that you can associate with that URL target. Then simply click on the 'Add URL' button and it's instantly added to the database of other ID's you have stored.

To get the masked URL code snippet, you simply look for the ID name in your 'Manage URL' area. Select your action (in this event - Show URL / link ) from the ID Action table.

You do not have to worry about adding the '&afsrc=1' append tag that some parasite tracking agents stipulate must be present if you use a redirect script (in order not to overwrite your affiliate cookie) ... the '&afsrc=1' append tag is automatically added when you need to copy the masked URL code snippet.

The Affiliates Link Masker Redirect Control Panel also provides you with a complete statistical breakdown on each of your ID's clicks in the 'Statistics' area.

WHAT THIS SCRIPT WILL NOT DO:

This script will NOT mask images like our Anti-AD Showcase Manager does. This script is solely for the purposes of 'lightly' masking hypertext links and monitoring the click statistics processed through it.

Do not compare this scripts function with our Anti-AD Showcase Manager ... they are 2 separate scripts with HUGE differences.

This application will NOT mask the final landing page destination URL shown in the browser toolbar. (it does if it's a download zip file)

REQUIREMENTS:

OS: UNIX / Windows
Webserver: Any
PERL version: Min. 5.0 Best
PERL Module needed: CGI, available for free at http://www.cpan.org

YOU CAN GET YOUR FREE COPY BELOW:
Compressed File Size: 57.48 KB
File Zip: http://designerwiz.com/cgi-bin/perl/affanti-block/a.cgi?ID=ABW-Affiliate-Masker-Redirect

Please Note: You Should Always Test Each New Vendors URL Format For Script Compatibility Before Trusting To Add Additional Links From Any New Vendors.

[DesignerWiz]

[DesignerWiz]

Another

[topaffiliate]

Is this script still available for download? I tried clicking the provided link, and got a blank page...

[TJ]

The link worked for me... I just tried it

[DesignerWiz]

Hello Topaffiliate, the link worked for me as well. Try again, and let me know if you still continue to have difficulties downloading the zip file.

[mobilebadboy]

Ray, if I overlooked this forgive me, I did look first.

Are we allowed to modify it (should any reason ever arise, you know how programmers can be ) with an understanding we probably won't get support for it, and knowing we still cannot redistribute it?

While I'm a PHP guy, and have written my own app to do basically the same thing (more or less), I still might give it a try on my new site. My apps tend to be non-portable sometimes as I'm often lazy to code them that way. Portable to an extent, I just never write installations, etc.

[DesignerWiz]

Hello Mobilebadboy,

I don't have any problems allowing the script to have any modifications made to the codes as long as it's not for repackaging and/or for "sale distribution".

Your right about non-support for any upgrades you may add to the script function(s), I would obviously need to have my programmers fully study the coding structure ... which can be timely as you already know. If you upgrade the code and think it's worth sharing with the other ABW members, I'd appreciate a copy for that purpose.

[Donuts]

Ray - what a GREAT offer!!!!! I have it and am playing around with it. I am notoriuosly slow at implementing technical changes! But I like what I see - a lot.

I have this secondary problem, being pretty anal. People will tell me clean code (on my webpages) doesn't matter and in fact, can prove it to me by showing me examples in directories and serps of horrible code. Anyhow, when I validate my static html pages, the only errors I get today are from the code snippets from affiliate urls... like when a url has ?2345&0&pageland.aspx or ?kbid=14286 at the end - the validator always hacks the crap out of the variable pairs and says my page is invalid.

Am I right in assuming the software you're giving away here will clean that up and get me squeaky clean code?

Can you give me a few examples of exactly what the "internal" (i guess that's the word for it) url will look like?

And does having this running properly on my site, make the search engines see fewer outbound links on my page (cuz they all point to my domain)?

And do I need to make my robots.txt exclude the cgi-bin folder?

I'm pretty smart and knowledgable and experienced - but not when it comes to redirects and masking... give more detail than you think is reasonable please.

[Donuts]

Am thinking the resultant "internal" urls look like:

mydomain.com/cgi-bin/perl/redirect/test/a.cgi?ID=12548

so my code will be cleaner - only one variable pair - but still won't validate completely - that right?

anyway to make it like:
mydomain.com/linknounname/

[DesignerWiz]

Hi Donuts,

Your right about the code having a "?ID=12345" which does NOT validate to HTML compliant .. but does NOT blow out the template structure layout because of the non-validation and works just fine in browsers we tested in the build.

Your code would look something like this example:
http://mydomain.com/cgi-bin/redirect/a.cgi?ID=12345

This allows you to effectively make links appear inhouse because it shows the URL pointing to the site /cgi-bin/ versus an obvious outbound 3rd party tracked URL path which many Anti-AD programs look for in their banned definition files.
Like you said, the URL path now only has 1 non-validated URL element in the path versus multiple non-validated elements some vendors URL paths have in them.

Yes, you should always exclude the cgi-bin folder from crawlers. Not just for this redirect ... but for overall safeguards IMHO.

There are ways to make the URL appear as http://mydomain.com/linknounname/ through .HTACCESS .... but I personally don't think it's necessary.

I'll talk to Gary today, see what we can do about the "?ID=" element which is what does not validate.

[DesignerWiz]

People will tell me clean code (on my webpages) doesn't matter and in fact, can prove it to me by showing me examples in directories and serps of horrible code.

While this statement is true to some degree, it's basically a false hope if a webmaster thinks that the bad code format will last forever. I give it 2 - 4 years before all major browsers decide to abide by one "validated code language".

Internet 2 is in live BETA as we speak. It is so fast compared to todays technology it would make the mother of bad-ass servers with a T1 or faster connection cry an extremely quick "Uncle" if you leashed Internet 2 on it. It has been reported that this new technology will require a "validated code language format" from the major browsers. I think we will all see the major browsers come to some type of agreement in short time.
This is why my team is currently re-writing our entire site in XHTML transitional this summer. We are not taking any chances.

[topaffiliate]

Thanks for the update - I tried the link again and it did in fact work for me this time

DesignerWiz (or any other htaccess gurus out there) - any chance of telling us what to put in our htaccess file so we can make the URL appear as http://mydomain.com/linknounname/ ? It's been my experience that urls of that form do better in the serps

Thanks for the fast replies, and for making the script available to abw members!

[topaffiliate]

one more question re: '&afsrc=1'

I've read somewhere on abw that '&afsrc=1' needs to be in the link that is viewable on the web page in order to 'prevent' the parasites from stealing your code - that it has to be part of the link in the html page, not in the redirect, in order for them to recognize it. Am I misinformed (which would be great b/c having '&afsrc=1' right in my page makes it easily identifiable as an affiliate site to the serps, instantly devaluing it making it a catch 22)

thanks in advance!

[DesignerWiz]

Hello Topaffiliate,

The "&afsrc=1" is only printed on the URL path ID you created for pasting into your web page. You don't have to use that part of the string if you wish not to.

If you want to totally remove that variable from addition to your ID, open up a.cgi file and look for "$url.="\&afsrc=1";" .... simply make it read $url.=""; and that will fix that.

In regards to .HTACCESS write. You should read about that before implementing it's usage.

Here's a few URL's that have topics on the subject:
http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html
http://corz.org/serv/tricks/htaccess2.php
http://httpd.apache.org/docs/mod/mod_rewrite.html

[TJ]

Originally Posted by topaffiliate

make the URL appear as http://mydomain.com/linknounname/ ? It's been my experience that urls of that form do better in the serps

But you don't want that link in the serps... in fact some merchants forbid it ....or are you saying that the search engines don't like pages with variables in them..

[DesignerWiz]

We have had a few links with variables in them rank well ... so I don't think that is an issue. I'm no SEO specialist, but I think the answer to this question is a "no problem with variables in URL paths".

[topaffiliate]

Originally Posted by TJ

But you don't want that link in the serps... in fact some merchants forbid it ....or are you saying that the search engines don't like pages with variables in them..

you just apply a rel=nofollow tag so that the search engines don't index or follow those links. My concern was more with the search engines devaluing pages that are clearly affiliate pages. By having the link appear to be on your own site you don't look like an affiliate site.

[Donuts]

Originally Posted by DesignerWiz

We have had a few links with variables in them rank well ... so I don't think that is an issue. I'm no SEO specialist, but I think the answer to this question is a "no problem with variables in URL paths".

I agree. It's the validation aspect that bothers me. Please the codes wig out consumers - they often cut them up - many of my merchants usea variable pair for landing page or sku or whatever - and the site visitors sends themselves to a 404.... I'd like to find a way to have a descriptive noun in the url - so the consumer knows what the destination holds. And I'd like to make sure that search engines don't penalize me for it.

Using htaccess is one way, but I have so many links and hate messing with htaccess - it can tank your site if you make a mistake. It also is a no-wrap text file in ascii - weird characters in it - scary to edit and not easy like your free tool. And htaccess doesn't do any of things tracking and stuff that your tool can do when you bump it to the silver of gold level. If anyone goes to mess with their htaccess, think hard first, read alot forst, backup your current htaccess file first, check your hosts help files for htaccess (one of mine says you are on your own if you mess up) and another warns sternly that FrontPage users will disable their site more than 1/2 the time. Playing with htaccess can be like playing with matches - inexperienced is a no-no, and even experienced folks need to use their highest caution. Some hosts won't let you alter the file at all.

Anyhow, let me know what Gary says.

And why do some merchants not allow links like I suggested?

[TJ]

Originally Posted by topaffiliate

you just apply a rel=nofollow tag so that the search engines don't index or follow those links. My concern was more with the search engines devaluing pages that are clearly affiliate pages. By having the link appear to be on your own site you don't look like an affiliate site.

Ok, gotcha, and what are your thoughts on afsrc=1, wont this prevent you from adding it.... does better SERPs rank higher than worrying about parasite overwrites?

@donuts: If the serch engine spiders your jump script and then lists it... a user could click that link and it would be a forced click according to some merchants... or at least thats how I understand it.

[DesignerWiz]

I talked with Gary last night to see what we can do about the "?ID=" variable element ... which is what does not validate in the URL strings. He stated that it's something we can "fiddle with" in the near future to see what we can come up with. Gary seems to think that we may be able to implement a self build function that would "auto-write" to the .HTACCESS file during the input of ID's through the main control panel online.

The only draw-back concern Gary had ... if you have tons & tons of ID links within the .htaccess file, this can and would most likely would cause the redirect page to be slow to connect as it scans the .htaccess file for the proper ID to associate with a "noun ID". Gary was also concerned that this build structure would most likely cause normal access to pages to be slow loading because of the size of the .htaccess file.

Without having tested this theory, we can only speculate what may, or may not happen with a huge .htaccess file. Gary also seemed to think he may be able to do this using XML with the ID's. I won't be able to have Gary work on this test theory until after our site has been converted over to XHTML.

I'll keep you all posted when Gary jumps on this issue.

[TJ]

Here is a sniplet of code that MIGHT work in htaccess... Your links would be something like http://anydomain.com/jump/12345 with 12345 being the unique ID of each item. Adjust to taste...

RewriteEngine on
RewriteBase /
RewriteRule ^(jump)$  $1/  [R,L]
RewriteRule ^(jump)/(.*)(\.[^/]+)$ /cgi-bin/a.cgi?ID=$2 [L]
RewriteRule ^(jump)/(.*) /cgi-bin/a.cgi [L]
RewriteEngine off

Please use this code at your own risk... I'm NOT responsible

You can disallow the /jump/ folder with robots.txt and nofollow to stop the spiders going where you dont want them

[TJ]

Forgot to say, I'm thinking this would also work with a noun ID too

[admad1]

Hi Ray I've just tried the script and its great. Thank you. Just one thing is ther any way to upload a csv file with the urls in and have the script generate the code for download again to csv. Obviously the idea being to upload say 7000 links and have them proccessed. is this possible? I would be happy to pay for such a script.

Regards
Andy

[DesignerWiz]

Sorry for the delay on responding, I'm right in the middle of moving the work station.

Hi Ray I've just tried the script and its great. Thank you. Just one thing is ther any way to upload a csv file with the urls in and have the script generate the code for download again to csv. Obviously the idea being to upload say 7000 links and have them proccessed. is this possible? I would be happy to pay for such a script.

Regards
Andy

I see from your other thread posting, you discovered how you can import the ID's to the idfile.txt file.

RewriteEngine on
RewriteBase /
RewriteRule ^(jump)$ $1/ [R,L]
RewriteRule ^(jump)/(.*)(\.[^/]+)$ /cgi-bin/a.cgi?ID=$2 [L]
RewriteRule ^(jump)/(.*) /cgi-bin/a.cgi [L]
RewriteEngine off

Thanks TJ, while this code does work on a few servers (including ours), it won't work on others ... and this is the reason why we don't want to rely on the .HTACCESS file as a jump rule. Your also right about this working for a noun ID.