Contact Form Not Saving Data to Database

“`html

Why Forms Submit But Data Disappears

I spent three hours troubleshooting a contact form last Tuesday before realizing the obvious. The form submitted successfully. The user got a thank-you message. But when I checked the database? Nothing. Not a single row.

This form-submits-but-data-vanishes problem has gotten complicated with all the misleading articles flying around. Most guides focus on email delivery failures—why your notifications aren’t arriving. But the real issue here is different. Your form submission succeeds at the HTTP layer while failing at the database layer. The form works. The server responds. Your database just never gets the data.

Here’s what happens. A visitor fills out your contact form and clicks submit. Their browser sends an HTTP POST request to your server. Your server processes it, returns a 200 success response, displays a thank-you message. Everything looks fine. But somewhere between that HTTP request being received and the data hitting your database tables, the chain breaks.

Three scenarios cause this most often. First, the form submission completes a redirect before the database write operation finishes — your code saves the success message to cache, sends the user away, but the database transaction times out mid-process. Second, the database connection drops unexpectedly. Maybe your host restarted a service. Maybe there’s a network blip. Maybe the connection pool exhausted. Third, and probably should have opened with this section honestly, your form builder isn’t actually configured to save to the database at all. The fields exist in your form. The form submits. But there’s no mapping between those fields and your database columns.

The result feels like a ghost form. It appears to work. But your CRM is empty. Your database tables have no new entries. Your business misses inquiries because you never see them.

Check Your Database Connection String First

Start here. Forty percent of these cases boil down to a bad connection string.

Open your WordPress installation and navigate to wp-config.php in the root directory. Look for these four lines:

• DB_NAME
• DB_USER
• DB_PASSWORD
• DB_HOST

These must match exactly what your hosting provider gave you. Not approximately match. Exactly.

If you’re running on shared hosting, log into your control panel — cPanel, Plesk, whatever your host uses. Navigate to the database section. Find your database name. It often has your account prefix attached, like “account_wordpress” instead of just “wordpress”. Find the database user — same thing, often prefixed. Check the hostname. Most hosts use “localhost”, but some use “127.0.0.1”, and some use a remote server like “db-server-03.example.com”.

Copy these values exactly. One typo kills everything.

Once you’ve verified the credentials, test the connection. Create a simple PHP file in your public_html directory — or web root. Name it test-db.php. Add this:

<?php
$conn = mysqli_connect("localhost", "db_user", "db_password", "db_name");
if (!$conn) {
die("Connection failed: " . mysqli_connect_error());
}
echo "Connected successfully";
mysqli_close($conn);
?>

Replace the values with your actual credentials. Visit the file in your browser. If you see “Connected successfully”, your connection string works. If you see an error, you’ve found your problem.

Delete that test file immediately when done.

If your credentials are correct but the connection test fails, contact your hosting provider. They may have network issues, database server problems, or IP restrictions preventing your connection. I once had a host that required me to whitelist my office IP manually — took 20 minutes to figure that out.

Verify Form Field Mapping and Table Structure

Your form works. Your database connects. But data still isn’t appearing. Now we look at the middle layer — the mapping between form fields and database columns.

Here’s what I learned the hard way: a form builder can capture a field value without saving it anywhere. The field appears in your form. Users fill it out. The form submits. But if the plugin isn’t configured to save that specific field to a specific database column, it vanishes.

Check two things. First, verify your form is actually capturing the field data. Most form builders have a “Form Fields” section where you drag fields onto your form. Contact Form 7, WPForms, Gravity Forms — they all work this way. Check that every field you want saved has been added here, not just typed as static text.

Second, verify the field mapping. Open your form plugin’s settings. Look for “Database” or “Save” options. Some plugins automatically save to a default table. Others require you to manually specify which form field maps to which database column.

For Contact Form 7, this is handled by third-party plugins like Email Template Manager or Database Addon. WPForms has built-in database saving. Gravity Forms has native database integration. Each works differently.

In WPForms, open your form editor. Click “Settings” then “Database Saving”. You’ll see a section where you select a database table and map each form field to a column. Field name “Email” maps to column “user_email”. Field name “Message” maps to column “message_text”. If a form field isn’t mapped here, it won’t be saved to the database, even though users can fill it out.

Check your database structure too. Use phpMyAdmin — accessible from your hosting control panel — or your command line MySQL client. Look at the actual table where form data should land. What columns exist? What data types are they? If your form tries to save a phone number to a BIGINT column, the save might fail silently.

I once spent two hours debugging a form that wasn’t saving ZIP codes. Turned out the ZIP column was defined as INT(5). Some ZIPs started with zero — like 01234 for Massachusetts — and MySQL was stripping those leading zeros during the insert, then failing validation. Changed it to VARCHAR(10) and everything worked.

Check Database Permissions and Storage Limits

Your connection works. Your field mapping is correct. Data still won’t save. Next stop: database permissions and storage limits.

The database user configured in wp-config.php needs INSERT and UPDATE permissions on the specific table storing form data. Created a new database user for form submissions instead of using your main WordPress account? That user needs explicit grants.

In phpMyAdmin, go to the Users section. Find your database user. Click “Edit Privileges”. Scroll to the table-level permissions. Make sure “INSERT” and “UPDATE” are checked for the form data table. Missing either, and form data saves fail silently.

Next, check if your database has hit a size limit. Shared hosting plans often cap database size at 500MB, 1GB, or 5GB. If you’ve hit that limit, new inserts fail silently because there’s no room to write.

In phpMyAdmin, go to the home page. Look for a “Server” tab or check the information dashboard. You’ll see something like “Total size: 487.5 MB / 500 MB”. If you’re at or near the limit, you’ve found your culprit.

If you’re maxed out, delete old data, optimize tables, or contact your host about upgrading your plan. Running an InnoDB table optimization — which reclaims space — sometimes helps too.

Debug with Browser Console and Server Logs

The nuclear option: read the actual logs.

Open your browser’s developer tools. Press F12 or right-click and select “Inspect”. Go to the Network tab. Fill out your form and submit it. Watch the network request. Look for the POST request to your form submission handler. Click it. Check the response status. Is it 200? Is it 500? Anything in the response body indicating an error?

A 200 response with an error message in the body tells you the request reached the server and the server responded — but something failed during processing. A 500 response indicates a PHP fatal error. A timeout suggests a long-running database operation that never completed.

Now check your server logs. In WordPress, enable debugging by editing wp-config.php and adding:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

This creates a debug.log file in /wp-content/. Submit your form again. Check that log for errors related to database operations, form processing, or the specific plugin handling your form.

Your hosting provider’s error log catches PHP errors too. In cPanel, go to Metrics > Errors. In Plesk, check Domains > Your Domain > Logs. These logs often show database connection errors, permission denied messages, or query failures that WordPress logging misses.

If you have SSH access, grep the error logs directly:

grep -i "form\|database\|insert" /var/log/apache2/error.log | tail -50

This searches the Apache error log for the last 50 lines mentioning form, database, or insert operations. Adjust the log path and search terms for your environment.

Those logs will show you exactly why data isn’t being saved. Connection timeout. Permission denied. Table doesn’t exist. Field type mismatch. Whatever the actual issue is, it’s logged somewhere.

Once you find the error message, you have something concrete to fix. Start with connection credentials. Move to field mapping. Check permissions and storage. End with logs. One of these layers will show you where the data chain is breaking.

“`