domain name path problem

[Perfect Eye]

Whilst testing the basket of our store we have picked up on a little niggling issue around the actual entry of our web address which has us stumped.

When we type www.readingnightlife.co.uk/acatalog into Internet Explorer the page redirects us to http://readingnightlife.co.uk/acatalog/ and the basket doesnt work in the brochure pages, but does in the cgi-bin pages. All the brochure pages say http://readingnightlife at the start, as if its ignoring the www. bit, not referencing the cgi bin basket correctly.

When we type the complete path into Internet Explorer which is http://www.readingnightlife.co.uk/acatalog/ it goes directly to this URL and the basket DOES work across all pages. And all pages begin with www.readingnightlife etc.

I am led to believe this is either a cookie issue or network settings. Can anyone check this out and give me feedback?

[I-CC]

Does all of your network settings for URLs include the www portion, i.e. none of them are like a http://readingnightlife.co.uk/acatalog/ instead of http://www.readingnightlife.co.uk/acatalog/ are they?

If they are, then change them to include the www and then update..

[Perfect Eye]

Hello, these are our details in Network settings, I dont see anything that'd cause the problem, but i could be wrong:

Server details:

Catalog URL: http://www.readingnightlife.co.uk/acatalog/
CGI-BIN URL: http://www.readingnightlife.co.uk/cgi-bin/
Codebase: ./
Path from CGI-BIN to acatalog directory: ../acatalog/

Common Settings:

CGI Script ID:1 Extension: .pl
Web site URL: http://www.readingnightlife.co.uk/
Path to Perl: /usr/bin/perl
Ignore passive transfer errors ticked
Use relative CGI-BINs in Catalog pages not ticked

FTP Details:

Server Host: ftp.readingnightlife.co.uk
User name and password are in correctly
Path to CGI-BIN: /cgi-bin
Path to CGI from Directory as viewed by ftp is not ticked
Use Passive ftp transfer is ticked

[I-CC]

When you login via FTP, are you placed straight into the public_html (documents) folder?

Reason I ask is that you have path to cgi-bin as a straight /cgi-bin and no leading top level (non public area) like /documents/cgi-bin or /public_html/cgi-bin

Not sure if it is related, but normally you would have a folder which is non public above the ../cgi-bin area.

[Perfect Eye]

With supanames there isnt a top level folder. The root is literally: ./

(on a previous host for a different project there used to be a /web folder containing all the subfolders/files etc).

I've attached a screen of the structure of my folders when i log in to ftp to demonstrate this.

Do you think it might help if we ticked the use relative cgi-bin URLS in catalog pages? We dont want to tamper in case anything messes up.

[I-CC]

Hmmmmmmmmmmm it has something to do with having a trailing / on the end of the acatalog folder...

If you click on links which do not have the / on the end, then it redirects to the non www, but with the / on the end, it keeps to the www

I would speak with your host on this one as it is something to do with how the folders are set up on your hosting account I would suggest and not really anything to do with Actinic, although having them on the end of URLs that are just acatalog/ would help, but that is not the problem and the set up somehow is...

[Perfect Eye]

Thanks for the feedback. We're only currently using this hosting for the testing, when we want to go live officially we'd like to switch to another hosting package that supports Actinic. I notice that you offer smtp relay mail, and the shared SSL at a discounted price, so we're considering 4surehosting. Our client already owns a domain name and has basic hosting, would it be straight forward to migrate across to you if we chose your package? (would you also supply the network settings for Actinic that would upload to your server space?). Cheers.

[I-CC]

We provided Authenticated SMTP for usage within your email (Outlook) clients, but this is not required for Actinic to function with regards to email as our servers are set up to allow passage of emails from the site under authority of the domain being on the server, so localhost is the smtp address within the Actinic software with our hosting.

Network setting files are provided with instructions at account activation by our system, with this page providing more http://www.4surehosting.co.uk/inform...rk_files.shtml.

If you want want explicitly build/created for you, then email us once account activated and one will be knocked up for you, with 1 in 10 asking for it to be made as opposed to following the instructions above.

Yes, we directly provide the Actinic Shared SSL system on our servers.

Migrating across takes DNS Propagation time of approx 24 to 48hrs and is normally quite straight forward. Most .com users delegate there domain to our name servers, with .co.uk domains added to our Nominet UK IPS Tag and we then delegate the domain.

[Perfect Eye]

Slightly off topic: If we are using Worldpay as our debit card transaction company does the actual credit card detail entry page have to be on their site? * Do you know if we get any control over look and feel? (from just testing it goes away from our site to a secure Worldpay branded page, does this eliminate the need for the Actinic SSL as its gone to a secure page anyway, or can that still be implemented??)

*PS. We havent got a worldpay account yet, we just picked this in order settings from within Actinic to see what would happen to the order pages on our site.

[I-CC]

Slightly off topic: If we are using Worldpay as our debit card transaction company does the actual credit card detail entry page have to be on their site?

Yes under Actinic usage it does.

* Do you know if we get any control over look and feel? (from just testing it goes away from our site to a secure Worldpay branded page,

You get an online control panel with WorldPay where you can customize the payment pages with them to a certain degree...

* does this eliminate the need for the Actinic SSL as its gone to a secure page anyway, or can that still be implemented??)

It does remove the explicit need for Actinic Shared SSL, but in recent months we have had signups from those using WorldPay, Protx and SecPay due to those payment provider suffering from Distributed Denial of Service (DDos) attacks, so they use our Actinic Shared SSL as a back up payment detail receipt solution when these occasions occur, and then process the card details through either a terminal (bank approved for Internet transactions) or online terminal provided by the online PSP (when it comes back online after the DDoS).

*PS. We havent got a worldpay account yet, we just picked this in order settings from within Actinic to see what would happen to the order pages on our site.