DEV Community: WPShieldPro

A WordPress form says “sent”. Trace one message before changing SMTP.

Dongtao Jiang — Mon, 02 Nov 2026 01:51:36 +0000

A contact form displays a success message, but the enquiry never appears in the team's mailbox. Before replacing the mail plugin or changing DNS, follow one identifiable test through the form, the sending route and the receiving mailbox. Each stage answers a different question.

Concept illustration prepared for this article, not a screenshot of a delivery log or a customer incident.

Start on the page that is actually failing

Use contact details and a mailbox you control. Submit a short message with a distinctive marker, such as Enquiry test A1, and note the page URL, time and time zone. Avoid real customer information in the test.

Keep the initial configuration unchanged. If you change the recipient, sender and sending service together, a successful result will tell you very little about what was wrong.

Identify the form embedded on that page. A site can contain an old form that nobody uses alongside the current one. Check the active notification's recipient and any conditional routing: choosing a department may send the message to a different address.

Separate a successful request from a received message

The WordPress reference for wp_mail() explains that a successful return does not prove the recipient received the email. It means the sending method processed the request without reporting an error.

The form plugin can introduce another distinction. In Contact Form 7, demo_mode: on displays a successful response while skipping email. Its skip_mail: on setting also bypasses sending. These are documented Contact Form 7 settings, not options that necessarily exist in another plugin.

Check whether such a setting was deliberately left on after testing. Do not enable it as a remedy for missing mail.

Find the same test in the sending records

If the site already has a mail log or a sending provider dashboard, search for the test's time, subject and recipient. Establish which sending route the log covers and when logging began. An empty log does not, by itself, show that a visitor never submitted a form.

Then record the evidence rather than shortening everything to “sent”:

Observation	Useful next check
No matching record	Check the active notification and the log's coverage
Sending error	Investigate that error with the website or email administrator
Provider accepted the request	Read the provider's subsequent delivery or bounce events
Recipient cannot locate the message	Check spam, quarantine, filtering and mailbox tracing where available

Status names vary by provider. Read the definition of the event you actually have; do not treat acceptance at one stage as proof that a person can see the message in their inbox.

Retest the real form, not just the mail tool

After addressing an identified issue, use a new marker on the original page. Verify the notification reaches the intended recipient with its expected fields. If department routing, attachments or automatic replies belong to that form's workflow, check those paths too.

A mail plugin's test button can help test its sending connection. It does not exercise the form's recipient rules or field mapping, so receiving that test is not the end of the investigation.

Also establish whether enquiries are stored independently of email notifications. Stored entries can help recover a missed enquiry if storage was already enabled; enabling storage later cannot reconstruct submissions that were never retained. Limit access and retention because entries may contain personal information.

For a handover, leave the form URL, test marker and time, active recipient, relevant sending event, observed mailbox result, and changes already tried. Remove unrelated customer details from shared logs and screenshots. Send credentials through an established secure channel, not in a public troubleshooting thread.

Adapted from WPShieldPro's form email troubleshooting article and shared under the WPShieldPro organization. AI assistance was used to prepare and edit this adaptation and its concept illustration. Technical points were checked against the documentation linked above.

Before changing a broken WordPress site, write down what failed

Dongtao Jiang — Fri, 30 Oct 2026 08:28:49 +0000

A WordPress site loads normally one day and shows a blank page the next. Disabling plugins, switching themes and restoring a backup may each help in the right circumstances. Trying them all at once makes it harder to tell which change mattered. A database restore can also overwrite newer records.

Before making changes, put together a short incident note. It gives whoever investigates a place to start.

This blank record is a place to begin. Include the time zone, and keep passwords, complete orders and customer details out of shared screenshots.

First observed failure and time zone:
Last known working time:
Affected URL and steps to reproduce:
Results while signed out and in the admin area:
Impact on enquiries, orders or account activity:
Recent updates, configuration changes or deployments:
Backup time and what it includes:
Changes already tried, their times and results:

Record the affected requests

Check the home page, an ordinary inner page and the admin login separately. Repeat the check while signed out. Record what appears: a blank response, a critical error, a timeout or a database connection error.

Include the URL and steps if a particular action triggers the failure. “The product page loads, but adding an item to the cart fails” is more useful than “the shop is broken.” Establish whether enquiries, orders or account activity are still being recorded.

Make a timeline

Note the last known working time, then list updates, theme changes, code snippets, PHP changes, cache settings and migrations. If nobody made a manual change, check automatic updates, hosting notices and deployment records.

Have one person coordinate further work. Keep a note of each change and result, including unsuccessful attempts, so another person can take over without repeating every test.

Preserve current data

Confirm that backups include files and the database. Where possible, preserve a copy of the current failed state and relevant logs. An older backup may help with recovery; the current copy may contain newer orders, content and evidence.

Restoring files and restoring a database are separate decisions. For shops, membership sites and connected systems, account for records created after the backup before deciding what to restore.

An isolated copy can help with testing. Prevent it from sending real email, triggering payments or repeating external synchronisation before using it to investigate.

Match logs to the request

WordPress, PHP and server logs may provide evidence. Match entries to the request and time rather than treating every historical warning as part of the incident. A plugin path is a lead, not a complete diagnosis.

The WordPress debugging documentation explains logging and error-display options. These tools are intended for local testing and staging; WordPress does not recommend using them on live sites. Start with the host’s existing PHP and server logs where available. If more evidence is needed, have someone familiar with the environment choose a logging approach in an isolated copy. Prepare an appropriate backup before modifications, keep detailed errors away from visitors and check logs for sensitive data before sharing them.

The official troubleshooting reference describes options when the admin area is unavailable. File and database changes still require care; ask the host or maintenance provider for help if these operations are unfamiliar.

Change one factor at a time

If the failure followed an update, investigate the relationship before making unrelated changes. Where practical, test plugin, theme or environment changes in an isolated copy. Change one factor at a time and record the before-and-after result. Disabling every plugin on a live shop may also disable payments, forms and accounts; a home page that loads afterward is not enough to establish recovery.

When an adjustment removes the symptom, record what you can reproduce and what remains unexplained. Clearing a cache or reverting a version can change the symptom without establishing the cause.

Verify the business flow

A process illustration, not a record of a particular incident.

Check affected pages as an ordinary visitor, then test the relevant function. For an enquiry site, verify submission and receipt. For a shop, check the cart, checkout and order state. For a membership site, check sign-in and permissions. Use controlled tests that avoid real charges and unnecessary customer notifications.

Leave a record of the symptoms, confirmed findings, changes, checks and unresolved questions. If the cause remains unclear, say so. A temporary recovery should not be described as a permanent repair.

Adapted from the WPShieldPro troubleshooting article. AI assistance was used to prepare and edit this adaptation. Technical points were checked against the sources linked above.