Skip to main content
Welcome guest. | Register | Login | Post

Help with tracking links

11 replies [Last post]
ariadacapo's picture
Joined: 2006-07-13

Hello all,

one vendor of hardware pre-installed with GNU/Linux is willing to help us with commercial links and needs a little help. The idea is for them to give us a small retribution for orders initiated on (the commercial nature of the links is indicated on the site).

I understand that there are three ways that the tracking can work:

1. We append a special marker to the vendor url, and they keep that marker all throughout the customer's visit on their website until the final purchase.
Vendor reports they tried going this way but had no success.

2. We/They use a cookie. I am not sure of who sets the cookie and how the vendor is going to read it.
Vendor reports they are investigating this possiblity, I don't know much more about this.

3. We point to a special url (reserved to us) on the vendor' site, which redirects to the vendor's homepage. This allows them to log all the IPs of links incoming from us. Upon purchase they compare the buyer's IP with the log of (say) the last 48hours.
Vendor told me they are trying this way.

The point of the thread is, what would be the simplest solution? Do you have alternatives?
Some background:
- There is a lot of mutual trust, so respective control/inspection is not necessary. We just want something that works.
- Things should be as simple as possible, a plus would be an existing piece of (free) software to just plug-in
- Technical knowledge, as well as development time, on our side and especially their side, are limited. They use Joomla + Virtuemart.
- We really want some per-order tracking, not some pay-per-click or per-week system. It might be less lucrative but it is a million times more interesting and relevant to us.

Any (simple, practical, ready-to-use;-)) ideas?

Thanks a lot!


Joined: 2007-09-10
I thought about asking how

I thought about asking how the website intended on achieving the tracking (but didn't ask). I don't have experience, but I have some opinions. Sorry if I explain too much below, but I don't know who knows what (also, I may be wrong).

The idea is to capture something that will hopefully identify that customer the minute they click to finalize a buy transaction.

Something added to an url from the linuxpreloaded site (choice 1) indicates to the vendor that linuxpreloaded is concerned. This doesn't identify the customer except for that session. A session is something that the website infrastructure maintains transparently. It can involve something like cookies or http headers or can be invisible data stored and passed on the pages back and forth (dynamically generated urls or invisible form data, for example). How sessions are implemented depends on the technology being used. I don't have much experience with this in practice and can't say what joomla or any other code does (though I may have success if I research it.. but not sure if I want to invest the time now).

Anyway, sessions likely will only last for so long. Using cookies or storing info in a database or server text file or anything else (peristant storage) allows the identification to be done over a longer period of time (than perhaps only a few hours, if that is the normal length of a session). Cookies can be passed back and forth when the user uses the same browser on the same PC basically. This is an option.

Storing on the server (as well as cookies) leads to the question: what do we store? Well, you use some flag to initially identify a webpage request as coming through a link on linuxpreloaded (the marking information from a tag as mentioned in item 1, from a special url as mentioned in item 3 (basically the same concept as item 1), or maybe from a referrer http heading can each be accessed easily through php and most any server side platform being used). At that point, I'll assume you want to persist something beyond what the platform uses to constitute a "session."

One possibility is to store the client IP on the server and a uniquely identifying piece of information as a cookie on the client platform. The cookie data could serve as a key into the data store on the server that might hold the cart info and genearally identify a cart session or the user and identify that they came from linuxpreloaded.

Of course, if the visitor opens an account and logs in, you will have flagged their account (ie, use their account data on the server as the resting place of the piece of information that says that they came from linuxpreloaded) and so could easily check when they make the buy if any referrers were involved.

Storing the IP is not necessary, but you may want it as a fallback if they don't use cookies or have cleaned their system of cookies. Of course, IP is not a good identifying marker as I think many ISP's recycle these quite a bit.

In short the best solution is to have the client open an account. At the time they do this, make sure to store any identifying info being passed around that says "this person came from linuxpreload". In this way, this info will not be subject to cookie eating or IP swapping. It will be in the account and the person will be recognized by their ability to log into it, which they presumably will be using at the time of the buy.

Sorry for the generalities, but I don't know exactly who knows what. I don't think 1, 2, and 3 are mutually exclusive.

[Some repetition to conclude...]

The goal is to identify a web page request as coming from linuxpreloaded. Persist this information, preferably immediately, but certainly before the "session" as defined and maintained by the platform ends (since this may happen after only a few minutes or hours if there is even a session.. actually, whoever provides the cart is already maintaining a session so you should piggie back off them if you trust them and like their parameters (eg, session length)).

To persist, you need not store anything on the server if you can capture the valuable information (that linuxpreloaded was involved) as a simple tag used as a cookie itself. Otherwise, the cookie can serve as a key (or handle) into the server data that is larger and holds what you want (maybe cart info).

And using a cookie is a nonideal situation but at least may be able to reidentify the visitor if the visitor uses the same platform and has not deleted the cookie.

Ideal is for the visitor to be identified because they can log in to an account. If they ever open an account, move the cookie info over to the account at that point before you lose the info (that they came from linuxpreloaded).

Oh, and if the intention is for the visitor to buy within a (short) "session" then you never need to deal with cookies or with persisting anything except that you still have to add some data to the session (which may get passed back and forth) that can be checked once the buy transaction is done. [A "session variable" might be how you tap into this info; the data would be passed back and forth in any of several ways (see below for more details). The data would be a flag "I came from linuxpreloaded."]

I can give more or less detail on any of the above (based on how I think this all works). For example, I hardly discussed the idea of passing information within the web page itself. This is probably how a session is maintained. The thing is that closing the browser almost definitely kills the session and it may be terminated even earlier by the server software/libraries if configured as such. These web pages, btw, are dynamically generated since that is the only way to give different visitors a different page which was the assumption (that session data was passed back and forth through the webpage, eg, though the urls on that specific dynamically generated web page or through form variables which get passed in a POST request when the user clicks a "submit" button).

Oh, and there is an http header that can also be used to maintain a conversation (the server might use this mechanism in lieu of or along with some other mechanism such as the encoded webpages described in the previous paragraph). That too might die when the browser is killed (unless the browser saves this to disk). Basically I think it's the browser's job to pass a unique tag as an http header whenever the browser user goes to a page from the given domain or from the specific web page (url minus the form data portion at the end) that requested the connection be maintained (the server would have to be asked/configured to preserve a session for a given webpage request.. likely joomla does this and more automatically).

I'll be happy to repost more clearly if I am given more details.

PS: If I don't reply soon to a reply, it means I probably haven't gotten around to checking. One can always post a private message since that is more conspicuous and I am likely to see that eventually when I refresh a nuxified page (which I do periodically when I am not too busy, but I expect to be busy).

ariadacapo's picture
Joined: 2006-07-13
Thanks for the long reply

Thanks for the long reply Jose. I must say it's all a little confusing to me (haven't got the right background for that...) but I'm slowly getting my way to understanding what you mean.

Joined: 2007-09-10
[Note, the most useful part

[Note, the most useful part of this message, at least upon first reading, is probably the wikipedia cookie page, in particular the 3 sections of that page I mention below. Also, read the PS at the bottom for more information on cookies that I think the wikipedia page missed.]

>> I must say it's all a little confusing to me

I thought maybe I went too far, but better to go too far and know right away.

I have not done a lot of software development of the type mentioned, but I have been a very interested and motivated student of many parts of the web in the past.

For reference let me list a few resources. Some of these are about as close as you can come to defining the official way the Internet/web runs.

HTTP protocol v. 1.1:
HTML 4.01:
[also things like cookies and url]
[also perhaps some docs on php and joomla]

These may reference other items which you probably want to look at at some point too. And don't think you are supposed to figure it all out in one or even several attempts. In fact, I am listing it so that you know it exists since it generally answers questions definitively that you may have (but it takes a while to get used to the documents).

A tool you may enjoy if you don't already is wireshark/tshark (or ethereal/tethereal). It basically peeks at the contents of network packets and then interprets them in a much easier to digest fashion. With it you can see things like the http protocol in action and the delivery of html when you browse web pages. You can see what your browser sends out and what it gets back for example. Then you can use the reference above to follow what is going on.

I think the best way I can help is if you ask specific questions. Maybe I can set up an example and point to the specific sections of pages that cover the answer to the question. There are probably online pages that explain some aspect of this well.

Here are some pages that may help you come up with questions. The cookies page is very good. I recommend that you read at least the three sections mentioned below from the wikipedia cookie page before finishing the rest of this post: (pay special attention to sections titled "Cookie poisoning" and "Alternatives to cookies" and "Implementation")

Quoting from the "Implementation" section
>> The Set-Cookie line is typically not created by the HTTP server itself but by a CGI program. The HTTP server only sends the result of the program (a document preceded by the header containing the cookies) to the browser.

What this is saying is that joomla, which is an application written in PHP I believe (I have very limited experience with PHP and none with joomla), has it's own way of setting http headers or of setting cookies or of doing anything else (joomla/php would be the "CGI program"). This means that you have a special joomla-ish way of accomplishing the above. For example, there might be a function that sets cookies. When designing the page, you use that function (I guess as PHP). Or maybe joomla provides for templates or configuration files you build. Or maybe you simply build pages through a web interface without hand coding any php. Whatever. When that page gets requested (http GET or POST with that given url path), the PHP plugin running on the webserver (like apache) or a stand along php app/engine swallows up into memory the page (and perhaps what constitutes a part of joomla) and then interprets that requested page. Eventually, the "page" is spit to the server which sends it out to the browser (possibly after manipulating the page somewhat). The "page" includes the http header and then the contents which likely is an html page (it could be xml, text, a pic, a movie, etc). Within the http header (or as meta http-equiv within the html header section) would be the "cookie" which as indicated in the wikipedia article is basically an http header that looks something like 'Set-Cookie: thecookiename="fdogjoiajlkjvlkjiotgji--session-id-for-this-user--dlkfjoijareij0ijvijertijdvioj" ' [Note that http headers can be inserted directly ahead of the html page or will be inserted automatically by the server if the proper meta http-equiv tag is in the header section of the html page; see .]

[That was a tough paragraph to read. I know.]

Take this simple example. Browser asks for a page. The page is identified as php (through Apache configuration options). Apache sets a php engine loose on it. The engine spits out [http header] [a blank line] [html file]. Apache takes that and sends it straight through to the browser. [Note that the particular php page may have been a page generated by the joomla framework based on what the admin did through a web interface. The joomla "framework" is simply a set of php pages that might lead to other php pages getting spit out/created.]

Keep in mind I am familiar with a lot of this but may have made mistakes in the explanations out of laziness of not looking something up and memory failing or never have learned it well. But, I am probably fairly close or right on. The part I really had doubt on was about joomla. PHP is a language and there are applications (aka "interpreter" "engine" "plugin" etc) that read it and follow the instructions of the php program. I think joomla is nothing but a very large php application. This means you make sure apache is running and has a php plugin and mysql is set up properly (because joomla uses mysql... see ). Then a call to a page that apache identifies as php, leads to php interpreting the page. Again, I think joomla is just a particular set of php pages (including pages to administer and configure). I imagine it stores a bunch of php functions in there to do everything joomla does. It provides an api in php I presume, which means that you can hand build php pages that call up these php functions/API provided as part of the joomla package.

Hope this was helpful even if a little disorganized.

All corrections welcomed.

PS: Maybe this helps to understand cookies a little better, but it doesn't answer any of the basic questions asked originally. If you get comfortable with what a cookie is and why they are needed to hold state.. if you get comfortable with the pieces of the puzzle, you may find that you will know how to answer you own question. PHP works on the server. I didn't mention it, but javascript is a part of an html page and it only gets interpreted/run by the browser (it gets passed through uninterpreted at the server end). Javascript is capable of manipulating cookies the browser has stored. It provides an alternative way to create cookies (besides having the server pass them as http header commands). Remember, a cookie is basically just an http header (name=value with expiration etc) that the server passes to the browser requesting some page. The browser then takes it upon itself to store that cookie/message and pass it back whenever it asks for a page from the same domain (I think the wikipedia article explained this somewhat.. also, you can lookup the set-cookie header in the rfc 2616 specification, but that won't be nearly as useful as a good explanation of how it is used in practice by servers and browsers). Javascript sent as part of an html page is a language the browsers know how to interpret. One of the things a browser may expose to the javascript is a way to create/manipulate/destroy cookies. This is a feature of the browser and has nothing to do with the http protocol (so it's a way to transmit cookies out of bandwidth from the point of view of rfc 2616; it isn't specified by that standard). See . Finally, cookies are not the only way to help maintain a session/state. The wikipedia cookie page also mentions things like form data, specially build urls, etc.

Joined: 2007-09-10
The second half of the

The second half of the reply above is confusing. It was like me talking to myself.

I think the cookie wikipedia page and the link on cookies and javascript at the very end might be the most useful. Do you have questions on that?

When you use joomla, or even php, you can do a lot without really knowing what is going on. That is part of why they are popular, because they bring utility without requiring a PHD. However, not knowing some of the details of the plumbing makes it easier to get stuck.

As far as me being able to help out a bit, is there anything that perhaps I could focus on? It's tough to explain things when I don't realize that some words I am using might be meaningless. The words exist because they are useful but they are not useful if you don't know what is being refered to.

Joined: 2007-09-10
A second crack

[In what follows, the second option about cookies is probably what you want; however, what I describe with cookies starts off by using the marker concept from option 1. You can't avoid an intial marker of some sort to identify a referred visitor, even before the vendor builds the very first cookie. You sort of can if you try and use http "referer" headers, but the bottom line remains that the referer must be identified. Anyway, you may want to clarify what the vendor means through this "marker" business. I don't think it is mutually exclusive to using cookies. At least not in identifying linuxpreloaded visitors initially. Also, cookies are simpler to use than pushing a marker back and forth through url rewrites unless you have a solid system that does this for you automatically and has been debuged well. In this case, use it since it would work without cookies needing to be enabled.. but there are many ways to make a mistake if you do it on your own. You may be debugging for a while. I would use cookies if I had to start from scratch. Or so I think, since I haven't done this before. Finally, I should point out that the example given for the cookie option (2) is somewhat like a step-by-step procedure to tracking a visitor.]

Let me take another crack at the problem stated at the top.

>> 1. We append a special marker to the vendor url, and they keep that marker all throughout the customer's visit on their website until the final purchase.
Vendor reports they tried going this way but had no success.

Maybe you mean that when the vendor receives a visitor that came from a link on, the page that "receives" the url also receives many other urls and so the code on the page disects the url to capture any unique marker. The vendor can do this through url rewriting, urls with a query portion, and maybe in other ways, but the effect is the same.

OK. So now you say that they keep this marker "all throughout the customer's visit on their website until the final purchase." I think you should try and ask for more specificity here or at least clarify what you mean.

Sessions can be maintained through cookies, yet you mention that as option 2. [The marker could be passed to and from the browser as a cookie for example.]

Probably what you mean here is that each page returned to the browser has unique markers "in the urls" (in the hyperlinks on the pages that link back to the website), much the same way as the original url that was on linking to the vendor was designed (??). Another possibility is that POSTed form content carries the marker over. If either case (or if I am missing something else), the destination back at the vendor for every such link must look for this marker. The marker must be identified no matter what the visitor clicks on. Then besides identifying the marker on the incoming url, every new generated page that will be returned in reply to that url request must make sure to pass the marker back. This seems like more work than using cookies, btw, because here the vendor must manage all of this reprocessing and shuffling back and forth. With cookies, the http standard specifies that the browser has to return them back so that you don't have to specifically encode them in the urls or html forms of every page sent out. Also, with cookies, I think you only need to even bother to look at the cookies at the time of creation (on initial visit) and at time of checkout. The rest of the time they are passed to/fro automatically.

>> 2. We/They use a cookie. I am not sure of who sets the cookie and how the vendor is going to read it.
Vendor reports they are investigating this possiblity, I don't know much more about this.

Here, the links on cookies I provided in an earlier post may be very useful.

Assuming the vendor is using PHP, there are simple functions to create/set/view cookies.

The first task is to identify the visitor as coming from You can't bypass that step. I'll assume this will be done through a marker on the url (as what I think option 1 was saying). Another option is for the vendor to look at the referer header of incoming requests since it should have the domain. A possible problem with this method is that the referer header is sent by the option of the browser depending on how it was configured by the user (it's a privacy issue). This means it many not be set or set correctly. Another option would be like option 3 "we point to a special url (reserved to us) on the vendor' site;" however, this is just a general way of describing the specific case of putting the marker on the url. A marker inside the url is nothing but a "special url (reserved to us) on the vendor' site."

OK. So assuming a marker on the url (or a special url) allows the vendor to identify and incoming link as originating from The vendor parses the url and recognize that the link is from At that point the vendor stores in the database a small record on this visitor. The vendor assigns a unique cookie to that record and sticks the cookie in the page being generated as a reply (eg, use the PHP functions to create cookies). At checkout, it tests for that cookie and ultimately links it to the entry in the database from before that shows the visitor came from linuxpreloaded.

An example:

The url on linuxpreloaded is something like "" OR similarly there is a form on the linuxpreloaded site with '... action="" method="get" ' and an input element in the form named "Icomefrom" that will have a value of "linuxpreloadedTheBestSiteOnline" when the "submit" action is activated. [see ]

The vendor's page that receives this url will have to process every incoming request/url.

Here it learns that the Icomefrom variable has value linuxpreloadedTheBestSiteOnline. This would be the marker. At this point, it creates an entry in the database in a section where it puts all sessions that came from linuxpreloaded. For example, there would be an existing mysql table in the database that was created with a field for "referrer" and another field for "visitortag." Then using PHP you would add an entry (using an SQL insert command) to the table with "linuxpreloaded" or some equivalent id (eg, maybe 475 represents the referrer id for as the "referrer" and "VIS8989789537945" as the "visitortag".

With an entry for this new visitor created, we insert a cookie into the page. This means we use the PHP function for adding a cookie.. the PHP engine interpreting this create cookie function will make sure that an http Set-cookie header entry is created along with any other http headers created for this page. With this sort of function is how PHP saves you from having to code the http Set-cookie header by hand. After googling.. I think the PHP function to create a cookie is "setcookie": see or .

The cookie *name* can be something like "initialreferrer". The cookie *value* can be the same referrer value inserted into the database "linuxpreloaded" [see a few paragraphs down for a better cookie]. In fact, it better be something that allows you to test against the database later on. Make the expiration value something meaningful since when the cookie expires, the user will no longer be recognized .. unless of course, some other cookie or something else (like a login account) does the job.

User now browses with cookies enabled.. shops... leaves vendor site... turns off browser and PC.. comes back next day and goes to main vendor page hoping to get back to shopping.. Because the browser sends the cookie on every visit to the vendor's domain name [verify this], the user gets back to shopping. To do this, the vendor has to make sure it recognizes this visitor as "VIS8989789537945". This can be done through a second cookie.

Alternatively, you can set only one cookie from the very beginning. The cookie can be named "visitorid" and have value "VIS8989789537945" (in lieu of "initialreferrer" with value "linuxpreloaded"). This would be the way to go since you can use this visitor id to look up any and all information on this user. You might us it to look up what they have in the cart for example (to implement shopping cart). AND ...

... after a few days of repeating this cycle, the user finally buys something. Here the code to process the transaction grabs the cookie(s) (eg, a PHP "isset($_COOKIE['VIS8989789537945'])"). Doing a PHP query against the same database as before against the table with the visitortag and referrer fields, you find out that this user has a referrer of "linuxpreloaded". Ie, we use the cookie value of "VIS8989789537945" at checkout to query the database to see if that id is attached to a referrer (use something like "select * from thereferrertable where referrer='linuxpreloaded' and visitortag='VIS8989789537945'). In this case, it is, so...

BAM. You cut a tiny check to

Case closed.

>> 3. We point to a special url (reserved to us) on the vendor' site, which redirects to the vendor's homepage. This allows them to log all the IPs of links incoming from us. Upon purchase they compare the buyer's IP with the log of (say) the last 48hours.
Vendor told me they are trying this way.

As mentioned above for option 2, a "special" url can mean anything. It can be what we did with option 1.

As for keeping track of IP addresses, I would use this as a last resort IF you even wanted to allow shopping without cookies enabled. IP addresses change every so often for the same user even from the same PC or device. If the shopping cart works without cookies enabled (eg, url rewriting) and cookies are not enabled, then use IP. Here attach the IP addr to (eg, put it into a database table similar to what was shown above). At checkout, query over linuxpreloaded to get all IP attached to it. Then compare each one to the current visitor IP address.

To recap the main alternative to cookies:
Doing things without cookies means that the vendor must follow every possible path the vendor wants to allow the shopper to take so that VIS8989789537945 is always sent back with every page. But this may not be possible to pull off once the browser gets closed unless (eg) the shopper saved a page from the prior shopping experience and then went back to shopping through a link on that page (this may not even be possible if the browser saved the page with links pointing locally as mozilla does since it saves all the graphics and items from a page locally when it saves a page (firefox doesn't do this by default so ff would be ok)).

Hope this helps.

Joined: 2007-09-10
Third Attempt

Here is a simplification of the portion of the above reply that pertains to option 2 (cookies). I change a few things. This may serve as a guide to implementing what you need/want.


Page one:

A link on leads to the vendor. This hyperlink has a marker within the url that looks like this "?referrer=linuxpreloaded".

Page two:

The vendor page pointed to by that link is a PHP page.

During a particular visit originating from PHP code on that page checks the name/value pairs passed along in the hyperlink. It finds out that "referrer" has value "linuxpreloaded".

More PHP on that page then generates a random number, eg 25345634636. It then creates a string from that number by prefixing it with "VIS". Afterwards, this string "VIS25345634636" is inserted into a database table. It is inserted into a field/column named "visitortag". In that same entry the string "linuxpreloaded" is inserted into the field/column named "referrer".

PHP code now creates a cookie with a name of "visitorid" and a value of "VIS25345634636".

At this point, nothing else special needs to be done, so the rest of the PHP code for that page does whatever it did before to create the page.

Page three:

The page that finalizes a checkout transaction is another PHP page. Before completing the transaction, PHP code gets the cookie named visitorid if it exists. If it exists (eg, if it didn't expire and the user didn't clean out cookies), PHP gets the value and finds VIS25345634636. It queries the referrer table with that value and finds out that an entry exists and the referrer is linuxpreloaded.

The PHP now computes a percentage it will pay to the linuxpreloaded account. It updates that account in the database (maybe a different database) with this amount.

The End.

PS: I don't include code examples to keep things simple. The prior longer post mentioned some examples of sql queries and simple php cookie handling. In those cases, keep in mind I conceived of these on the fly from what I found online.

Joined: 2007-09-10
To unsimplify a bit... 1 --

To unsimplify a bit...

1 -- There are many ways to generate an id for a new visitor. Also, when creating a new id and putting it into the database, you may want to also add to the database information such as which product or page this visitor is first visiting and on what date.

2 -- You probably don't want to use the word "linuxpreloaded" in the url that leads to the vendor. Better might be for the vendor and linuxpreloaded to agree to some more cryptic marker (eg, 2rwfw34trfv3q4t5ewrf). In this case, the vendor may have as the final step prior to updating the referrer account be a translation of that value (2rwfw34trfv3q4t5ewrf) into the proper account id (which would be the account id the vendor has designated for

In fact, the value of the marker might be refreshed between the vendor and linuxpreloaded on a weekly basis. Each new marker would allow the vendor to know if a visitor is visiting from a current/fresh page or from an older saved page. Also, the new marker could be used for other identifying information, perhaps to learn from precisely which page on the visitor came or even from which link on that page if more than one link on the same page point to the same place.

This marker information (eg, the marker itself) could also be placed into the database when the initial visitor id value is created and inserted into the database. This would allow for a later pass through the database to process this information to perhaps learn where to better place future linuxpreloaded links.

Joined: 2007-09-10
I was looking through

I was looking through virtuemart online docs.

I think what you want to do is to hand build a PHP page (under the vendor's control, ie, at their site) to accept the direct link from This means, we would hand code Page Two above. After the PHP does everything mentioned above, you want to use whatever PHP function allows redirects. At this point you redirect to some page on the vendor's site under the control of Joomla/virtuemart I presume (eg, a product display page).

You may also first have to set up a mysql table with fields "visitortag" and "referrer" or something like that.

Finally, we should be able to test that page without even bothering We just take a browser and type in the url for that Page Two with the proper added name/value pair query string (ie, "...?referrer=linuxpreloaded") and the browser should pass through Page Two on its way to the vendor page that Page Two redirected. Then we can look inside the database directly to see if the proper entry was created (the vendor might use mysql cli tools or some gui to query the mysql database at the vendor's site where the new table was added; or the vendor might make another PHP test page to query the table and print out its contents to make sure a new entry is created after each visit to Page Two, ie, we'd go to this test page after each visit to Page Two and redirect to confirm that a new table entry got created).

When we verify that Page Two is in fact creating database entries that look correct after any new visitor and that redirection works, we can implement the cookie. Then we test that the cookie is working by hand coding a simple PHP test page that just grabs cookies and prints the value. So we first visit Page Two and then visit this cookie test page to verify that Page Two added a cookie. Note that the test page would have to be in the same domain as Page Two (ie, for the cookie Page Two set to be seen. Also before repeating the test, we'd have to clean out cookies from the browser (at least for that domain) if earlier tests added a cookie with the wrong info (probably we can avoid cleaning out cookies and still feel relatively sure that everything is working, so don't worry too much about cleaning browser cookies -- but if you want to clean cookies out, you may want to use a new broswer profile for testing so as not to disturb your existing cookies).

Finally, we have to add some extra stuff to the PHP page that handles checkout (or add in a hook somewhere to a page that does this extra stuff). This would be Page Three I am talking about, but we'd have to interface/interact with Virtuemart to accomplish this.

I don't yet know how this last part will be set up; however, I think the following may provide the clues we need .

I will try to help you using that document page and anything else, but it will be easier if right off the bat we can narrow down to a specific payment processor, eg, Paypal. See this page .

So if you are interested in setting this test up and hand coding some small amount of PHP (I have not really done PHP, though I am somewhat familiar with the overall picture), perhaps post which type of checkout payment processing system you want to cover. For example, if we deal with Paypal, we might have to take a copy of a page called notify.php provided by virtuemart and add in our hand PHP and place it in the proper location on the server. Then we would go to Paypal and let them know that this is our hook... but I am not sure about these details yet. I am still reading the virtuemart docs.

Anyway, if interested, what payment system should we focus on?

Joined: 2007-06-08
Yes there is a solution.

It requires some work and is not free but it is do able. It is called Idev affiliates. We have installed configured it and will be using it on one of our commercial websites. It works best if community builder is installed. I would be willing to help setup and configure it if need be. There is a plug-in that enables Idev to integrate very nicely into Joomla and Virtuemart. It is not Freedomware however and it costs about $150 USD but it does work very well.

It would be able to handle everything from tracking and paying affiliates per click through to just crediting them for each purchase via Virtuemart and much much more....

ariadacapo's picture
Joined: 2006-07-13
I'm sorry, due to an

I'm sorry, due to an extremely high work load these two last months {it's not quite over} I totally dropped this thread, which btw was quite hard to follow for me.
In the end our sponsor implemented a cookie-based solution, I don't know much more details.

Thanks and sincere apologies,


Joined: 2007-06-08
No worries.

I understand completely. No need to apologize. Really. Smiling I am glad to hear that they were able to make it work.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.