Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.


rogerwhitfield

Recommended Posts

I have recently suffered a server failure, the server is only accessible in recovery mode so I have copied all the files off it onto a new server. Before the server failure the OSCommerce site was working correctly but after the change I am getting the following error messages:-

 

Notice: Undefined variable: data in /var/www/vhosts/nortechcomputers.co.uk/httpdocs/includes/modules/boxes/bm_best_sellers.php on line 64

Notice: Undefined variable: data in /var/www/vhosts/nortechcomputers.co.uk/httpdocs/includes/modules/boxes/bm_categories_accordion.php on line 237


 

 

 

Parse error: syntax error, unexpected end of file in /var/www/vhosts/nortechcomputers.co.uk/httpdocs/includes/header.php on line 111
 
After I transferred the files I made sure that the owner and group were changed, and that the correct file permissions were set, I am using the same .htaccess file as on the previous server.
 
I am running OSCommerce 2.3.3 and php 5.4.1.6, I think the old server was running a similar version. Server is Centos x64 as was the previous server.
 
I have tried setting the file permissions for the two boxes mentioned above to 777 but that has made no difference. The MySQL server was restored from a backup. The backup was two years old but I don't think that this is a database problem. My money was on it being a file permissions or ownership problem but that does not seem to be the case, so I am at a loss as to what has caused a perfectly good website to throw this error!
 
In my mind the only thing that has changed is the server, so surely this is a configuration issue, but I cannot think of anything else to change to resolve these errors, if anyone could give me some pointers it would be very much appreciated.
 
Thanks.
Link to comment
Share on other sites

These are files copied over from the old site, and not a backup restore? The errors sound like your files were corrupted in the crash, especially the header.php problem. An unexpected EOF usually means either the end of the file got chopped off, or a closing ], ), or } was changed to something else (or is missing). Dunno about the missing $data. Any chance of restoring a clean backup, rather than copying files over? How customized is your site -- is it worth getting a fresh copy of osC 2.3.3 and comparing files for differences?

 

PHP 5.4 might be a little advanced for something as old as osC 2.3.3, but that shouldn't cause the errors you're reporting.

 

 

I have tried setting the file permissions for the two boxes mentioned above to 777 but that has made no difference.

 

Never do that. You need to understand the permission system. The only time 777 is appropriate is for a directory (folder) that PHP needs to write to, and PHP is running as world/other ownership. Otherwise, it's a security hazard (anyone can write to your directories).

 

If your store is not tremendously customized, you should be thinking about upgrading to the current version, osC 2.3.4BS. You'll be a lot better off in the long run, plus your store will be responsive and mobile-friendly.

Link to comment
Share on other sites

I have opened the header.php file in dreamweaver and it seems intact, I tried restoring from my local backup but I get exactly the same errors.

 

I changed the file permissions to 777 temporarily just to check to see if it was a permissions error but it made no difference so I changed it back.

 

My site is quite heavily customised so upgrading to a newer version is something that needs to be planned for and at the moment I am just trying to get something back online.

 

The server crash was actually caused by a corruption in the use partition, it didn't really crash it just wouldn't restart, so I am sure that the web files that were in the var partition are all fine.

 

I guess I could always try installing the latest version just to see if I get the same problems. I may give that a go next week.

Link to comment
Share on other sites

...and it seems intact

 

Unfortunately, an eyeball check is meaningless. You have to compare byte-by-byte with a known good copy (such as from a fresh copy of the 2.3.3 distribution), and account for any changes you know that you made.

 

And don't use Dreamweaver for editing code. It wasn't built for that, and can cause all sorts of problems if you slip up. Learn to use a real editor such as ViM or Notepad++, and you won't risk introducing subtle bugs into your code by forgetting to turn off WYSIWYG mode.

 

 

it didn't really crash it just wouldn't restart, so I am sure that the web files that were in the var partition are all fine.

 

Famous last words. How can you be sure that whatever mangled the user partition didn't also damage the var partition? Especially if these share the same physical disk...

 

I take it that you don't have a fairly recent, and known good, backup of your site. Lesson learned.

Link to comment
Share on other sites

I have a recent backup of all the files. I started by copying the files extracted from the old server and ran into this problem so I replaced the files from the backup and got exactly the same issue. The backup was taken 3 days before the server problem and when the server was working correctly.

 

As a test I have installed a fresh copy of 2.3.3 and 2.3.4 and Bootstrap, each of these installations work correctly so I think I will have to give up on resurrecting the old website and instead start making modifications to the Bootstrap version.

 

Its a shame I can't get the old site working as its quite a long job to modify the site the way I want it but I guess that's life.

Link to comment
Share on other sites

Well, I can't imagine how you would get the three errors you listed, especially the unexpected EOF, unless you had corrupted files. A different (not necessarily higher) PHP version on the new server (if it is) shouldn't cause those sorts of errors. Nor should having incorrect file permissions. You say that the backup was three days before the server went casters up? I could guess that the files were already corrupt by that time (or, less likely, the backup process suffered corruption while reading the files, but the disk itself didn't die for a few more days), and you simply didn't notice it over the next days. Any chance it's the disk controller card or on-board electronics that were fried (at first, only conking out on heavy sustained use such as a backup, and eventually on all reads), and the disk platters themselves are OK? Your host may not want to spend the money to deep-diagnose the cause, and possibly replace disk electronics, and simply tossed the whole drive. Unless they were planning to scrap an old server anyway, they should have at least confirmed that it wasn't a bad disk controller card (easily replaceable), and the failure was in the drive itself.

 

It's possible those three files are the only bad ones, but my money would be on other corruption elsewhere. Any older backups? How about your host -- did they have any backups you could get restored? Or is this -- shudder -- a self-hosted system?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...