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

Searched forums for 1.5.5a categories.php and 1.5.5a catalog/categories and didn't get any returns...apologies if this is a duplicate.

I upgraded from 1.5.5 to 1.5.5a 3 days ago on Godaddy shared Linux Economy servers.

PHP version 5.4 (that is as high as they are going on Economy hosting). I created a new database as well and have not transferred any CUSTOMIZATION files (except my admin program which updates my 114,000 product catalog).

I can not get admin/catalog/ categories/products (categories.php) to open...the server is timing out. I can get in through the back door of Products Viewed but it is extremely slow and I can not get to the top level.

I also had to rewrite my update program to handle smaller chunks of data because of server time out issues...all was working well in 1.5.0-5 until I installed the 1.5.5a upgrade.

Here are my custom php5.ini settings (the same settings I used in 1.5.0-5 with the exception of adding max_input_vars = 2000 - suggested by Godaddy support)

date.timezone = America/Phoenix
max_input_time = 240
max_input_vars = 2000
max_execution_time = 300
file_uploads = On
post_max_size = 320M
upload_max_filesize = 256M
memory_limit = 384M
session.referer_check =
register_globals=off
magic_quotes_gpc=off

My cache method is set to 'file' and I verified date changes in the cache folder after accessing admin and the catalog.

Gzip is on and verified in php info file.

I tried swapping to the 1.5.4 admin/categories.php file...no joy

Please help...thank you.

Forgot to mention...

I ran a GTmetrix site speed test on the link to admin/categories.php and it said the page loaded in 1.3 seconds (renamed admin folder afterwards:cool:(.

My browsers are a recently updated Chrome on Windows 10 and Edge...neither one works for admin/catalog/categories/products.

Just did a clean install of 1.5.5a on a new database and with sample products...

admin/catalog/categories/products opens fine...but I have 114,000 + products.

Will uninstall my admin script files and recopy the 1.5.5a files to the server and see what happens.

Reinstalled 1.5.5a, removed my admin script files, and admin/categories.php opened on the first attempt (very slowly) then all attempts after that timed out.

I tried clearing the browser cache but it does not help.

I'm out of ideas...anyone?

I'll be back at it Monday...got a wedding to go to.

Thanks for any help.

The first thing that strikes me is the random wildcard of the "admin scripts that load your products". I suspect the data may not be being populated into the database properly, so indexes and relationships are off, thus the performance is hindered.

Thanks...but I'm not sure how to check the "indexes and relationship" you are referring to.

Would resetting the database tables help?

My 1.5.5a catalog is a copy of the products (SKU) and categories / categories_descriptions I was using successfully in 1.5.0 - 5. My custom scripts simply align the data feed with zc database.

I have the same total number (of products) in the meta_tags_description, products, products_description, and products_to_categories, featured, and specials tables.

My categories, categories_description, and meta_tag_categories description numbers are in agreement as well. I don't use attributes...so not of that applies.

I'll do some searching and reading on indexes and relationship and see if I can figure anything out.

In my original post, I indicated I had changed my session folder in my configure files and all was working fine...the dates for the session names were changing every time I accessed admin or the catalog.

However, I noticed this weekend that there is a session folder setting in admin that did not match the configure.php files. I tried changing admin to match my config files but it kept changing back to the default zencart cache folder whenever I would try to change it to a folder above my html (public access). The admin setting now matches the default cache folder in the configure.php files but I would really like to be able to set the cache folder above the public access since that is one of the recommended security measures I have read about in the forums. I'll see if I can manually set that in the db.

Thanks for your help.

More info...

I "checked" my MYSQL tables in phpMyAdmin and all were okay (none needed repair).

I also verified that all master_categories_ids were in products to categories and that there are no products in the top level.

Don't know what else to do?

mikeel100:

I'm not sure how to check the "indexes and relationship" you are referring to.I'm referring to how all the tables relate to each other using keys like products_id so each record knows who its counterparts are. Most people have no idea about the relationships between the tables and think it's basically just a 2-dimensional spreadsheet, but it's much more than that. Perhaps you've already checked the integrity of all those. In that case none of the performance issues you mention make any sense ... or at least point away from ZC or the db as being the problem source.

mikeel100:

Would resetting the database tables help?Only if you've had bad imports and the ids (referred to above) are out of sync.

mikeel100:

In my original post, I indicated I had changed my session folder in my configure files and all was working fine...the dates for the session names were changing every time I accessed admin or the catalog.I'm assuming by "original post" you mean some other completely different post, ie: a different conversation than the one we're having here.

mikeel100:

However, I noticed this weekend that there is a session folder setting in admin that did not match the configure.php files. I tried changing admin to match my config files but it kept changing back to the default zencart cache folder whenever I would try to change it to a folder above my html (public access). The admin setting now matches the default cache folder in the configure.php files but I would really like to be able to set the cache folder above the public access since that is one of the recommended security measures I have read about in the forums. I'll see if I can manually set that in the db.
ZC does auto-reset the foldername in the admin (and database) by reading the DIR_FS_SQL_CACHE setting from your configure.php files and using that value. Provided the folder exists. If you want to move that folder elsewhere, move the folder first, edit its path in both configure.php files, and then your Admin should auto-update as long as it's valid.
But this is a separate discussion that would be better had in the original thread where you started it ... else it's got no value to anyone else and makes it a lot harder to provide continuity in any answers given to you.

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.

...tried the "none" chache method and couldn't access categories.

...tried the "file" cache method and couldn't access categories.

ZC does auto-reset the foldername in the admin (and database) by reading the DIR_FS_SQL_CACHE setting from your configure.php files and using that value. Provided the folder exists. If you want to move that folder elsewhere, move the folder first, edit its path in both configure.php files, and then your Admin should auto-update as long as it's valid.
But this is a separate discussion that would be better had in the original thread where you started it ... else it's got no value to anyone else and makes it a lot harder to provide continuity in any answers given to you.

Sorry, but Zencart is not auto-resetting the database by reading the DIR_FS_SQL_CACHE from the configure file. I've tried numerous times (in the correct order) and the only way to change the database to match the configure file is to use phpmyadmin and manually change it.

If you will read my original post, you will see that the new cache folders were created before I changed the configure.php DIR_FS_SQL_CACHE (because I verified that the dates were changing on the session file names).
Which, BTW, makes no sense because I had not yet changed my admin/session file directory to match the configure.php file settings.

What I said in the very first post in this thread:

My cache method is set to 'file' and I verified date changes in the cache folder after accessing admin and the catalog.

Not trying to argue with you or be difficult...I just want my store back in the efficient working order it was in in 1.5.4.

The reason I piggy-backed off of the thread you moved this from is because I suspected my problem had to do with 1.5.5 to 1.5.5a transition.

Are you going to move this back to the original thread I had it posted in?

Thanks again for your help.

If you want to move that folder elsewhere, move the folder first, edit its path in both configure.php files, and then your Admin should auto-update as long as it's valid.

Do you mean...move the default cache folder supplied with zencart? I see it has a .gitignore and .htaccess file within it.

I have been trying to use a zc_cache folder above my html directory without these files in them.

mikeel100:

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?

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?

DrByte:

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.

mikeel100:

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.

mikeel100:

• 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.

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.

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.

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.

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

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

mikeel100:

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.

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!

mikeel100:

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.