Great Lynx Designs

GLX Secure Contact: Building and Debugging a Custom WordPress Contact System

Overview

I developed GLX Secure Contact, a custom WordPress plugin that handles contact form submissions through a lightweight PHP and JavaScript implementation.

Rather than introducing a general-purpose form-building dependency, I wanted a focused solution tailored to the needs of Great Lynx Designs. The plugin gave me direct control over form behavior, validation, spam prevention, and email delivery.

The implementation uses WordPress AJAX handlers, server-side validation, nonce verification, honeypot detection, transient-based rate limiting, optional reCAPTCHA, and SMTP-backed email delivery.

The project also became an exercise in production debugging when legitimate messages were silently rejected because of an unexpected interaction between browser autofill and the plugin’s spam detection.

What began as a straightforward contact form ultimately demonstrated the importance of understanding the complete request lifecycle, from browser interaction to server-side processing and successful message delivery.

The Goal

Design a contact system that is:

• Lightweight, with minimal third-party dependencies
• Resistant to spam and automated abuse
• Observable and diagnosable during testing and maintenance
• Compatible with modern authenticated email delivery
• Easy to maintain within the existing WordPress installation

The aim wasn’t just functionality. It was reliable behavior under real-world conditions.

System Design

GLX Secure Contact operates as a layered system. The browser submits form data asynchronously, WordPress processes the request through PHP handlers, and a series of validation and anti-spam checks determines whether the message proceeds to email delivery.

Key Components

• AJAX submission: JavaScript sends form data without requiring a full page reload.
• WordPress AJAX handlers: PHP processes requests through WordPress’s built-in AJAX infrastructure.
• Nonce verification: WordPress nonces provide a measure of protection against cross-site request forgery (CSRF).
• Honeypot detection: A field intended to remain empty helps identify suspicious automated submissions.
• Rate limiting: WordPress transients help restrict repeated submissions.
• Optional reCAPTCHA v2: An additional verification mechanism can be enabled when appropriate.
• Email delivery: WordPress wp_mail() passes messages through the configured SMTP transport.

These mechanisms provide complementary protections. Nonce verification is not user authentication or proof that a submission came from a human, so independent validation and anti-abuse measures remain necessary.

The Production Failure

The system initially worked as expected, but later exhibited a subtle failure during real-world use.

• The browser displayed a successful submission message.
• The expected emails were not delivered.
• Independent SMTP tests completed successfully.

The interface reported success even though the intended email operation never occurred.

This was especially difficult to diagnose because the visible result suggested that the system was functioning normally.

Investigation

Rather than assuming the problem originated with the mail service, I investigated the request lifecycle across several layers.

• Verified SMTP delivery independently.
• Confirmed that wp_mail() could send messages.
• Compared the execution paths of test and live submissions.
• Examined server-side validation and conditional branching.
• Traced the conditions under which email delivery was skipped.

These tests narrowed the problem to the application’s validation logic rather than the underlying SMTP configuration.

Root Cause: Browser Autofill Triggered Spam Detection

The investigation revealed that the honeypot field, originally named company, was being populated by browser autofill.

The field was intended to remain empty during legitimate submissions. When populated, the server interpreted the request as automated spam and skipped email delivery.

The spam-handling branch deliberately returned a success-like response to avoid revealing detection behavior to automated submitters. However, because browser autofill could populate the field during legitimate use, real users received confirmation even though their messages were never sent.

The problem was therefore not an SMTP failure or an unavailable mail service. It was an interaction between frontend browser behavior and server-side anti-spam logic.

The Fix

I corrected the issue by addressing the interaction between the browser and the honeypot field, then verifying the submission path.

• Renamed the honeypot field to reduce the likelihood of browser autofill targeting it.
• Adjusted the field’s autocomplete behavior.
• Differentiated success and spam-handling responses during debugging.
• Retested legitimate submissions to confirm that they reached the mail handler.
• Verified successful email delivery through the configured SMTP service.

Disabling autocomplete alone cannot guarantee that browsers or password managers will never populate a field. Renaming the field and testing its behavior in actual browsers were therefore important parts of the correction.

Additional Improvements

• Refined email headers, including appropriate From and Reply-To handling for authenticated SMTP delivery.
• Improved visibility into validation and delivery behavior during debugging.

Outcome

• Restored and verified successful contact form email delivery.
• Confirmed operation through the configured Gmail SMTP service.
• Preserved the plugin’s layered anti-spam protections.
• Reduced the risk of legitimate submissions being rejected because of browser autofill.
• Improved the ability to diagnose future validation and delivery problems.

Code Insight: A Small Check with Larger Consequences

The underlying honeypot check is conceptually simple. If the field contains a value, the submission is treated as suspicious.

if (!empty($_POST['glx_hp_field'])) {
    // Spam detected
}

This simplified example illustrates the conditional check, not the complete handler.

The difficult part was recognizing that the field’s value could be changed by browser behavior rather than deliberate user or bot interaction.

A straightforward PHP condition became a production issue because an assumption about frontend behavior was unreliable.

Engineering Lessons

A successful interface response does not necessarily mean that the underlying operation succeeded.

GLX Secure Contact reinforced the importance of examining software as an interconnected system rather than a collection of isolated components.

Building and maintaining the plugin required working across browser behavior, JavaScript requests, WordPress PHP handlers, validation logic, and email infrastructure.

The most instructive problem was not a complicated algorithm. It was a small assumption—that an invisible form field would remain empty—that proved unreliable under real-world browser behavior.

The project illustrates the value of end-to-end debugging, layered security controls, and clear observability when maintaining production web applications.

More broadly, it demonstrates the kind of engineering ownership required to design, implement, troubleshoot, and maintain a custom WordPress application component.