Their (Aliant - e-commerc provider amongst other things) Server Side .asp is
quite old, and awkward. I am trying to update some things for a client who
had her site built 3 years ago - based on this old code which is still being
used. Here is a sequence of events...
1) Interested buyer goes to her site and follows link to her sale items.
(
http://mysite/supertest.asp)
2) This page is an .asp generated page which checks database and returns
list. Alternately, if the purchaser clicks on an item from the list, then
this same .asp page loads, with a value ProductID being passed to it.
(
http://mysite/supertest.asp?ID=439)
3) Once ProductID is passed - a single description is generated (if ID==""
then find the specific item).
4) If the person wants to buy, then they click a "Buy Me" button which
passes info onto the e-commerce site - an order confirmation page.
PROBLEM: This Confirmation page is very generic. It is meant to be passed
info like: Product ID, Description, Quantity and what Merchant sold it. This
means that Aliant - the e-commerce provider will not change any of the
script for a specific customer, since it works fundamentally for all
merchants who use it.
5) There is a <Continue Shopping> button which looks more like
<input type="button" name="Continue" value="Continue Shopping"
onclick="ContinueShopping('http://mysite/supertest.asp?Id=439');">
It has gathered the from, in the passed information.
PROBLEM: This brings the buyer back to the specific unit they were looking
at - rather than the list - since ID <> "". Now the confusing part really
begins. The common user will click <back> from here thinking they will get
back to the list. They do not, as <back> really leads them to the Order
confirmation screen again. To make things worse, there is actually a
redirecting site before the Order Confirmation screen, so if you hit <back>
again your info is thrown from the Meta refresh back at the Order Confirm
site, doubling it. You can stay in this very confusing loop all day.
My attempted solution: Use HTTP_REFERER to catch the URL once you click the
<Continue Shopping> button. I was then gonna write an if/then that said - if
it came from the e-commerce site, then redirect to the
(
http://mysite/supertest.asp) site - no ID - so that list would show up
again. Unfortunately the REFERER does not catch the URL, it passes "", so
the redirect does not work.
Many customers have complained about this annoyance, and she figures she
loses 5-10 sales for every person who actually takes the time to complain.
Hey - wait a sec... think i just talked myself into solution. Will ahve to
test this. I am thinking that the only real way you would get to this site
with REFERER having a value of "" would be if you came back from the
e-commerce site... EUREAKA! This may be it.
Let you know,
D.
"Ray at <%=sLocation%>" <myfirstname at lane34 dot com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
You're saying that the previous page the visitor is coming from is not on
your site or on a site that you control? Can you specify the value in
that onclick event? If so, you can ask them to change the url to something
like:
onclick="ContinueShopping('http://mysite/supertest.asp?YesTheUserCameFromThi sSpecificPage');"
Now, that won't tell you where the user came from, but if this page you're
trying to check is the only one that puts the person at your site with
that querystring, you'd "know."
Ray at work
"Drifter" <loreseeker_prime@hotmail*removethis*.com> wrote in message
news:bp**********@nntp-stjh-01-01.rogers.nf.net... Using HTTP_REFERER I cannot capture the URL when the link is made via a
button:
<input type="button" name="Continue" value="Continue Shopping"
onclick="ContinueShopping('http://mysite/supertest.asp');">
I do not control the script above, it is on an e-commerce site that is
very generic, meant for many users - and is generated by their server code. I
want to capture the URL and with an if/then redirect if the last place
visited was the checkout site.
I need an alternate method of URL capture, rather than HTTP_REFERER.
Thanks,
D