Meridian Forms

A reusable WordPress registration & payment forms plugin: build any number of forms with a visual builder, take payments through Stripe, and connect whichever email provider you want — no code changes needed per client.

Made by Waqas Anwar.

GitHub: waqasdev01

What's in v1.0.1

• Visual form builder — add/remove/reorder sections and fields, with a live preview, from Meridian Forms → Forms → Add New Form. Field types: Text, Email, Phone, Number, Date, Dropdown, Radio, Checkbox group, Single checkbox (consent), Paragraph text, File upload, Hidden.
• Multi-section forms — one form, one section (looks like a normal form) or several — the admin decides per form.
• Payment & pricing per form — enable/disable Stripe checkout per form, fixed price or a tiered "early bird" pricing schedule, capacity limits, and promo codes (percentage or fixed amount off, with an optional max-uses cap).
• Pluggable email — WordPress (SMTP), MailerLite, or Zapier. Switching providers is one click in Email Integration; the registration/payment logic never talks to a provider directly (MRD_Email_Provider interface + MRD_Email_Service dispatcher), so adding a new provider later is one new class.
• Independent per installation — activation creates this site's own database tables (wp_mrd_forms, wp_mrd_submissions, wp_mrd_payments). Nothing is shared between sites; Stripe/email credentials are entered per install under Stripe / Email Integration.
• Admin area: Dashboard, Forms, Submissions, Payments, Email Integration, Stripe, Settings, Tools, Help — all under one "Meridian Forms" menu, with a consistent design system (see assets/admin.css).
• Security: nonces + current_user_can( 'manage_options' ) on every admin action, Stripe webhook HMAC signature verification (with a 5-minute replay window), server-side validation against the configured fields plus price/capacity/promo re-validation on every checkout, request rate limits, and file uploads restricted by extension/MIME/size and routed to their own uploads subfolder.

Getting started

1. (Optional) Add your Stripe keys and webhook secret under Stripe, for any form that will take payment. The exact webhook URL to add in your Stripe Dashboard is shown on that page.
2. Choose an email provider under Email Integration.
3. Go to Forms → Add New Form, build your sections/fields, and configure payment & pricing if needed.
4. Publish the form and paste its shortcode — [mrd_form id="X"] — into any page or post.

Architecture notes (for future development)

• class-mrd-forms.php owns form CRUD, the schema (sections/fields) format, and the pricing/capacity/promo-code engine — this replaced what used to be two hardcoded event types spread across two classes.
• class-mrd-field-renderer.php turns a form's schema into frontend HTML/JS at render time — there is no per-client template file any more.
• class-mrd-rest-api.php is generic over form_id; it no longer knows about any specific client's fields.
• class-mrd-email-*.php implement MRD_Email_Provider; register a new one via the mrd_email_providers filter.
• assets/admin-builder.js is a small vanilla-JS app with no build step — it keeps the schema in memory, re-renders the editor + a live preview on every change, and writes the current schema into the hidden #mrd_schema_json field that the PHP save handler reads.

Known trade-offs in this v1 (documented, not hidden)

• Field reordering uses ▲▼ buttons rather than native drag-and-drop. Functionally equivalent, less visually flashy — flagged as a possible v1.1 addition.
• The live preview in the builder is a JS mirror of the PHP renderer (previewField() in admin-builder.js vs. render_field() in class-mrd-field-renderer.php) rather than a literal server round-trip, so it's fast but is a close visual match rather than byte-identical output.
• Multi-section forms render as one continuous page (sections shown as labelled fieldsets) rather than a multi-step wizard with per-step navigation. A stepped wizard is a reasonable v1.1 addition if a client specifically wants it.
• MailerLite group targeting is global (Email Integration → MailerLite → Default group ID) rather than configurable per form. A per-form override (MRD_Email_MailerLite already checks for payment['mailerlite_group_id'] if present) is a small addition — wire up a field for it on the Payment & Pricing tab when a client needs different forms feeding different MailerLite groups.

Uninstalling

Deleting the plugin from wp-admin removes its settings but keeps the three data tables (forms/submissions/payments) so registration history is never silently destroyed. Use Meridian Forms → Tools → Delete all plugin data first if you want a completely clean uninstall.