Bizarre CGI-Bin related error...

[Marci]

I'm confused here...

head to http://store.over-clock.com in Firefox, and click a link in either "New Products List" or "Best Sellers List"... it'll open perfectly.

Now try the same in InternetExplorer(7) - you'll get a 404 error (hopefully... cos I do!).

Why would the browser being used make any difference at all to the Search script?? Anyway to make the product links in these two blocks go direct to the product without using the search script (ie: static link to http://store.over-clock.com/[sectionpage].html#a[prodref] - that'd be a quick fix)??

EDIT: QuickLink to solution - http://community.actinic.com/showpos...0&postcount=34 - tis all down to REFERRER being cookie'd and tab'd browser retaining session... define referrer at end of each URL from outside your store (/acatalog/) by adding &ACTINIC_REFERRER=http://your.web.site/acatalog/ to the end of each link. Bin cookies and cache... problem solved. If your customers experience this odd issue, you need to instruct them to bin cookies and cache, or, if experienced, can tell them to bin the cookie tied to your domain name entitled ACTINIC_REFERRER, and their cache (to save em losing all their cookies etc). But only instruct them to do this AFTER you've amended all your links to include the referrer statement above...

[dave_finlayson]

Marc,

Seems to work for me in both Firefox and IE 7

[Marci]

OK - now I'm REALLY confused then!! Could a few others test this please...?!

I've tried it from 3x separate PCs here, and IE7 always produces a 404 error as the search script points it to http://www.over-clock.com/[sectionpage].html#a[prodref]
whereas if I try it in Firefox it succesfully lands at http://store.over-clock.com/[sectionpage].html#a[prodref]

Does the FRONTPAGE of our site's New Products list also work ok for you in both IE and FF?? (http://www.over-clock.com - top righthand corner - used actinic to generate a separate newproducts.php file that I've php-included within VirtuaNews CMS as a variable) [NOTE - if u don't see it, scroll to bottom of LHS column and flip site skin from "O-CuK2005" to "O-CuK2007"]

In fact, if I manually copy and paste a link (such as http://www.over-clock.com/cgi-bin/ss...=289&NOLOGIN=1 ) into Internet Explorer, it lands on a 404 error. If I past the same link into FireFox, it gets there perfectly.

The correct destination for the above link is http://store.over-clock.com/pumps.html#a289
IE7 lands the above link at http://www.over-clock.com/pumps.html#a289 (404 error)

This results in all links (via the search script) to products within news posts on our frontpage also landing on 404 errors, effectively meaning any customers using IE7 are gonna get VERY p****d off fairly rapidly...

Point to note - I haven't made ANY changes whatsoever to the ss000001.pl search script file either - it's the stock file as supplied by Actinic...

I'm currently looking thru the "DirectLinkToProduct" subroutine within ss000001.pl but I may as well be trying to read Russian...

[Marci]

Definite problem - it does exactly the same on my home PC...

The only PC I've found that DOESN'T have issues so far and all works correctly runs IE6 rather than IE7...

[TraceyHand]

IE7 works fine here too...it's having no problems redirecting the result from www. to store.
consistent results with FF and IE7 here
Sorry, not much help!

[pinbrook]

IE7 works fine for me too

have you cleared cache etc?

[Marci]

Yep... cache cleared... no change, same problem...

EDIT: or not... now BOTH have the same problem. Both IE7 and FF now produce 404 errors on links via the searchscript.

[dave_finlayson]

Think I see it. You cgi links are going through 'www.over.....' but it looks like the shop is on 'store.over...'. If I manually enter the link with 'www' replaced with 'store' it works.

Could it be something in your metwork setup?

[Marci]

Nope... it's nothing to do with the subdomain... ss000001.pl should handle going from www. to store. without issues, as it has doneso for MANY years. That problem is resolved by implementing the demon cookie fix... as cookies are the only thing that that script sorts out, that implies that all the CGI scripts will work happily from what is effectively a different domain, and is indeed the case as we've been operating our Actinic-based store like this for at least 4 years now, if not more... (see http://knowledge.actinic.com/acatalo...394.html#a1097)

Further developments - the shopping cart now refuses to display images defined by the stylesheet, and now spools off a load of errors for me... Am beginning to suspect BaseHref is being mis-defined...

[Duncan Rounding]

I just tried your given link that you say doesn't work:
http://store.over-clock.com/pumps.html#a289
and it worked fine for me.
Qsearch works ok too.

[dave_finlayson]

Yep and if you change it to www. it won't work. Have you updated recently and maybe the script change hasn't been implemented properly?

[Marci]

This is REALLY wierd folks... I swear I ain't making this up, and have replicated the issue on 5x separate PCs, 3x of which are in a different location on a different connection.

Have discovered that for some reason Actinic has rendered the site using "www.over-clock.com" as the base href, despite the CatalogURL being set to "store.over-clock.com" within network settings... have hard-coded the <actinic:BASEHREF> tag within the header now and am doing a full site refresh at the moment...

I'll keep updating this thread as someone at somepoint may get the same inexplicable issue on their site...

Given the fact that this only occurs for a handful of folks (a few of my forum-regulars have confirmed the problem also) I'm assuming it's something to do with cacheing... next step will be to set everything NOT to cache via <meta HTTP-EQUIV="Pragma" CONTENT="no-cache"> and see how that affects things (if the current refresh doesn't have any affect)

[wjcampbe]

It will certainly affect your search engine positions.....

[Marci]

Well... in an "i'm sick of this" moment, I ditched the new site skin and restored the old snapshot that I KNOW works perfectly and performed a full site refresh... and, surprise surprise, the fault is now there in the old skin too. I'm now at a loss... have no clue which way to go from here.

[dave_finlayson]

have you checked your script amendment you mentioned earlier is still in place. It may be that Actinic has overwritten it with the original.