A WordPress site that sends a contact form, takes a payment, and processes an event signup typically runs four to six plugins for those jobs – a form builder, an SMTP plugin, a payment-gateway add-on, an event-registration plugin, a sender-override snippet, sometimes a forms-plus-payments bridge. Each is admin UI, a database table, a release cadence, and an attack surface. For most sites, that is the right trade.
For some sites it is not. The same jobs can be done by an HTML form posting to a hosted handler, a short phpmailer_init snippet in wp-config.php, an <a href> to a Stripe Payment Link, or a single PHP filter in a mu-plugin file. The site loses an admin UI it never used; the plugin’s release cadence, CVE history, and row in the plugins screen go with it.
This page collects the five WordPress jobs where the no-plugin path is a real alternative and links to the slice piece for each. It is the minority path on purpose. Most WordPress sites still benefit from the right plugins; that is what WP Mail SMTP, WPForms, Gravity Forms, and WooCommerce exist for, and the best WordPress SMTP plugins roundup is the entry point when a plugin is the answer.
Why operators take this path
Five motivations show up across the cluster:
- CVE and privilege-escalation surface. Form plugins are the canonical case:
Contact Form 7’s CVE history is the example people cite, but every form plugin sits on the same attack class – an admin configuration UI plus an unauthenticated public submission endpoint, both on the WordPress release cadence. - Plugin sprawl and maintenance load. Every plugin is a settings page, an update notice, a compatibility risk against the next core release, and a row in the plugins screen. A site running 25 plugins to do five jobs is not unusual.
- Performance. Admin-heavy plugins ship CSS and JavaScript on the front end (event calendars, forms-plus-payments stacks, e-commerce cart widgets) even when only one page uses them.
- Vendor lock-in. Data inside WooCommerce, EventOn, or a forms plugin’s submission archive is hard to leave. A hosted endpoint is a different lock-in, but a cleaner exit when the migration target is “another hosted endpoint” rather than “another WordPress plugin.”
- Developer preference for code over UI. Agencies and operators who manage WordPress as code prefer credentials in
wp-config.php, behaviour in amu-plugin, and an<a href>over a settings panel three clicks deep.
Contact forms
A WordPress contact form is, structurally, an HTML <form> and a recipient address. The standard stack adds a form builder (Contact Form 7, WPForms, Gravity Forms), an SMTP plugin, a sending service, and DNS authentication records. The no-plugin path is a <form action="https://..."> pointing at 
Formspree, 
Basin, 
Formspark, or 
Forminit. The handler accepts the POST, delivers the submission as email, and archives it in its own dashboard. WordPress holds no submission data. Security is the dominant motivation: removing the plugin removes the attack class.
Slice piece: Create a WordPress contact form without plugins.
SMTP and outbound mail
WordPress core’s wp_mail() hands off to PHPMailer, which exposes a phpmailer_init filter that fires before any message leaves the site. A short snippet in mu-plugins/smtp.php, plus a few SMTP_* constants in wp-config.php, points PHPMailer at an external SMTP server with credentials in the filesystem rather than the database. The motivation is developer control: secrets in version-tracked code, not the options table. The trade-off is the loss of WP Mail SMTP’s logging, retry, and admin debug.
Slice piece: WordPress SMTP without a plugin. See also the hosts without an SMTP plugin roundup for hosts whose default wp_mail() already delivers (SiteGround, DreamHost, Hostinger, Nexcess, Bluehost, Liquid Web, Pagely).
Sender address and From name
WordPress sends from [email protected] by default. Two filters override that: wp_mail_from and wp_mail_from_name. A short mu-plugin with both is enough; an SMTP plugin’s From Email override does the same job through the admin UI when one is already installed. The motivation is plugin sprawl: a dedicated From-override plugin is a settings page, an update, and a row in the plugins screen, all to set two strings. The DKIM-alignment trap applies either way: DKIM (the cryptographic signature receivers use to confirm the message came from your domain) only validates when the From domain matches the signing domain.
Slice piece: How to change the WordPress email sender.
Event registration
Event-registration plugins (The Events Calendar plus Event Tickets, 
EventOn, 
Modern Events Calendar, 
Event Espresso) each register a custom post type, attach a payment gateway, and ship a calendar UI to the admin. For a quarterly meetup, a one-off workshop, or a small ticketed launch, the maintenance surface dwarfs the workload. Two no-plugin paths cover the job: embed a hosted event platform (Eventbrite, Lu.ma, Ti.to, RingCentral Events, Posh) inside a Custom HTML block, or pair a bare HTML form with a 
Stripe Payment Link for paid tickets. Lock-in and performance are the dominant motivations here.
Slice piece: WordPress event registration without a plugin.
One-off payments
A single donation, a workshop deposit, a one-product launch – the default stack is WooCommerce plus a payment-gateway plugin, or a forms-plus-payments add-on. Three lighter paths handle the job: a Stripe Payment Link as a plain <a href>, an embedded checkout button (Stripe Buy Button, PayPal Standard Checkout) in a Custom HTML block, or a bare HTML form posting to a form-service handler with a Payment Link in the success state. Performance and lock-in both drive this one: a 50 MB e-commerce platform for one payment a week is a lot of WordPress to maintain.
Slice piece: WordPress payment form without a plugin.
When this is the wrong call
The no-plugin path is wrong for sites that need what the plugin actually provides. A WooCommerce store running real catalogues, tax rules, and shipping zones needs WooCommerce. A site taking 200 contact-form submissions a week and routing them through three sales-pipeline integrations needs a real form plugin. A site whose operator does not edit wp-config.php should not be told to. The test is whether the plugin is doing work the no-plugin path cannot do, or whether it is a four-tab settings UI wrapping a one-line behaviour. The first stays. The second is what this hub is about.