Site crash/hack?, lost a live database connection, before potential upgrading

Ok had a perfectly operating cart although on 1.3.8a
My shop cart somehow became unuseable, corrupted by a date issue at the time, maybe by the server, or a hacker.
I saw this date error line once, so no idea what its said now.
It never came back again to copy it and I could not get back into the site, having an almost blank page.

So I created a 'site down' index page & moved the whole cart files of the site to a different location folder to test out, but have had no success at all, only now keeps saying;
0 DB_ERROR_NOT_CONNECTED
in:
[select * from zen_project_version WHERE project_version_key = 'Zen-Cart Database' ]

Both the configure.php files show the correct database name, password & admin directory, in its new location using the original database I cannot afford to lose, not so much the customers but the stock inventory data, I assume it keeps all but the actual images. It checks out fine in MySQL.

In desperation I thought to create a new database name in mysql, imported the saved sql backup so I intend to use that to use on the upgrade to 1.5 if this repair cannot be resolved today. Noted that the new database is 0.4MB smaller after copying?

My preference is to work out how to keep my 1.3.9 version running for a bit longer with its many previously stable tweaks, customisations & templates that are not yet ready to work with 1.5 as a new install but using the original live database.

Have read many similar threads on database access errors but Im going round in circles :wacko: just being told to look at the two configure files, and the mysql/myphp database names/passwords, not that anything but the sub-directory name has been changed since the crash.
I will be using a new admin subdirectory just in case the site had unauthorised access that killed that version that might stop an upgrade from 1.3.8a to 1.5

phpMyAdmin Server version: 5.1.56
PHP version: 5.3.8
Operating system: linux (server)

Clarification: you said

My preference is to work out how to keep my 1.3.9 version ...

but you meant 1.3.8, right? The cart is broken and it's at 1.3.8?

You show a PHP version of 5.3. If you haven't applied the 5.3 patches, you'll have problems. But rather than do this, why not install a stock 1.3.9 cart in a new folder, copy over your configure.php files, go through the db upgrade using zc_install, and see if this works. Then you'll have to port your customizations but at least you'll be back in business.

Ha great thoughts Scott, but first my mistake yes I was happily running 1.3.8, never had any issues and regret not having the time to sit and get down to upgrading with fixes into 1.3.9.
The more 1.5 was coming along that was my intention to jump, so I agree from your point upgrade to 1.3.9 is best that hopefully would keep all my tinkering and the database. I could play with 1.5 at a more leisurly pace I suppose.

If not broke you dont fix, but I should have kept an eye on the php patches although PHP & SQL are my weak points.
Many thanks, may try that today. I never added you Better Together but that with Royal Mail and Image Handler I liked.

Proceeded with the installion of the 1.3.9 install, doing fine at the start, saw the install page, sorted out the first issue permissions on one file, then came up with this after a trying to copy over the .htaccess file from the previous installation about global something. I find these htaccess files awkward to deal with not liking filenames when editing/copying.

500 Internal Server Error

[Sun Feb 19] [error] [client 81.101.202.] File does not exist: /home//public_html/500.shtml
[Sun Feb 19 ] [alert] [client 81.101.202.] /home/***/public_html/store/.htaccess: Invalid command '\xef\xbb\xbfRewriteEngine', perhaps misspelled or defined by a module not included in the server configuration

So back to being a little frustrated...
When its solved I will post the issue, unless someone else points us to the simple cause.

Use the stock .htaccess and turn off URL rewriting.

swguy:

Use the stock .htaccess and turn off URL rewriting.

Many thankjs again Scott for assistence, my Update...

To get back to where I was, from your suggestion to upgrade to 1.3.9 first then later work towards 1.5.0 (might mean the thread gets moved).

I took out the htaccess file that was originally suggested in the Global requirements to turn that off.
Then I deleted the htaccess file in the new admin folder and then made sure it was saved from notepad under UTF-8 format.
I then got happily back to a my original view of my public front page and the zc_install folder...

The install came back to the error that caused that run of 500 Server errors; Register Globals = ON Click here for more info
I have ignored that for now. My server/host dealt with that last time in the htaccess file.

Next highlight was;
PHP Output Buffering (gzip) = OFF

All seemed fine until...
Click here to open the Admin area
Disappointingly it was back to 500 internal Server error!

Keep an eye on the cache directory, which contains error logs (but not for this situation, which is likely a permissions issue with your admin directory - be sure things are set to 755 or 644).

Im getting the 500 error still, but now sure which file to look at, its the htaccess file in the admin folder, as I see the word I added admin after the # at the start of the text.

.htaccess: Invalid command '\xef\xbb\xbf**#admin**', perhaps misspelled or defined by a module not included in the server configuration

This looks like gibberish bits in front of the file I saved again by UTF-8 in notepad then used filezilla in ftp to the site.

Those files in the cache directory are 644 or just one has 600
In my ftp filezilla I see another htaccess file there but in my cpanel file manager I dont ?

Cache log said:
Failed opening required 'includes/languages/custom/english.php
But it was there. Making me get a bit tired of it all now.

Still not found the issue to solve but this lot of detail digging a round in the cache log;

PHP Fatal error: require() [<a href='function.require'>function.require</a>]: Failed opening required 'includes/languages/custom/english.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/****/public_html/store/admin/includes/init_includes/init_languages.php on line 35

While line 35;
require(DIR_WS_LANGUAGES . $_SESSION['language'] . '.php');

words specific to my site removed and 'admin' had been renamed too.

Using the htaccess file in the install it gives a 500 Error, while renaming it to not be used gives a total blank page on the admin side, while both ways give a working shop, with 'down for maintenance' script BUT I have mananged to buy, with it sending a 'success' email out, hence why the store is not running somewhere public.

What am I missing or looking for :frusty:...

Dinnages:

PHP Fatal error: require(): Failed opening required 'includes/languages/custom/english.php' ... in .../admin/ ...
The error message is telling you that an important file is missing, and is causing a fatal error.
ie: your /includes/languages/custom/english.php file is apparently missing

DrByte:

The error message is telling you that an important file is missing, and is causing a fatal error.
ie: your /includes/languages/custom/english.php file is apparently missing

Many thanks for that comment, its pretty obvious issue so had looked before posting, both files are there, as in my template format used for 138.
Maybe later today I will compare with a standard 139 version.

public side = /public_html/store***/includes/languages/custom/english.php
admin side = /public_html/store***/admin/includes/languages/english.php

Neither seem to be missing anything, but will compare with winmerge, standard versions. public side must be fine because those pages works fine, just admin, no access.

You took out all the path information from your post. Perhaps the problem is that your admin configure.php file has a DIR_FS_CATALOG setting that's pointing to the wrong folder, so it can't find the files it's expecting to see when the admin attempts to access your non-admin language file.

DrByte:

You took out all the path information from your post. Perhaps the problem is that your admin configure.php file has a DIR_FS_CATALOG setting that's pointing to the wrong folder, so it can't find the files it's expecting to see when the admin attempts to access your non-admin language file.

Great advice much appreciated by Scott 'swguy' and DrByte as in previous issues a way back.
:clap:

Going by the mention above, there seemed to be just an extra space/line in the listing of that admin configure.php file, which then gave me this;

PHP Fatal error: require() [<a href='function.require'>function.require</a>]: Failed opening required 'includes/languages/custom/english.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/****/public_html/store/admin/includes/init_includes/init_languages.php on line 35

Then looking at the directories the admin side overide 'custom' folder was now missing? I had done the FTP across and cannot see how its either missed it or maybe lost it in the transfer, timeout maybe?

So at last guys with your help, which all people need at times, is pointers where to look, as it is quite daunting wading through php files not knowing quite how they work. To all those who get frustrated, cool off, come back again refreshed, and its worth perseverring instead of giving up on a great cart, wether for hobbies or big business.

Anyway have now logged in and have one tiny thing left I think, so I should be able to find whats missing there on my own.
(TEXT_CURRENT_VER_IS v1.3.9h)
/includes/languages/english/extra_definitions/onlyFor139.php

However the onlyFor139.php file shows;
define('TEXT_CURRENT_VER_IS', 'You are presently using: ')
In Winmerge stated "files using different carriage return types"

Certainly worth a donation to those who help me, and credits where due. Again many thanks.

If you're upgrading to 1.5.0, then the onlyFor139.php file's contents were merged into the main language files. So, your problem suggests that you've not merged the changes for the various admin language files.
Or you've got admin and non-admin language files mixed up, or admin vs non-admin init_includes files mixed up

DrByte:

If you're upgrading to 1.5.0, then the onlyFor139.php file's contents were merged into the main language files. So, your problem suggests that you've not merged the changes for the various admin language files.
Or you've got admin and non-admin language files mixed up, or admin vs non-admin init_includes files mixed up

Really appreciate the thoughts and advice.
I was frustrated at what killed the 1.3.8a site and my warning to others, despite the time it takes, its worth upgrading more often!
I left it too long, so thought I would jump from 1.3.8a to 1.5 but instead have by Scotts suggestion gone from 1.3.8a to 1.3.9h in order to get the site up and running again first so I can sell again, then more calmly study the differences in upgrading to 1.5 where I would like to keep my colour and customisation themes.

Thanks.