Blank admin and store on live server

[peterp]

Hi All,

I have just uploaded a developed cubecart latest version site to the live server and now all I get is a blank screen in both the admin and the store. The site is working perfectly on the localhost machine all of the parameters have been setup correctly. (see below)

I have checked the error log see below

This error log screen capture is the last one in the system error log file, what mystifies me is that it seems to be referencing xampphtdocschampcoclothingtestnew which is the development site on the localhost server. I have cleared the cache files and still get the same blank screens.

I don't know where to look next so if somebody could please point me in a direction might help I would be very appreciative.

All help will be welcomed

Best Regards,

Peterp

 

[bsmither]

The screen capture, as you say, seems to show a page request from 'localhost'.

So, are we sure that this log entry was databased from the 'live' store?

Any entry in PHP's error_log in CubeCart's main folder (as configured in ini-custom.inc.php)?

 

[peterp]

Hi Brian,

Thanks for your help I have been checking and re-checking and finally I have decided that the hosting provider may be causing my issues, so at this moment I'm going down that track. My reasoning is that when I test the site on my local server then all is perfect however after uploading the site it doesn't work. I will keep you up to date if I find anything and/or I exhaust the reasoning of the hosting provider being the reason for the site failure.

Thanks again for you help.

Best regards,

Peterp

[peterp]

Hi Brian,

I have been in conversation with the hosting provider and they have come back with a reason why this is happening which I find a little hard to swallow, they seem to think that the reason for the site not working is because the prefix to the database tables is a mixture of capitals and lower case and the database we are trying to reference is all lower case. So I tried their solution and when I used a database that had a upper case table name prefix it did work, not completely but better than it was. The prefix of 'cubecart...' is what we were using which gave us a login screen which was in some foreign language whereas the database that was a mixture of upper and lower case 'CubeCart....' worked better but wasn't showing the information which we had input into the lower case database tables. I vaguely remember that there was a fix for this but I cannot remember when, which fixed the programs needing the mixture of upper and lower case tables. Below is the login page for the lower case database

Unfortunately this is as far as I can get as I have no idea what a valid login would be. I'm just starting to wonder whether it would be better to start again from scratch and use a fresh version of cubecart.

This is where I'm at so any comments would be useful

Hope you can help

Best Regards,

Peter

[bsmither]

Developing on a Windows box provides for the loosening of upper/lower-case lettering constrictions.

Windows considers a database table name of cubecart_config the same name as CubeCart_Config. Same for filenames.

Not so for any other operating system.

So, from a screenshot posted above, $glob['dbprefix'] is an empty string, meaning the names of database tables that are stock to CubeCart must be, for example: CubeCart_access_log. That is, the table name has no prefix, then has CubeCart (with only the two letters 'C' being capitalized), then an underscore, then the rest of the table name is all lowercase. This is the upper/lower-case format that CubeCart will use to construct the query, and any operating system other than Windows will use that exact upper/lower-case format.

Using the database utility that your hosting provider has in the hosted account's control panels, manually check and rename all the stock table names as needed.

 

[peterp]

Hi Brian,

Interesting enough when you load a new version of cubecart onto a localhost server which running widows all the table names are lowercase including the prefix 'cubecart'

When I changed the prefix to 'CubeCart' on the live server it all started working a little better no foreign language login hooray! However there is a problem with the site now as it seems to be not able to find any of the products. I have setup a product with correct category and when I try to buy this product I get a 404 error also if I try to select a category then I get 404 error again. Once again it works correctly on the localhost server but when it has been migrated to the live server it fails to work, is it possible that the live server has something setup that I need to address before a live site will work similar to the capital letter issue. I can modify and maintain the categories and products in the admin screens but when I try to purchase the 404 error occurs.

Any Ideas where I should start looking

Best Regards,

Peterp

[bsmither]

Verify that the live server is running a web server that understands the .htaccess file. Apache, of course, and I think there is one other (but not Nginx).

Even if the web server understands the .htaccess file, the web server needs to be configured to allow the directives in it to "override" any similar or default settings in the web server's main configuration file -- usually the main configuration file is not accessible by anyone other than the server admin. The main configuration file will have a directive similar to "Allow Overrides" - check with your hosting provider.

Then, even if that is good, the .htaccess file must have appropriate directives for URL rewrites, and the web server must have the "mod_rewrite" extension installed.

If, when copying the files from local to live, the "hidden" file .htaccess (because it has a leading period) may not have transferred. Even so, When getting into the admin side of the installation, a check is made for the existence of the .htaccess file, and if missing, will write one out.

 

 

[peterp]

Hi Brian,

I have confirmed with the hosting provider that the .htaccess is running and they allow overriding and have the mod_rewrite extension is installed. Unfortunarely now what happens is the admin pages are displaying correctly and I can do changes to the site, the front page of the website appears correctly but I'm still getting the 404 error. I have checked that the .htaccess file has been copied across and it has please see below

Hi Brian,

Not sure that you got the whole screen shot of the .htaccess so here is the last bit.

Best Regards,

Peterp

[bsmither]

On the live server, are you, in fact, actually running CubeCart in the sub-directory /champco_champcoclothing/, and that the real web address is something like:

http://www.mainsite.com/champco_champcoclothing/index.php

I would have to assume so.

As for the 404 Error, do you get a CubeCart page where it has the typical CubeCart stuff and that the main content area says "404 Error: Sorry but the page you are looking for could not be found.", or do you get very basic page (no CubeCart skin styling at all) simply saying 404 Not Found?

[bsmither]

In admin, Store Settings, Search Engines tab, what is the "SEO URL Extension" set at?

Examine the contents of the database table CubeCart_seo_urls. Does any entry in the 'path' column end in .html? (There should be only a few, and those few that do should also have '301' in the 'redirect' column.

 

[peterp]

Hi Brian,

The web address is 'http://www.champcoclothing.com.au' and the 404 error is the basic 404 format and as far as I can tell all of the entries have '.html' and there are none with the redirect set to 301

the SEO URL Extension is as below

 

Best Regards,

Peterp

 

[bsmither]

If we are working with CC651, then I suspect that the database was not properly updated. At some version a while ago, the programmers decided that all active values in CubeCart_seo_urls, 'path' column, would not have the .html suffix. That database update from not too many versions ago should have pruned all .html suffixes from this database table. (That update also added a few specific entries that do have the .html suffix but also has a 301 in the 'redirect' column. This part of the update is not critically important.)

You say the legitimate URL for your store is:

http://www.champcoclothing.com.au

that is without including the /champco_champcoclothing/ sub-directory. Then you need to edit the .htaccess file and remove that reference from the various directives:

Change to:

RewriteBase /

Change to:

RewriteCond %{REQUEST_URI} !=/favicon.ico

Change to:

ErrorDocument 404 /index.php

Note: the seo paths the update added to Cubecart_seo_urls are:

contact-us.html
gift-certificates.html
login.html
recover.html
register.html
search.html

for the case where a non-current skin had these links hard-coded in the template.

[peterp]

Hi Brian,

Once again you have helped me immensely and this seems to have done the trick. the site is now working as to what the client wants.

Once again Thankyou

Best Regards,

Peterp