Contact form
Secure contact form with server-side delivery expectations.
▤ OMEGA WEB PRO DOCUMENTATION • FORMS & SMTP
Generated Forms Need a Real Server-Side Delivery Path.
Omega can generate conversion forms and contact workflows, but email delivery depends on the selected platform and the customer's deployment environment. This guide explains the Pure HTML PHP/SMTP path, the WordPress-native path and the private configuration rules that keep credentials out of public files.
Secure contact form optionAuthenticated SMTPPrivate credentialsPure HTML backendWordPress-native handlingNonce verificationwp_mail integration
FORM • VALIDATE • SERVER • SMTP / WORDPRESS • DELIVER
FORM DELIVERY ARCHITECTURE● CURRENT PLATFORM REFERENCE
DocumentationBuilder FormsPure HTMLWordPressSecurityDeliverabilityPrivacy + SpamTroubleshooting
✓ Credentials private✓ Server validation required✓ Platform-specific handling
Generated form features
Form requirements begin in the website specification.
The Builder can include contact and conversion-oriented components according to the selected project features.
Newsletter
Newsletter signup section when selected; real external list-provider integration may require customer configuration.
Booking CTA
Booking/appointment calls to action.
Quote CTA
Quote-request calls to action/forms.
Lead magnet
Download/lead-capture CTA components.
Pure HTML form path
Pure HTML requires compatible server-side processing when a form must send email.
Static HTML alone cannot securely keep SMTP credentials or send authenticated mail by itself.
Frontend
Generated form markup and browser-side UX live in the website.
Server endpoint
A compatible PHP backend handles submission processing when included by the project.
Authenticated SMTP
Operational mail is sent using server-side SMTP configuration rather than embedding credentials in JavaScript.
Private config
SMTP host, username, password, sender identity and other secrets belong in private server configuration outside public_html where possible.
WordPress conversion
WordPress output does not simply keep the Pure HTML PHP endpoint.
The dedicated WordPress renderer converts form handling to WordPress-native mechanisms.
admin_post
Form submissions use WordPress admin_post/admin_post_nopriv hooks where generated by the renderer.
wp_verify_nonce
Nonce verification protects the generated WordPress form flow.
wp_mail
Email delivery is routed through WordPress's mail API.
Validator
The WordPress validator checks that obsolete Pure HTML contact endpoint references are removed and native integration exists.
Credentials + validation
Never put real SMTP or API credentials in browser JavaScript or exported project content.
Secrets must remain server-side.
Private storage
Use private configuration one level above public_html where supported by the host.
No client secrets
Do not place SMTP passwords, provider API keys or webhook secrets in HTML/JS.
Server validation
Validate required fields and submission state on the server; browser validation alone is not a security boundary.
Same-origin controls
Use the generated server/security architecture and avoid broad cross-origin submission rules unless intentionally required and reviewed.
Email operations
Successful form code does not guarantee inbox delivery.
SMTP authentication, DNS reputation and recipient filtering all affect deliverability.
Correct credentials
Use the correct provider host, port, username, password and encryption settings.
SPF/DKIM/DMARC
Configure the sending domain according to the email provider's guidance.
Sender alignment
Use a sender identity permitted by the authenticated SMTP account.
Test real delivery
Test submissions from the deployed production URL and confirm delivery, reply handling and spam-folder behavior.
Operational responsibility
Forms collect user data, so deployment decisions matter.
The generated website owner remains responsible for applicable privacy, consent, retention and anti-spam obligations.
Privacy disclosure
Explain what information is collected and why where required.
Consent
Add appropriate consent/marketing permission wording for newsletters or lead capture where required.
Abuse controls
Use practical anti-spam/rate-limiting or provider controls appropriate to the production environment.
Data retention
Understand where submissions/logs are stored and avoid unnecessary sensitive data collection.
If mail fails
Diagnose the layer that actually failed.
A visible successful button click does not prove the email reached the destination.
Form request
Confirm the browser submits to the expected endpoint/action.
Server response
Check PHP/WordPress errors and permissions.
SMTP / wp_mail
Check authentication/provider logs and WordPress mail behavior.
Inbox delivery
Check recipient filters, spam folder, SPF/DKIM/DMARC and sender alignment.
Omega Web Pro documentation
Treat form delivery as a server feature, not just a visual component.
Configure the project in Builder, keep credentials private and test the actual deployed submission path before relying on the form.