Cannot delete users from within admin

[lhungil]

I've just copied the admin folder across again (saving the configure.php) but it's made no difference. ...

Copied from the local development environment (to a new folder on the server)? Or copied from the Zen Cart distribution zip (to a new folder on the server)?

You have removed from both configure.php files the lines for DB_PREFIX, DB_CHARSET, and DB_DATABASE. These are not sensitive information. Are these the same in both files? Are they correct for the server?

Does the DB_CHARSET match the collation used by the Zen Cart database tables on the server (are the tables using latin1_general_ci if set to latin1 or utf8_general_ci if using utf8)?

... #777 is the customer ID, as displayed in the admin panel. ... Whatever customer I try to delete, the ID is given as 0. ...

So in the database (and in the Zen Cart admin page "/customers.php") the ID assigned to a user is 777. Has this been verified by manually checking the database table "customers"?

What is the cID shown in the URL for deleting user 777 (hover over the delete button)?

In the Zen Cart Admin Activity Log (HTML view, not download), for the rows with "customers.php" what parameters and postdata do you see?

Example 1: "page=1&cID=1&action=update&"

stdClass Object
(
[default_address_id] => 1
[customers_gender] => m
[customers_authorization] => 0
[customers_firstname] => Bill
[customers_lastname] => Smith
[customers_dob] => 01/01/2001
[customers_email_address] => [email protected]
[entry_company] => JustaDemo
[entry_street_address] => 123 Any Avenue
[entry_suburb] =>
[entry_postcode] => 12345
[entry_city] => Here
[entry_state] => California
[entry_country_id] => 223
[customers_telephone] => 12345
[customers_fax] =>
[customers_email_format] => TEXT
[customers_newsletter] => 0
[customers_group_pricing] => 0
[customers_referral] =>
)

Example 2: "page=1&cID=1&action=confirm&"

Example 3: "page=1&action=deleteconfirm&",

stdClass Object
(
[cID] => 2
)

... If you've upgraded, HOW did you upgrade? (official upgrade procedure or an automated script from your hosting company?)

I installed ZC then loaded the old database and ran the update script. ...

Please explain further.

Did you upgrade a copy of the database? Did you attempt to selectively carry over portions of the database before upgrading the database? Did you export / import specific tables before upgrading the database? Did you export / import the entire database upgrading the database? If doing an export / import via phpMyAdmin (or similiar) before upgrading the database, did you disable "partial" export / imports? Did you check the database tables for errors (and / or run repairs) before exporting?

Did you overwrite the existing files with new (or did you start with an empty folder on the server)? Did you determine what changes were present in the old version and manually merge those changes into into the new files? Did you follow the instructions to Rebuild on the New Version?

... What plugins/addons have you installed? When? If your problems are payment-related, what payment module(s) are you using? If it's shipping-related, which shipping module(s) are you using?

No addons or modules. just a very simple template. ...

So there are zero changes, modifications, or overrides present?

... What is the value of "admin" -> "configuration" -> "sessions" -> "session directory"?

Answer please. This value (location of the session write directory) is stored in the database. If you are coping the database from the local installation to the server installation by just exporting the local database and importing to the server database, the value may be incorrect (and need to be updated) on the server. If the site was migrated, this value may also need to be upgraded.

[_Vince]

Copied from the local development environment (to a new folder on the server)? Or copied from the Zen Cart distribution zip (to a new folder on the server)?

Copied from the distribution zip. But since then (this afternoon), I have recopied a lot of the files in case there was some glitch during the FTP transfer.

You have removed from both configure.php files the lines for DB_PREFIX, DB_CHARSET, and DB_DATABASE. These are not sensitive information. Are these the same in both files? Are they correct for the server?

Yes, they are the same, and I think they are correct because the site displays products, clients, etc correctly so it's definitely connecting to the right database and tables.

Does the DB_CHARSET match the collation used by the Zen Cart database tables on the server (are the tables using latin1_general_ci if set to latin1 or utf8_general_ci if using utf8)?

Hadn't thought of that. It was set on the DB to latin1_swedish_ci, so I've changed the configure files to match.

So in the database (and in the Zen Cart admin page "/customers.php") the ID assigned to a user is 777. Has this been verified by manually checking the database table "customers"?

Yes, it has.

What is the cID shown in the URL for deleting user 777 (hover over the delete button)?

777, as expected.

In the Zen Cart Admin Activity Log (HTML view, not download), for the rows with "customers.php" what parameters and postdata do you see?

Well, that's part of the problem. I can't get it to output as HTML, same as I can't get the admin to delete customers or change anything. It's like there's something missing between the user interface and the PHP that actually does things.

Did you upgrade a copy of the database? Did you attempt to selectively carry over portions of the database before upgrading the database? Did you export / import specific tables before upgrading the database? Did you export / import the entire database upgrading the database? If doing an export / import via phpMyAdmin (or similiar) before upgrading the database, did you disable "partial" export / imports? Did you check the database tables for errors (and / or run repairs) before exporting?

What I did was: export a copy of the 1.3x database import it onto the development machine's phpMyAdmin, then run the upgrade. After which, when the ZC was installed on the live server, I imported the upgraded DB.

Did you overwrite the existing files with new (or did you start with an empty folder on the server)?

Empty folder. It's a different server, which is why having old paths mentioned in the .log files is so odd. But I haven't actually seen any new .log files since this morning. Is this normal? Is there a limit to the number of .log files ZC will create?

Did you determine what changes were present in the old version and manually merge those changes into into the new files? Did you follow the instructions to Rebuild on the New Version?

It wasn't really possible. The previous web person wasn't sure of what (if any) changes had been made, the site owner couldn't remember any. Thanks for the link, I will look at that now.

So there are zero changes, modifications, or overrides present?

As far as I can know, no.

Answer please. This value (location of the session write directory) is stored in the database. If you are coping the database from the local installation to the server installation by just exporting the local database and importing to the server database, the value may be incorrect (and need to be updated) on the server. If the site was migrated, this value may also need to be upgraded.

For sure. The record with configuration_key SESSION_WRITE_DIRECTORY has a configuration_value of /var/sentora/hostdata/riobravo/public_html/schofield/cache




I think I will reinstall everything and see what happens. It couldn't be any worse than it is right now.

[_Vince]

In the end, the easiest and quickest thing was just to save the database, reload all of ZC, then import the saved database and template.

It's working now, except for a problem with the email, but that's a different story.

Thank you very much for all your help, people.

[lhungil]

... What I did was: export a copy of the 1.3x database import it onto the development machine's phpMyAdmin, then run the upgrade. After which, when the ZC was installed on the live server, I imported the upgraded DB. ...

This could be problematic. In some case phpMyAdmin can fail to fully export or import the data (depending upon selected settings and server configuration)... Sometimes using mysql_dump and similiar locally is more reliable.

Another potential problem can occur if the test environment does not exactly match the production environment. In Zen Cart 1.5.3+ the password encryption scheme can vary on different versions of PHP (resulting in failed logins / requiring admins and users reset passwords).

So basically, it is usually best practice to always backup the production DB (or copy to a staging DB) first. Then you can test the database upgrade and make any necessary file changes (and document - along with document any plugin installation and extra required steps). After everything looks good, one can then update the files on the production server (and run the database upgrade again against the production copy - and perform any database related changes identified during development on the test server).

The steps outlined in Rebuild on New Version tend to work best, especially when moving from one major version to another (for example from 1.3 to 1.5).

... Empty folder. It's a different server, which is why having old paths mentioned in the .log files is so odd. But I haven't actually seen any new .log files since this morning. Is this normal? Is there a limit to the number of .log files ZC will create? ...

No limit on the number of .log files Zen Cart will create (although some cheap hosting providers may limit the number of files allowed to be stored on a shared server).

If you are no longer receiving new log files related to the path issue, most likely it has been sorted. As we have now checked 90% of the places where the path could come from (and all appear good), I'd not worry about it. Could even have been the hosting provider caching some of the ".php" files (some providers do - and it can take awhile for changes to propagate).

... It wasn't really possible. The previous web person wasn't sure of what (if any) changes had been made, the site owner couldn't remember any. ...

One can always download a "clean" copy of the old version and compare all of the files against the files (from the old version) on the server. Kinda messy without a good comparison / merge tool, but there are some relatively inexpensive (and free) ones out there. While the article on "Troubleshooting Obscure Issues" is not an exact match, the basic process is outlined.

... I think I will reinstall everything and see what happens. It couldn't be any worse than it is right now.

In the end, the easiest and quickest thing was just to save the database, reload all of ZC, then import the saved database and template.

It's working now, except for a problem with the email, but that's a different story. ...

Glad you were able to get things sorted (and thank you for letting us know).

May want to look into converting the database tables to UTF8 after the upgrade, will avoid some potential issues if the store ever needs to support non latin-1 characters (or contains any content with non latin-1 characters). This can range from trivial (for a store previously only using latin-1 characters) to pain in the rear (multilingual stores using non latin-1 characters and multiple different character sets). Here is a related article: Should I Convert From iso-8859-1 to utf8?

Would strongly suggest using SMTPAUTH for your email (unless your provider blocks the necessary ports), much easier to debug and lower chance of emails being flagged as spam.


NOTE: My next step was going to be to ask you to install a "clean" copy of Zen Cart on the server in a new folder and database (with test data) to see if the same problems still occurred, or if there was an issue with something related to the current installation of Zen Cart (files + database). While Zen Cart usually will run on most modern hosting providers without any major issues, once in a blue moon (usually on really cheap providers) the hosting provider's environment is not compatible.