Curious ZenCart Database Problem

[BlackPanther]

I'm encountering some odd behavior and warnings about updatable components with a client's ZenCart 1.5.5e at http://noontidepress.com

Site uses PHP 5.3.29, MySQL 5.5.51

The most perplexing issue is when I login with what I believe to be the site's admin credentials, the latest order I see is November 17th, 2017. The client assures me that there are numerous orders submitted since then. Server was bounced for some reason, perhaps by hosting service hostgator almost a month ago, so I suspected that perhaps the database records got corrupted/deleted by the outage, or maybe were in cache and not committed to database when outage occurred.

I submitted a test order, received email confirmations, but still don't see the order in ZenCart admin console.

However, when I used PHPmySQL I noticed there appear to be multiple ZenCart databases and I was able to find my test order in one of them. This raises the question as to whether there are multiple ZenCart site instances running (likely a bad idea) and if so, whether I'm inadvertently connecting to the wrong one.

Is there a way from the ZenCart admin to determine the name of the MySQL database being used and its location in the file system?

Conversely, if I used PHPmySQL to revisit the database where I found my test order, is there a ZenCart database table that would contain the URLs of public ZenCart and the private ZenCart admin console?

I need a way to determine and test if I'm accessing the proper instance of ZenCart.

[mc12345678]

Really here and possible is that you are accessing a different admin directory than the store is using. By design the database doesn't contain a path to the admin directory and the catalog doesn't contain one either. (think security)

Ideally should work with the store owner to identify the correct path seeing as it appears you don't have ftp access to the files to be able to identify the correct admin path in which the database to be used when accessing that admin directory. Mind you the database reference is not just the database itself but also the set of tables associated by use of the DB_PREFIX.

[BlackPanther]

Good morning and thanks for the quick reply.

Given I DO have cPANEL access to the hostgator hosting of the ZenCart site. What files would I need to look at to determine which sites are connected to which databases?

Unfortunately, the credentials I have are those provided by client so there's no guarantee they're accurate as client has no clue who installed their ZenCart site or when.
If issue really is I'm connecting to a different instance than public is seeing then problem should be relatively easy to fix, assuming I can identify correct database instance, point to it as admin, and possess (or obtain) the right credentials. Worst case, I could reset admin PW via PHPmySQL, but only if I know which database I'm actually connecting to.

If issue isn't multiple ZenCart instances, then inability of Admin or Order Admins to see entries successfully submitted by customers that have made it into the database is probably a more serious problem, for which there may be no obvious solution.

[mc12345678]

Good morning and thanks for the quick reply.

Given I DO have cPANEL access to the hostgator hosting of the ZenCart site. What files would I need to look at to determine which sites are connected to which databases?

Unfortunately, the credentials I have are those provided by client so there's no guarantee they're accurate as client has no clue who installed their ZenCart site or when.
If issue really is I'm connecting to a different instance than public is seeing then problem should be relatively easy to fix, assuming I can identify correct database instance, point to it as admin, and possess (or obtain) the right credentials. Worst case, I could reset admin PW via PHPmySQL, but only if I know which database I'm actually connecting to.

If issue isn't multiple ZenCart instances, then inability of Admin or Order Admins to see entries successfully submitted by customers that have made it into the database is probably a more serious problem, for which there may be no obvious solution.

Realize the title of the thread relates to a curious database issue; however, sounds like a curious store operation issue because of the following:
URL information and credentials have supposedly been provided by store owner that vouches that there have been sales occurring since the last date documented in A database that is connected to an admin directory.
Database review in phpMyAdmin shows multiple databases and in some cases multiple stores within a given database.


Again it is possible for multiple admin directories to exist off of a single store and each admin directory could reference a different database (as well as store to be honest) and/or a different dataset within a database.

If there are multiple stores within the file structure of available directories then here's how I would approach the matter with having so much access to the overall site.

Identify the file path that is to be reached by internet users when entering the URI in the browser.
Then within that path begin an inspection of an .htaccess (if it exists) to see if there is some sort of redirect to another location on the server or not. Ideally no redirect.
Then to identify the database information associated with that install, go into includes/configure.php and review the section that contains defines beginning with DB_. This information is the database that the catalog is using which identifies the database itself and the prefix that is to be used when accessing the tables.

Then at the path of the store, navigate to/through directories immediately off of the store and not typically a part of a default install (ie. not includes, images, extras, etc...) to identify the admin directory(ies) that have been made available in this installation. (ie. the path you use to login to your version of the admin is the path you see.)

Then within each of those paths see if there is an includes directory and within each such includes directory there should again be a configure.php file. That file also has DB_ credentials. In your current case, the credentials are likely different in one or more ways than the catalog side. I do not recommend yet changing these credentials as for one the files being used to access the database may not be up-to-date with the current database version and could (PSA warning) cause issues if the database is accessed with them.

Once all such admin directories have been identified, if there is only one, then well the next step is easier, but should be done regardless. Would then suggest to review the admin files for version related information, though the header of a file tends to be a good indicator, it may not have been updated in previous updates or may still exist at a lower version just because it hasn't required a change since that identified version. This is almost where a file comparison utility would come in most handy because it should be relatively obvious if the file is the same or a different version from the ZC default...

Anyways, once the "right" admin directory is found or rebuilt, then the database credentials associated with the catalog side should be the same as what is used/entered in the admin and from that point on should be able to access the store data from that admin directory.

[carlwhat]

holy moly....

if you successfully place an order, and don't see it on the admin side, your admin is accessing a different database.

from your base ZC directory, there are 2 files to consider:

/includes/configure.php
/YOUR_ADMIN/includes/configure.php

in both of those files, check that the following constants are the same:

define('DB_PREFIX', '');
define('DB_SERVER', 'localhost');  // address of your db server
define('DB_SERVER_USERNAME', 'username');
define('DB_SERVER_PASSWORD', 'password');
define('DB_DATABASE', 'zc_data'); 

i have a feeling, either the DB_DATABASE is different (most likely) or the DB_SERVER. possibly, the DB_PREFIX as well....

while mc's very thorough response is probably accurate, start here. it really could be that simple.

good luck.