ZC Main & Admin HANGING and RUNNING SLOWLY -Getting Error Message

[Donn]

Very odd.

*When* did this start happening?
And how does that "when" relate to anything else done to your site? to your site's files? to any addons? to your hosting account? to any emails from your hosting company?

I first noticed this issue around a month or so ago. Maybe a bit longer. It wasn't quite so bad then. Just a slower admin....mostly.....

I hadn't done ANY work on the cart in many, many months at the time the issue started. No add-ons were connected in that time, either.

The last time I had done any work on the site, adding items was fast and the admin modules always loaded without ant error messages.

No setting changes to my hosting account (that I am aware of) have occured in that time.

The only thing of note that i can recall is that the admin log was over 90 days old....and in fact had NEVER been dumped in a whole year of the cart's running.

I do know there were some changes at GoDaddy a few months ago....but it wasn't exactly at that time...I don't *think* it coincided precisely...I think the admin was acting up first....

If you install another clean uncustomized store into another folder and separate database (use demo data for simplicity), do the problems follow? ie: storefront works fine but the admin locks up?
And then test the admin of your live site ... get it to lock up or slow down or whatever, and then immediately (another browser tab?) check to see if your other demo store is at all impacted by the problem triggered on your live site.

Well, Dr. Byte...I finally ended up finishing the installation of 1.3.8 that I downloaded a while back. It was sitting in a directory waiting for...of all things...the database information.

Anyway, the second ZC store works fine. Even when I manage to get the first site to lock up, in the manner described in above messages, the second site (1.3.8) still works perfectly...even the Admin modules.

So GoDaddy seems innocent, in this case.

I suspect you'll not be able to make the demo store have the same problem ... in which case, the fingers are pointed to either your customizations/addons or something damaged in your database.
You can sort out addon problems with the time-consuming process of comparing your site's files against a good backup from when it was working fine.
If you have database damage, I recommend hiring someone who specializes in that area to sort out what you've damaged.

Since I did not activate any new add-ons, is there a possibility that some php file that is accessed often has been corrupted?

Is there a possibility that it was some sort of malicious code placed into my server files, or placed in the database? Or does what I describe not fit these sort of scenarios?

Should I try uploading a backup copy of my site files? If so...just wondering which files I should consider....

or

Should I check out any programs that 'fix' damaged MySQL databases? There are many out there. (I know for Windows, some Registry repair tools DO work QUITE well, so I can imagine that there are some effective utilities out there for MySQL also. I'd rather try something like this first, before hiring someone and paying for their services.

I think not purging the admin log for so long did this!~ That's just my feeling.

What other database is accessed during ALL Admin User actions? (I get that message on ALL Admin pages...and Admin pages ONLY!) And further, which tables AREN"T accessed during normal routine User action on the site? (Non-Admin site use doesn't seem to cause any issues)

Donn

[DrByte]

Since I did not activate any new add-ons, is there a possibility that some php file that is accessed often has been corrupted?

Is there a possibility that it was some sort of malicious code placed into my server files, or placed in the database?

Either of those are certainly possibilities that deserve exploration.

You should compare all the files currently on your server against the backup you have on your PC, assuming you've made backups.

Should I try uploading a backup copy of my site files? If so...just wondering which files I should consider....

NO!
Blindly uploading from a backup is not a good idea.
You should COMPARE your backup against the live files first. Identify all the differences, and make corrections as appropriate.

Should I check out any programs that 'fix' damaged MySQL databases? There are many out there. (I know for Windows, some Registry repair tools DO work QUITE well, so I can imagine that there are some effective utilities out there for MySQL also.

The Windows Registry is an entirely different animal than a MySQL database.

There are things you can try, such as taking a backup of your current database and importing it into your new temporary store's database, and see if your admin problems follow you, etc. If they do, then it points to something with your database content. If they don't, then you've got something damaged in your now-live database, which *might* be fixable by dropping the database and re-importing it from your backup. If you're going to do something like that, make sure you practice it a few times on a test site before killing your live site and having to beg for immediate help or pay for emergency assistance.

I think not purging the admin log for so long did this!~ That's just my feeling.

I'm not convinced that's directly related. While that table's contents are updated on every admin click, it doesn't attempt to read anything from that table. I would expect that a "repair" on that table would have solved it if that was indeed the problem.
You could delete its contents via the appropriate Reset button in Admin->Tools->Store Manager, and see if that solves the problem.
You said you're using v1.3.7, so after you've done that, use phpMyAdmin and run "OPTIMIZE TABLE admin_activity_log;" from the SQL tab, just to reclaim the space it frees up.

[DrByte]

If you compare your /includes/configure.php file against your /admin/includes/configure.php file, what differences do you see? The only differences should be things that relate specifically to your /admin/ folder.
Everything from the DB_USERNAME all the way to the bottom should be identical.

[Donn]

Either of those are certainly possibilities that deserve exploration.

You should compare all the files currently on your server against the backup you have on your PC, assuming you've made backups.
NO!
Blindly uploading from a backup is not a good idea.
You should COMPARE your backup against the live files first. Identify all the differences, and make corrections as appropriate.

OK...I uploaded a site backup from my HD, saved from when the site first went online and worked without issue. I didn't yet do a file-by-file comparison....I just wanted to see if the site, as it was when first installed, now has the same issue.....

Connected to the same database as the live store , I found that the backup store now has the SAME issues in the admin, with the SAME error message. It works sometimes. Just as the live store does. No improvement.

I then changed the database in the new 1.3.8 cart I just set up today, from the demo cart database, to the database associated with my live cart (and now the backup of that cart as well)

I had both versions running in different browser windows. The 1.3.8 cart admin worked LIGHTNING fast, on all functions and page loads.

At the same time, the 1.3.7 cart ran just as poorly as before - sometimes loading a page, sometimes not.

Even when the 1.3.7 version (backup OR original site) couldn't connect to the database, the 1.3.8 version still worked 100%, with the SAME database active.

There are things you can try, such as taking a backup of your current database and importing it into your new temporary store's database, and see if your admin problems follow you, etc. If they do, then it points to something with your database content. If they don't, then you've got something damaged in your now-live database, which *might* be fixable by dropping the database and re-importing it from your backup.

So then, what I reported suggests that the database is somehow damaged....?

I suppose I should backup my backup database, then link the 1.3.8 test site to the backup database, delete the original database, then link the 1.3.7 live site to the database backup, in its new location? Is that what was meant?

If you're going to do something like that, make sure you practice it a few times on a test site before killing your live site and having to beg for immediate help or pay for emergency assistance.

OK....I've backed up EVERYthing at this point.

If you compare your /includes/configure.php file against your /admin/includes/configure.php file, what differences do you see? The only differences should be things that relate specifically to your /admin/ folder.
Everything from the DB_USERNAME all the way to the bottom should be identical.

OK...I checked out the configure.php files, and they are identical, from that point down to the bottom of the text.



What is suggested by the fact that 1.3.8 works great and 1.3.7 seems to not work so well, with the same EXACT database?


Thanks again for the help....I really appreciate it............!

[DrByte]

What addons/contributions have you installed on your 1.3.7 site, and what customizations have been made?
ie: what would have to be done to take a clean untouched 1.3.7 and make it the same as yours?

[Donn]

What addons/contributions have you installed on your 1.3.7 site, and what customizations have been made?
ie: what would have to be done to take a clean untouched 1.3.7 and make it the same as yours?

OK....I also uploaded a clean version of 1.3.7....

That version works 100% in the admin with the database in question, just as the clean 1.3.8 does.

So I suppose that it must be an add-on or customization....

The only add-ons that I found are the updated shipping module released in November, and additional language packs.

Everything else is largely cosmetic HTML changes....

The only real alteration was in displaying clickable medium-sized additional photos (in item view), and that doesn't seem to be anything of significance. The code was procured from members of this board, about a year ago.

I'll try disabling additonal languages next.....

[Donn]

I'll try disabling additonal languages next.....

Looking closer, I notice that the additional languages are active in the clean 1.3.7 install, as well as the clean 1.3.8 install, using the live site's database. I didn't remember that the settings for such are stored in the database....

Both of those carts work perfectly in the admin, with the language packs installed. So can it actually be the additional languages?

Could it be that the additional languages are causing the admin in my modified 1.3.7 cart to hang, even though they don't seem to affect the admin in the clean cart installs of 1.3.7 and 1.3.8?

[Donn]

Looking closer, I notice that the additional languages are active in the clean 1.3.7 install, as well as the clean 1.3.8 install, using the live site's database. I didn't remember that the settings for such are stored in the database....

Both of those carts work perfectly in the admin, with the language packs installed. So can it actually be the additional languages?

Could it be that the additional languages are causing the admin in my modified 1.3.7 cart to hang, even though they don't seem to affect the admin in the clean cart installs of 1.3.7 and 1.3.8?

To answer my own question:

Even though the additional languages are set as ACTIVE in those clean versions, the language data itself is MISSING. So I suppose that the language packs aren't ruled out, then?

[DrByte]

You could try copying the physical files for the language packs to the test site.
In fact, adding everything one by one with testing might be a good approach.

[Donn]

You could try copying the physical files for the language packs to the test site.
In fact, adding everything one by one with testing might be a good approach.

OK....

I copied the physical files from the live (modified) site. I didn't use backups from my HD, just in case file corruption is to blame.

I checked each and every time after adding another language to the test cart, and by the end, with all language modules installed, the test cart (3.7.1) was still running perfectly in the Admin.

What's next?

I suppose I'll try adding the updated shipping module released last November to the test site.

If that doesn't recreate the problem, I'll try copying every PHP file one at a time, from the clean copy to the modified cart, to see if that resolves anything.

Or I could try copying the PHPs from the modified cart into the clean test cart to see if the problem follows.

Could caching be involved in this issue? (I'm just guessing now)