Production-grade custom code for hardening targeted Elementor form submissions with server-side business-email qualification, validation, and normalization.
GitHub repository: https://github.com/jeremy-burgos/elementor-form-hardening
This repository documents and stores a reusable custom-code implementation for WordPress websites that use Elementor forms and want stricter lead qualification controls.
It is designed for production environments where form quality matters and where relying only on front-end validation is not sufficient.
This is not a standalone plugin repository.
The implementation is deployed through Code Snippets or an equivalent reviewed custom-code loading method, and this repository exists to showcase the engineering, documentation, governance, and security posture behind that implementation.
Many lead forms attract low-quality, disposable, irrelevant, or consumer-email submissions that create noise for businesses trying to qualify serious inquiries.
This project was built to address that problem in a maintainable way across multiple WordPress websites by enforcing targeted server-side controls rather than depending on ad hoc page-level fixes.
This is a lead-quality filter, not a security control. It reduces casual consumer-email noise on targeted forms. It does not stop bots, spam, or abuse, and a determined submitter can register a domain that is not on the denylist. Use it alongside honeypots, CAPTCHA, and WAF controls where abuse prevention is the actual goal.
Elementor Form Hardening should be understood as a configurable form qualification and submission-hardening implementation.
Its value comes from:
- strict form targeting
- server-side validation
- configurable business-email qualification rules
- server-side normalization before downstream Elementor actions run
- maintainable governance and documentation for production use
This implementation is designed to:
- apply only to intentionally targeted Elementor forms (form-name prefix match)
- reject consumer and free-email domains server-side using an exact denylist and a first-label prefix denylist
- reject malformed email values server-side
- return clear, non-deceptive rejection messaging
- support repeatable deployment across multiple WordPress websites
- keep the implementation reviewable, documented, and controlled in GitHub
This implementation does not:
- replace honeypots, CAPTCHAs, WAF rules, or broader anti-abuse controls
- guarantee lead quality
- assume business-email-only rules are correct for every business
- silently intercept unrelated forms
- auto-deploy from GitHub to production
- implement an allowlist-only ("block everything not explicitly allowed") mode
Enforcement is denylist-based. A submitted email domain is rejected if it matches:
- an exact blocked domain (
efh_blocked_domains), or - a blocked first-label prefix (
efh_blocked_prefixes), where the prefix is compared against the domain's first DNS label
An optional allowlist (efh_allowed_domains) is provided. The denylist takes precedence: a domain on both lists is rejected. Because enforcement is denylist-based, the allowlist has limited functional effect today and is documented as an exception-carve-out and extension hook rather than as an override mechanism. See docs/validation-rules.md for full precedence details.
All four lists are adjustable through filters without editing core logic.
Blocking free-email providers is a business decision with tradeoffs.
For some businesses, that policy improves lead quality and reduces irrelevant inquiries. For others, it may block legitimate prospects.
This repository treats business-email qualification as configurable policy, not as a universal best practice.
This project is deployed as custom PHP code through Code Snippets or an equivalent reviewed custom-code deployment method.
It is intentionally not packaged in this repository as a standalone WordPress plugin. That choice reflects the real production implementation and keeps the GitHub presentation accurate.
| Filter | Purpose | Default |
|---|---|---|
efh_form_prefix |
Targeted form-name prefix | LeadForm- |
efh_email_field_id |
Targeted email field ID | email |
efh_error_message |
Public rejection message | Please enter a valid business email address. |
efh_blocked_domains |
Exact-match blocked domains | built-in consumer list |
efh_blocked_prefixes |
First-label blocked prefixes | built-in provider-family list |
efh_allowed_domains |
Explicit allowlist (denylist still wins) | empty |
Pure domain-qualification logic is covered by PHPUnit.
composer install
composer testThe test bootstrap shims the small set of WordPress functions the snippet uses, so the domain logic runs without a full WordPress install. Elementor record handling is not unit tested because it requires the Elementor runtime; that path is covered by the manual matrix in docs/testing-guide.md.
Runtime behavior has been verified on PHP 8.3. The runtime snippet itself supports PHP 7.4 and later. The PHPUnit dev tooling requires PHP 8.1 or later.
snippets/contains the production custom-code source tracked in this repositorytests/contains the PHPUnit suite and bootstrapdocs/contains implementation, validation, compatibility, security, and release documentation.github/contains governance, issue templates, code ownership, and pull request controls
- Architecture
- Security model
- Validation rules
- Testing guide
- Compatibility notes
- Error codes
- Implementation blueprint
- Release process
- Demo notes
- FAQ
This repository is public for transparency, reviewability, and professional presentation.
Public issues are welcome. Public pull requests may be allowed, but merges into the trusted main branch remain maintainer-controlled through CODEOWNERS, protected-branch policy, and manual review.
Public visibility does not equal public trust.
Do not report vulnerabilities in public issues. Use the process in SECURITY.md.
Support boundaries and reporting guidance are documented in SUPPORT.md.
Release history is tracked in CHANGELOG.md.
This repository is licensed under GPL-2.0-or-later. See LICENSE.