Confirm the specific change before editing configuration
After a known database credential change, compare WordPress's protected connection settings with the existing authorised database account.
Use the known credential change and its time to narrow the WordPress database fault. Record the first error time, the exact site and who made the change. WordPress lists incorrect configuration and hosting-side database faults as separate possible causes, so a recent credential edit is a likely branch, not proof. If several unrelated sites fail at once, report a possible shared database service fault promptly.
Keep a secure copy of the current application configuration and a suitable site backup. The site’s administrator or application owner should control edits to wp-config.php. Do not copy its contents into a ticket: it can contain database credentials and other secrets. Do not expose a temporary diagnostic copy under the public web directory.
Match four settings to the existing account
WordPress identifies the database name, username, password and host in wp-config.php as the connection values to check. Compare them privately with the currently authorised database account and the operator’s documented host value. Be careful with a changed password: the authorised application owner should verify and update the value privately, without sending the password to support or including it in a ticket. Confirm that the database still exists through the account’s permitted panel view if available.
Do not create a new empty database as a quick fix; the existing site content lives in the original database. Do not broaden a database user to all databases to make a connection succeed. If the host or database name is uncertain, ask support for the account’s correct value before changing it.
Restore the approved connection setting
When the application owner confirms a single wrong value, edit only that value through the authorised protected file route. Preserve the file format and permissions. If a planned password rotation was partly completed, coordinate the account and application change so they refer to the same current credential; avoid repeatedly changing the database password while other applications or jobs may still use it. Keep the previous configuration copy privately for rollback, but treat an old exposed password as unsuitable for reuse.
Prove the site is reading the intended data
Open the public site and admin area in new sessions. Check a recent known post or page to confirm that WordPress connected to the intended existing database rather than an empty one. If the four settings match and the error persists, or other databases are affected, stop editing and send the error wording, affected domain and times to platform support. The operator can check database availability or account limits under the contracted scope. Do not send passwords or a full configuration file.
For example, a connection using the new database credential may work while an application write still fails. Test one authorised low-impact action and restore it if needed; never publish a diagnostic file containing the password.
Frequently asked questions
Should I reset the database password again? Only through an agreed rotation plan. A second reset can break other consumers of that user.
Does the error mean data was deleted? No. It means WordPress could not establish a usable connection; verify the database state separately.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.