Can't open admin/categories.php - times out

[DrByte]

I just changed the configure.php files cache method to "database" and was able to access admin/catalog/categories/products...3 times in a row. However, it still takes over 2 minutes to show the categories/folders. I have 1841 categories/subcategories.

1. The admin display of categories/products doesn't utilize any cached queries beyond what MySQL caches on its own.

2. The code which handles categories/products in the admin, or even non-admin for that matter, had no significant changes between v154-v155 ... basically the only change was when displaying a product to dynamically look up image subdirectory names using a shared function instead of duplicating the code across every product-type ... and even that should have no bearing on your situation.

3. Common causes of the admin category/product listing to be slow include:
- broken master_categories_id values set on product records (ie: out of sync; see previous discussion above)
- dropped indexes on MySQL tables ... which usually only happens when doing imports where the export didn't include indexes, which is rare, but shouldn't be overlooked. The default indexes supplied on all the tables should suffice provided one hasn't altered the ZC core code via plugins or customizations
- damaged tables -- you already said you ran a repair

4. You haven't listed all the ways in which your site's code differs from original ZC v1.5.5a distribution code. What customizations or plugins have altered things?

[mikeel100]

I guess I got lucky last night with accessing categories / products...can't get into it today.

Maybe it is time to leave Godaddy...got any recommendations for certified Zencart hosting?

4. You haven't listed all the ways in which your site's code differs from original ZC v1.5.5a distribution code. What customizations or plugins have altered things?

The following info seem irrelevant since I have already removed my scripts / tables to see if it had any affect on the issue at hand...but I have provided it to see if it gives you (or me) any insight into what may be happening:).

Here is what I have done:

- Added the UPS module, PayPal Express, and my scripts for updating my catalog (which are working fine).

- My scripts include a form page which is accessed from the tools menu and it operates off of a separate PDO connection...using the values from the configure.php file.

- Turned off global left and right columns in admin and applied all of the speed up recommendations from the forums.

Table changes:

I added 5 of my own tables and added 36 values to the configure table for processing updates.

Additionally, I added zip_code and consumable fields and indexes for zip_code, consumables, and image name to the products table. I also changed the products_image field from 64 to 254 in the products table and the products name from 64 to 254 in products_description.

In a nutshell, here is how my scripts work.

In the database of the cart I am upgrading from:

- products, products_to_categories, categories, and categories_descriptions are exported to a tab delimited text file.

- As I understand, these are the minimum tables required to maintain product alignment with the category structure.

- No indexes are involved in the transfer of basic product/category match-up data...I assumed that phpMyAdmin / MYSQL will rebuild the indexes off of the information I provided to it...have I assumed incorrectly?:)

In the database of the cart I am upgrading to:

- I am importing the tab delimited files created above.

- My updating scripts compare the supplier datafeed against the information I just imported into the tables using the products_model (acturally the SKU) and master_categories_ids as keys for comparison, inserting, and updating the tables.

- My align tables script keeps the products table aligned with featured, products_to_categories, meta_tags_products_description, meta_tags_categories_description, products_description, and specials tables.

Next?

I'm going to try to install just the categories / categories_descriptions into a fresh install of 1.5.5a without any plug-ins or table changes. If I can access admin/catalog/categories/products, I'll know it has something to do with how the products and products_to_categories tables are relating to the categories tables. I'll add a category at a time until I hit a snag, and that should further narrow down where the problem lays.

Give me a day or two to play around with it and I'll post the results back here.

Thanks again.

[DrByte]

Maybe it is time to leave Godaddy...got any recommendations for certified Zencart hosting?

Eek. Any day that ends in "y" is a good day to leave GoDaddy.
See the "Services" link at the top of this page for other hosts. I recommend the geeky one, but that's mainly cuz I haven't used the others.

- products, products_to_categories, categories, and categories_descriptions are exported to a tab delimited text file.
- As I understand, these are the minimum tables required to maintain product alignment with the category structure.

products_description should be on that list; judging from the rest of your post I assume that's just a typo.

[mikeel100]

products_description should be on that list; judging from the rest of your post I assume that's just a typo.

Not a typo...products description is covered with my alignment script. Actually, the bear minimums I need for transferring the shop is the products_model(SKU) and master_categories_id from the products table...everything from the categories and categories_description tables. My scripts will align all of the other relevant tables with the products table.

Let the troubleshooting begin...LOL.

Thanks again for your help.

[mc12345678]

Umm if I may offer, seeing that almost everything is being populated with this script and perhaps a few things related to the inner workings of ZC have been modified that possibly various queries within the flowpath are being cached and therefore not resolving in the desired condition

Ie: $db->Execute($sql); may need to become:
$db->Execute($sql, false, false, 0, true); in order for the database information to properly post.

[mikeel100]

Thanks mc12345678,

Are referring to my scripts or ZC?

My scripts are built with php/mysql/PDO...not dependent on the native ZC programming. The only thing in common between the two are the basic database connection information and the actual name of the connection ($db). Once my form loads in admin, $db is nullified and my PDO connection and scripts takes over. I have dumped cache and log files until I'm sick of it.

Speaking of log files, no errors are being generated in the ZC log folder after a failed attempt to access categories/products...I just get a screen that says the website can't be reached after about 3 minutes.

My scripts are executing and updating my products as intended...the only problem I am having is time-out issues accessing admin/catalog/categories/products. I can access it when the server loads are really down at 2 a.m. and randomly throughout the day.

I have 114,000 + products in 1841 categories/subcategories. Everything was working great in ZC 1.5.1 - 5 until I did a restore on my database with a bad backup file from Godaddy. Since things were so screwed up, I upgraded to 1.5.5a and completely rebuilt my catalog with a new database...but the slowness remains...even after doing all of the speed optimizations recommended in the forums.

I talked to Godaddy today and they agreed that I need to try a different host to see if it helps.

Godaddy service has been declining for about 4 months and I believe it is time to move on.

I appreciate your input.

[mikeel100]

$db->Execute($sql, false, false, 0, true)

What are the additional options ... false, false, 0, true?

[DrByte]

What are the additional options ... false, false, 0, true?

From the code:

  function Execute($zf_sql, $zf_limit = false, $zf_cache = false, $zf_cachetime=0, $remove_from_queryCache = false) {

$zf_sql = the query
$zf_limit = how many entries to limit the results to; false for unlimited
$zf_cache = whether to cache the results using the ZC caching
$zf_cachetime = how many seconds to keep the cache for
$remove_from_queryCache = whether to reset the cache for this query

Note: as with all caching systems, the cache is only done on identical incoming query strings. In this case $zf_sql gets hashed and that hash becomes the cache index. If a single character is different on the incoming SQL statement then it won't find an old cached value to re-use.

I suspect 99% likelihood that none of this is relevant in your case. But passing that final 'true' for $remove_from_queryCache might be worth exploring within your "custom scripts" that you're using to inject your data.

None of this is new to v155. It's been around for a long time.

[mikeel100]

The problem was GoDaddy Economy shared hosting.

I rebuit my store with Inmotion Pro and all seems to be working extremely well now (after I figured out how to do a PDO db connection with PHP 5.6.).

I'm with the Dr. now...any day of the week ending in Y is a good day to leave GoDaddy. They were pretty good for a few years but now there servers are outdated and sluggish at best. Customer service is lacking as well.

Thanks for your help and insight!

[DrByte]

The problem was GoDaddy Economy shared hosting.

Occasionally asking them to move you to a different (newer) server on the same pricing plan may buy some time before switching, particularly if you've prepaid for a long period of time.
Their reliability goes in spells. One year it's good, the next year or two are bad, then improves for awhile, then dives again. And their customer-service reps are paid on closing calls and upselling, so the quality suffers until you weed thru the lower echelons to get to the 3rd-level techs who actually know what they're doing.