MySQL error in /engine/classes/mysql.php: how to find and fix the real cause

What does “MySQL error in /engine/classes/mysql.php” actually mean?

The path /engine/classes/mysql.php tells you where DataLife Engine detected or reported a failed database operation. It does not prove that the PHP file itself contains the defect. Connection failures, authentication errors, missing databases, missing tables, invalid columns, rejected SQL queries, and lost connections can all surface through the same database layer.

The scope of the failure immediately narrows the search. If the home page, articles, categories, and admin panel all fail at once, connectivity, credentials, database selection, and the MySQL or MariaDB service deserve attention first. If the site mostly works but one module or admin action fails, the connection is already up. Follow the query.

Intermittent behavior points elsewhere again. A permanently wrong password does not normally become correct after a browser refresh. If the site disappears for a few requests and then comes back, inspect connection limits, service restarts, resource pressure, timeouts, or the network path.

Save the complete DLE error before changing the environment. Keep the numeric error number too if DLE displays one: it can help confirm the MySQL error class, but use it together with the returned text rather than treating the number as a standalone diagnosis.

Which part of the DLE MySQL error should you read first?

Read the error block as evidence, not as one long message. The Error returned was usually tells you what MySQL rejected. SQL query shows what DataLife Engine was trying to execute. The PHP file and line tell you where DLE reported the failure. Those fields do not have equal diagnostic value.

Start with “The Error returned was”

Consider three messages:

Access denied for user 'siteuser'@'localhost'

Table 'site_db.dle_example' doesn't exist

MySQL server has gone away

The first belongs to authentication. The second means MySQL got far enough to resolve a database and table reference. The third means an established connection stopped being usable. Searching only for mysql.php line 52 throws away that distinction.

If an error number is also displayed, keep it with the text when searching documentation or sending a ticket. Do not build a catalogue of numbers in your head; the human-readable message is normally the faster routing clue.

Use “SQL query” to separate connection problems from query problems

A concrete query changes the investigation. Suppose DLE shows:

SQL query:
SELECT id, title FROM dle_news WHERE ...

If MySQL rejects that statement because a table or column is missing, stop changing passwords. Authentication has already progressed far enough for DLE to submit SQL. Now look at the schema, table prefix, update state, module, or query itself.

If no query is shown and DLE fails immediately on every request, connection, authentication, or database selection moves higher on the list. An empty query is not absolute proof because error formatting can vary between releases, but it is useful context.

Treat line 52, 53, or 61 as version-specific context

A line number can move after a DLE update, a local patch, or even a small change above the error handler. Two installations can therefore report the same underlying MySQL error at different lines, while two different errors can appear at the same line in different situations.

How do you fix Access denied, Unknown database, or an invalid MySQL host?

A DLE site that stops immediately after a migration, restore, database password change, or hosting-account move often has a configuration mismatch. Test the four connection values first: database host, database name, database user, and database password.

Locate those settings using the documentation or configuration layout for your exact DLE release. Do not copy a configuration-file path from an unrelated version and assume it must be the same on your installation.

Access denied for user

Access denied for user means the server was reached, but MySQL rejected the account. The password is only one part of the match. MySQL accounts are associated with a user and host, so the host shown after @ matters.

Compare these two examples:

Access denied for user 'siteuser'@'localhost' (using password: YES)

Access denied for user 'siteuser'@'192.0.2.10' (using password: YES)

In the first case MySQL sees a local connection. In the second it sees the account arriving from another host. A user permitted as 'siteuser'@'localhost' does not automatically match every remote source. That small part of the message often explains why credentials work on one server and fail immediately after a migration.

Stop changing passwords and test the login directly:

mysql -h DB_HOST -u DB_USER -p DB_NAME

Enter the password interactively. If the same command fails with Access denied, DLE is not the place to fix it. Correct the password, account-host match, or privileges first.

After a successful login, inspect the current account grants:

SHOW GRANTS;

On shared hosting, the equivalent check may be the database-user assignment screen in the control panel rather than SQL. The account should have the permissions required by DLE on its application database, not unrestricted privileges across the whole server.

What if the MySQL CLI login works but DLE still fails?

A successful CLI login rules out several things, but not everything. It proves that the credentials you just typed can reach that database using that connection method. DLE may still be using another configuration file, another database host, another username, or another transport.

A typical migration can look deceptively correct: the dump is visible in phpMyAdmin and the manual login succeeds, but DLE still points to the old database host. The database is healthy; the application is simply connecting somewhere else.

Unknown database

Unknown database means MySQL was reached but could not select the configured database. After a migration this often means the new account uses another database name, the SQL dump was imported under a different name, or only the site files were restored.

With sufficient permissions:

SHOW DATABASES;

MySQL only lists databases visible to the current account, so absence from this output can mean either that the database does not exist or that the account cannot see it. On shared hosting, compare the database shown in the control panel or phpMyAdmin with the name configured in DLE.

If you can connect while explicitly naming the database:

mysql -h DB_HOST -u DB_USER -p DB_NAME

then the database exists and is accessible to that account. If DLE still says Unknown database, compare the application's configured name character for character.

Unknown MySQL server host

Unknown MySQL server host points to the hostname, not the password. Common causes include a typo, a database hostname from the previous provider, a private internal hostname that no longer exists from the new server, or DNS resolution failure.

On Linux, test name resolution without involving DLE:

getent hosts DB_HOST

If the command returns no address, fix the hostname or DNS path before troubleshooting SQL. If it resolves correctly, continue with the TCP test and MySQL login.

localhost is not interchangeable with a provider-specific remote database hostname. Shared hosting may require an internal DB endpoint, while a VPS may run MariaDB locally. Use the host assigned to the actual environment.

When the configuration is corrected, verify three things in order: manual login works, SELECT DATABASE(); returns the intended database, and both the DLE frontend and admin panel load normally.

How do you diagnose “Can't connect” and “No such file or directory”?

Correct-looking credentials are not enough if the database service cannot be reached. At this point shared hosting and VPS diagnostics split: a shared-hosting user may only have a panel and phpMyAdmin, while a VPS administrator can inspect the service, socket, port, filesystem, and logs.

Is MySQL or MariaDB actually running?

On a VPS, identify the actual service name first. Depending on the distribution and installation, it may be mysql, mysqld, or mariadb. Use the one that exists on the server:

systemctl status mariadb

or:

systemctl status mysql

Look for active (running), failed, repeated restarts, and the timestamp of the last state change. A quick response check is:

mysqladmin ping

If the command cannot connect because it follows the same broken local socket, try the actual configured host or an explicit TCP test instead. The goal is to answer one question: is a MySQL-compatible server reachable through the path DLE is supposed to use?

If the service failed, inspect its journal with the correct unit name:

journalctl -u mariadb

When the database process is down, DLE is no longer the first suspect. A PHP-file change cannot repair a failed MariaDB startup, an exhausted filesystem, or a server crash.

Why can “No such file or directory” be a MySQL connection error?

On Linux, No such file or directory can refer to the Unix socket used for a local MySQL connection. The missing path may be something like /run/mysqld/mysqld.sock or /var/lib/mysql/mysql.sock, depending on the distribution and installation. Those are examples, not universal paths.

There are two different failure patterns worth separating.

• The database service is not running. The socket is absent because no process created it.
• The database service is running, but PHP or the MySQL client expects another socket path. The server has a socket, just not where the client is looking.

If TCP access works, ask the running server which socket it uses:

mysql --protocol=TCP -h 127.0.0.1 -u DB_USER -p -e "SHOW VARIABLES LIKE 'socket';"

You can also inspect client or server configuration for socket directives. On systems that keep MySQL configuration under the usual locations, a targeted check may look like:

grep -R "^[[:space:]]*socket" /etc/my.cnf /etc/mysql 2>/dev/null

Compare the paths rather than guessing a replacement. If the server reports one socket while PHP or the client expects another, correct the configuration that is wrong.

Local connections using localhost may use a Unix socket, whereas 127.0.0.1 normally forces TCP. Switching between them can therefore be a diagnostic test, but not a universal fix. MySQL account matching can also change between local and TCP connections.

What changes when MySQL is on another server?

A remote database adds DNS, TCP reachability, firewall rules, the MySQL listening address, and remote-account permissions. A correct password does nothing if the application cannot reach the port.

From a VPS:

nc -vz DB_HOST 3306

A successful TCP connection proves that something is listening on that address and port. It does not prove that the MySQL account is allowed to log in. Follow it with the same manual MySQL login that DLE is expected to perform.

Why does DLE connect to MySQL but fail on a table, column, or SQL query?

If DataLife Engine can open some pages but a particular module, admin action, or URL displays a MySQL error with a concrete SQL statement, credentials are no longer the main suspect. The connection is already up. The table name, column, query text, and action that triggered the error now carry more information.

Table doesn't exist

Table ... doesn't exist often follows an incomplete SQL import, a wrong prefix, a partial DLE upgrade, restoration of the wrong backup, or installation of a module whose database migration never ran.

Confirm the active database:

SELECT DATABASE();

Then inspect its tables:

SHOW TABLES;

If you know the expected prefix:

SHOW TABLES LIKE 'prefix_%';

If the expected table exists under another prefix, the application may be querying the wrong naming scheme. If it does not exist at all, find out which installer, migration, or backup should have created it. Creating an improvised table just to silence the error can leave DLE with the wrong columns, indexes, or defaults.

Unknown column

Unknown column usually means application code and schema disagree. One common pattern is newer DLE or module files working against an older database dump. Another is an update that copied PHP files successfully but failed before its schema changes completed.

Inspect the real table instead of guessing:

DESCRIBE table_name;

For the full definition:

SHOW CREATE TABLE table_name;

Now compare the actual column type, defaults, indexes, and table definition with the expected schema for the installed DLE release or module. Do not add the missing column manually unless you know what the official migration intended to create.

SQL syntax error

If DLE displays You have an error in your SQL syntax, capture the entire query and reproduce the exact action that generated it. A custom modification, old plugin, incomplete module update, or query that relied on older database behavior can all end at the same MySQL error.

For a recently changed module, reproduce the failure on staging if possible and compare behavior with that module enabled and disabled. Developers can also trace the displayed table names and query fragments back to the responsible code. The important part is to tie the SQL to an action rather than treating it as an anonymous database problem.

Read-only SELECT statements can often be examined safely in a test database or phpMyAdmin. Treat write operations differently. Do not execute unfamiliar DELETE, UPDATE, ALTER, or DROP statements on production just to reproduce an error.

One failing module while the rest of DLE works is a strong boundary. Restarting MySQL or changing the global SQL mode at that point is usually a much wider intervention than the evidence supports.

Can a DLE, PHP, or MySQL version mismatch trigger the error?

Yes, but compatibility should be tied to a symptom and a recent environment change. Write down four values before rolling anything back: the exact DLE release, the PHP version used by the website, the MySQL or MariaDB version, and the PHP database extension that the site actually loads.

Check the PHP environment used by the website

On a VPS, the CLI gives a quick starting point:

php -v
php -m | grep -Ei 'mysqli|pdo_mysql'

Do not stop there. A server can have several PHP versions at once, and the shell may use a different binary from PHP-FPM or Apache. If SSH reports PHP 8.x while the DLE virtual host still runs another branch, the CLI result does not describe the web request that failed.

Use the hosting panel, PHP-FPM pool configuration, or another environment-specific method to confirm the PHP version assigned to the site. Also check the PHP and MySQL requirements for DLE hosting for the exact release instead of assuming that every historical version uses the same database API.

When does compatibility become a serious suspect?

This table prevents a common detour: blaming every failure after an upgrade on “incompatibility.” If the returned error is Access denied, start with authentication even if PHP was updated yesterday. The message still has priority.

Check SQL mode instead of disabling it blindly

Stricter MySQL behavior can expose queries or values that an older environment accepted. Read the current mode:

SELECT @@sql_mode;

Then connect it to the failing query. If an INSERT omits a required value or sends data that no longer satisfies the column definition, the durable fix may be in the application or schema.

A compact environment snapshot is:

php -v
php -m | grep -Ei 'mysqli|pdo_mysql'

SELECT VERSION();
SELECT @@sql_mode;

If PHP, MySQL or MariaDB, and the installed DLE release are supported together and the same error existed before the environment change, stop blaming compatibility and return to the actual MySQL message.

What causes intermittent MySQL errors in DLE?

A DLE site that fails for a few requests and then recovers needs time-based evidence. Write down the exact time of the next error. Without a timestamp, service restarts, connection spikes, and resource events are much harder to correlate.

If every site on the VPS breaks together, DLE is probably not your first suspect. If one module on one site fails while the rest of the server stays healthy, narrow the search back to that application.

MySQL server has gone away

MySQL server has gone away means an established connection could no longer be used. A timeout is one possibility, but so are a database restart, network interruption, and requests that run into relevant packet or connection constraints.

Read the current values before changing them:

SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'max_allowed_packet';

Neither value is a diagnosis by itself. A larger max_allowed_packet does not fix a MariaDB crash. A larger wait_timeout does not fix a broken network path.

Check server uptime:

mysqladmin version

If the database reports only a few minutes of uptime and the DLE error occurred a few minutes ago, the restart becomes a concrete lead. Now inspect the journal around that time instead of tuning application limits.

For example:

journalctl -u mariadb --since "10 minutes ago"

Use the correct database unit and a time window appropriate to the incident. Look for a normal administrative restart, crash, OOM-related termination, storage error, or repeated failed starts.

Too many connections

Too many connections means ordinary clients have exhausted the available connection capacity. The real question is whether the configured limit is too low for a healthy workload or whether something is holding connections much longer than expected.

SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';
SHOW FULL PROCESSLIST;

Compare Threads_connected with max_connections. Then inspect the process list for many sleeping sessions, long-running queries, or a repeated pattern from one application account. Visibility depends on privileges, so shared-hosting users may need provider-side evidence.

Do not tune MySQL around one unexplained spike. Raising max_connections increases the number of sessions the server may have to support, which can worsen memory pressure if the workload itself is the problem.

Check whether the database server is running out of resources

Several sites failing together on one Linux VPS is a good reason to check the machine before editing several copies of DLE:

df -h
df -i
free -m

df -h catches a full filesystem. df -i catches inode exhaustion even when gigabytes are still free. free -m gives a quick memory snapshot. Pair those values with service logs rather than interpreting them in isolation.

What should you check after moving or restoring a DLE site?

A MySQL error that starts immediately after migration should be treated as a consistency problem until the evidence says otherwise. The files, database configuration, imported schema, DLE version, PHP runtime, and database server all need to describe the same installation.

A migration can look finished because the domain opens and phpMyAdmin contains tables, while DLE is still using the old database host or an older schema. If the destination installation itself is incomplete, compare it with the steps used to install DLE on hosting. Check the pieces as a set.

Match the error to the migration scenario

Verify the four connection parameters

Compare the destination database host, database name, database user, and password with the values DLE actually uses. Control panels often add account prefixes to DB names or users, and remote database hosts can change completely between providers.

Test the same values outside DLE when possible:

mysql -h DB_HOST -u DB_USER -p DB_NAME

If login fails, stay on the connection or authentication branch. If it succeeds, do not keep rotating passwords. Move to the database and schema checks.

Verify that DLE is using the database you imported

SELECT DATABASE();
SHOW TABLES;

A dump imported into site_new does not help if DLE still connects to site_old. Check the active database name, table prefix, and expected tables together.

On shared hosting, phpMyAdmin can cover much of this check when shell access is unavailable: open the database, inspect its table list, and compare that name with the one assigned to the DLE installation.

Make sure files and database belong to the same application state

Files and database dumps taken on different dates can produce a site that looks almost correct until one module calls a column that did not exist in the older dump. The same thing happens when newer DLE files are uploaded but the database-upgrade step does not finish.

After the migration checks, test both the DLE frontend and admin panel. Then perform one safe read and, if appropriate, one controlled write through the CMS. A migration is not fully verified just because the home page renders.

What should you avoid changing while troubleshooting mysql.php?

Some forum fixes make the error disappear by hiding it or widening permissions. That is not the same as repairing the failed database operation.

Do not publish the complete DLE database configuration in a forum post or ticket. Review screenshots too: database usernames, schema names, filesystem paths, SQL fragments, and sometimes credentials can appear in places that were not meant to be public.

Detailed database errors are useful while diagnosing a failure. Once the problem is fixed, remove temporary public error output so visitors are not shown internal paths or SQL.

How do you verify that the MySQL error is really fixed?

A fix is confirmed when DataLife Engine repeatedly reads and writes data without the same failure and the database or server logs no longer show the original event. One clean reload proves very little after an intermittent problem.

Open the home page and several pages that retrieve different data. Then open the DLE admin panel. If the site allows a safe test, perform one controlled write through the CMS and verify that the change persists.

On a VPS:

mysqladmin ping

Inside a MySQL session:

SELECT 1;
SELECT DATABASE();

For an intermittent failure, repeat the application test under the same conditions that previously triggered it and compare the time with database uptime and logs.

If the original failure cannot be reproduced and the corresponding service or database evidence stays clean, the repair has passed a meaningful verification rather than a single browser refresh.

When is the problem outside DLE, and what should you send to hosting support?

If DLE credentials and schema check out but the database service is unreachable, restarting, dropping connections, or failing at the server layer, further CMS edits only add noise. Shared-hosting users may not have access to the service logs, firewall, socket configuration, or system resource history needed for the next step.

Contact hosting support when the assigned database host does not respond, DB-user permissions cannot be corrected through the panel, connection failures recur without application changes, several databases fail together, or provider-side logs are required to see what happened.

VPS administrators should collect the server evidence first. A useful set is the database service state, relevant journal entries around the exact timestamp, database uptime, connection information, disk usage, inodes, and memory. If the filesystem filled at 14:32, “DLE shows mysql.php line 52” is not the useful part of the ticket.

Never send the database password in an open ticket. A useful support request contains a reproducible symptom, an exact timestamp, the returned error, and the checks already performed. That gives the next technician a starting point instead of forcing the investigation back to “check your database credentials.”