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.
OMEGA WEB PRO HOSTING
Forms on Omega Web Pro Hosting
For an active hosted project, server-side form handling, private configuration and runtime requirements belong to the managed Omega Web Pro Hosting environment rather than the generated browser code.
Customer control plane
SMTP passwords, database credentials and service secrets remain private. Customers manage website-level hosting functions through the Omega Web Pro Hosting Dashboard without receiving internal infrastructure-management credentials.
Managed hosting plans
Monthly US$9.99 · Annual US$99 · Two Years US$179. Managed Omega Web Pro Hosting remains available while the recurring plan is active.
Lifetime software licence
US$999 one time for permanent supported build, edit and export rights for one licensed website domain. Production hosting is separate and can be added when required.
Current production customer architecture
Build, purchase, billing, hosting and editing continue through one authenticated Omega customer relationship.
For a first-time Omega Hosting checkout, Omega saves the selected plan and pending website to one restricted checkout-bound customer account before payment, sends a secure one-time account-setup email, and requires the customer to set a password and sign in before continuing to the required purchase acknowledgements and secure Stripe Checkout. Paid Hosting and Editor entitlement remain locked until Stripe confirms payment. For a first-time Lifetime Licence purchase, an existing account is reused where available, or the customer account is created after Stripe confirms the purchase. My Account is the commercial identity, website, licence and billing centre; recurring hosting customers can use the Full Hosting Dashboard while entitled; lifetime customers retain their separate same-domain software rights.
My Account
Purchased websites, subscription/renewal state, lifetime licences, Pending Checkout, Purchase History, profile/security, Builder and Website Editor entry points.
Billing Centre
Secure Stripe customer-portal access for the account's usable canonical production billing customer, including supported payment-recovery and subscription billing actions.
Omega Hosting Dashboard
Entitled operational hosting controls for project workspaces, provisioning, deployment, backups, databases, SFTP and usage, with customer-facing DNS/SSL state surfaced through Omega interfaces.