Author: onetwothreeadmin

WordPress sends two kinds of email: the newsletters and marketing messages you schedule through a platform, and the transactional messages your site generates automatically—password resets, comment notifications, form submissions, order confirmations. Most operators notice the latter only when it breaks.

Transactional email typically leaves your server through one of two methods: SMTP (Simple Mail Transfer Protocol) or API. Each has different failure modes, and mixing them up costs you customer trust and support time.

SMTP: the older, slower, more fragile path

SMTP is the internet’s original email-sending protocol, defined in RFC 5321 (checked October 2026). When WordPress uses SMTP, it opens a connection to a mail server, authenticates, hands over the message, and waits for confirmation. Plugins like WP Mail SMTP and Easy WP SMTP reconfigure WordPress to route outbound mail through a dedicated SMTP service instead of your web host’s default mail server.

SMTP works, but it’s synchronous: WordPress waits for the handshake to complete before moving on. If the remote server is slow or the connection times out, your user sees a spinning loader or an error. Shared hosting providers often throttle or block port 25 (the default SMTP port) to prevent spam, forcing you to use port 587 or 465 with TLS authentication. Firewall rules, IP reputation scores, and greylisting all introduce points of failure.

When SMTP fails, the symptom is usually silence—no error logged, no email delivered, no bounce notification. WordPress assumes the handoff succeeded because the SMTP server accepted the connection, but downstream filters or reputation blocks kill the message before it reaches the inbox.

API: faster, more observable, purpose-built for transactional mail

API-based transactional email services—Postmark, SendGrid, Amazon SES, Mailgun—let WordPress send a JSON payload over HTTPS instead of negotiating an SMTP handshake. The request completes in milliseconds, returns a message ID, and hands off delivery to infrastructure purpose-built for high-volume transactional sending.

API transport is asynchronous by design. WordPress fires the request and moves on; the service handles queuing, retries, and reputation management. You get webhooks for bounces, complaints, and delivery events, and a dashboard that shows exactly which messages were sent, opened, or blocked. When an API call fails, you see an HTTP status code and an error message—usually authentication errors, rate limits, or malformed payloads.

The trade-off: API services require a plugin (or custom code) to replace WordPress’s default wp_mail() function. You’re also introducing a dependency on a third-party service. If their API goes down or your authentication token expires, transactional mail stops until you fix it. SMTP plugins can fall back to the host’s mail server; API plugins typically can’t.

When each method breaks—and how to tell

SMTP failures are usually silent and network-layer: port blocks, authentication mismatches, IP reputation issues, SPF or DKIM misconfigurations. You’ll see timeouts in server logs, but WordPress itself often reports success. Tools like MXToolbox (checked October 2026) help you test DNS records and mail-server reachability from outside your hosting environment.

API failures are louder and application-layer: invalid API keys, exceeded rate limits, rejected sender domains, webhook signature mismatches. Check your plugin’s debug log and the service’s activity dashboard. Most API providers offer a test-send endpoint you can call from the plugin settings to verify the integration before a customer triggers a real message.

For high-stakes transactional email—password resets, two-factor codes, order confirmations—API transport is the safer default. Postmark, for example, focuses exclusively on transactional delivery and publishes a real-time deliverability dashboard (checked October 2026). Services that blend marketing and transactional sending (SendGrid, Mailgun) require careful IP-pool and subdomain configuration to keep reputation clean.

Pick the method that matches your failure budget

If your site sends fewer than a hundred transactional emails a month and you’re comfortable diagnosing SMTP authentication in cPanel, a basic SMTP plugin works. If missed password resets cost you support hours or revenue, route transactional mail through a dedicated API service and set up a separate monitoring ping for delivery rate.

Don’t rely on your web host’s default mail server for anything that matters. Shared hosting mail has no reputation management, no bounce handling, and no visibility. The five dollars a month you save by skipping a dedicated transactional service costs you more the first time a customer’s order confirmation lands in spam.

Want more infrastructure deep-dives like this? Subscribe to One Two Three Send and get one operator-focused article every morning.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

Your WordPress site feels slow. You’ve already compressed images, minified CSS, enabled object caching—and page load times are still terrible. The culprit is often hiding in plain sight: database table indexes that are missing, bloated, or broken.

Most solo operators never look at their database structure until something breaks. But queries that scan hundreds of thousands of rows without an index can add seconds to page generation time, even on small sites. Here’s how to find the problem tables and decide what to do about them.

What indexes do and why they break

An index is a sorted lookup table that helps MySQL find rows without scanning the entire table. When WordPress runs a query like SELECT * FROM wp_posts WHERE post_status = 'publish' ORDER BY post_date DESC, MySQL checks for an index on post_status and post_date. If those indexes exist, the query returns in milliseconds. Without them, MySQL reads every row in the table—thousands or millions of disk operations.

Indexes break or go missing for a few reasons:

• Plugin migrations that create custom tables without proper indexes
• Large DELETE operations that leave fragmented indexes behind
• Manual SQL imports that skip index definitions
• Composite indexes that don’t match the query’s WHERE clauses

The WordPress core tables—wp_posts, wp_postmeta, wp_options, wp_comments—ship with solid default indexes (WordPress Codex database schema reference, checked October 2026). But plugins that add metadata, log tables, or custom post types often don’t add indexes for their own queries.

How to identify slow queries and missing indexes

Start by enabling MySQL’s slow query log. Most managed WordPress hosts (including BigScoots) expose this in their dashboard or phpMyAdmin. If you run your own server, add these lines to my.cnf or my.ini:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow-query.log
long_query_time = 1

Any query taking longer than one second will be logged. Restart MySQL, let your site run under normal traffic for an hour, then open the log. Look for queries with high Rows_examined counts—anything above 10,000 rows for a single SELECT is a red flag.

Next, check which tables are missing indexes. Log into phpMyAdmin or your database client, select your WordPress database, and run:

SHOW TABLE STATUS;

Look at the Data_length and Index_length columns. If a table has 50 MB of data but only 2 MB of indexes, and you know plugins are querying it heavily, you likely need to add indexes.

To see which indexes exist on a specific table, run:

SHOW INDEX FROM wp_postmeta;

WordPress adds a post_id index and a meta_key index by default. If a plugin queries WHERE meta_key = 'custom_field' AND meta_value = 'something', and there’s no composite index on (meta_key, meta_value), that query will be slow.

When to add an index and when to leave it alone

Adding an index speeds up reads but slows down writes. Every INSERT, UPDATE, or DELETE has to rebuild the affected indexes. For tables that change constantly—like wp_options with autoloaded data—a poorly chosen index can make things worse.

Add an index if:

• The slow query log shows repeated queries scanning tens of thousands of rows
• The table is read-heavy (e.g., custom post type archives, metadata lookups)
• The query filters or sorts on a column that isn’t indexed

Skip the index if:

• The table has fewer than 1,000 rows (the overhead isn’t worth it)
• The column has very low cardinality (e.g., a boolean field with only two values)
• Write performance matters more than read performance (e.g., logging tables)

To add a single-column index:

ALTER TABLE wp_postmeta ADD INDEX meta_value_idx (meta_value(191));

The (191) limits the indexed portion of the column to 191 characters, which keeps the index size manageable for utf8mb4 collation (MySQL CREATE INDEX documentation, checked October 2026).

For composite indexes matching a specific query pattern:

ALTER TABLE wp_postmeta ADD INDEX meta_key_value_idx (meta_key, meta_value(191));

The non-obvious tip: rebuild fragmented indexes quarterly

Even well-indexed tables degrade over time. If you run a membership site, a course platform, or any WordPress install with heavy comment or metadata churn, indexes become fragmented. MySQL has to read more disk blocks to traverse the index tree, and queries slow down even though the index exists.

Check fragmentation by running:

SHOW TABLE STATUS LIKE 'wp_postmeta';

Look at the Data_free column. If it’s more than 20% of Data_length, the table is fragmented. Rebuild it with:

OPTIMIZE TABLE wp_postmeta;

This locks the table briefly (usually seconds for tables under 1 GB), so run it during low-traffic windows. Set a calendar reminder to OPTIMIZE your largest tables every quarter. On a site with 50,000 posts and heavy metadata, this alone can cut query times in half.

Want more infrastructure deep-dives like this? Subscribe to One Two Three Send—every article is written for operators who want to understand the layer below the dashboard.

WordPress comment moderation is a black box until you dig into the settings. A first-time visitor leaves a thoughtful reply and it vanishes into the moderation queue. A known commenter posts a link and gets flagged as spam. The system uses a set of filtering rules—some visible, some buried—that decide whether a comment goes live, waits for approval, or gets junked.

Understanding how these filters work lets you tune moderation to match your traffic pattern. If you run a low-volume blog, you can loosen the gate. If you attract drive-by spam, you tighten it. The defaults are conservative, built for a web that doesn’t exist anymore.

The approval workflow: three possible destinations

Every comment WordPress receives lands in one of three places: approved and published immediately, held in the moderation queue, or sent to spam (or trash, if you use an external filter like Akismet). The path depends on a chain of checks that run in sequence.

First, WordPress checks whether the commenter has a previously approved comment using the same email address. If yes, and if the “Comment author must have a previously approved comment” box is checked under Settings → Discussion, the new comment publishes immediately. This is the fast lane for repeat commenters. If the box is unchecked, every comment waits for manual approval regardless of history.

Next, WordPress scans the comment body, author name, email, URL, and IP address against two lists: the moderation keyword list and the disallowed keyword list. The moderation list (labelled “Comment Moderation” in the dashboard) holds comments for review. The disallowed list (formerly called the blacklist, relabelled in WordPress 5.5) sends comments straight to spam. Both lists live under Settings → Discussion and accept one keyword or phrase per line.

Finally, WordPress counts links. By default, if a comment contains two or more links, it goes to moderation. You can change that threshold in the “Hold a comment in the queue if it contains [X] or more links” field. Set it to zero and every comment with any link gets held. Set it to ten and you let through link-heavy replies that are probably spam.

Keyword matching: case-insensitive and substring-aware

The keyword filters are simple but powerful. WordPress treats every entry as case-insensitive and matches substrings. If you add “casino” to the disallowed list, it will catch “casino,” “Casino,” and “online-casino-bonuses.” It will also catch “occasion” and “Casiano”—any string containing those letters in sequence.

This substring behaviour causes false positives. A moderation list that includes “free” will flag “freedom,” “freelance,” and “gluten-free.” You can work around this by adding spaces before and after the keyword (” free “), which narrows the match to whole words surrounded by whitespace. It’s not perfect—it won’t catch “free!” or “free.”—but it reduces collateral damage.

The moderation and disallowed lists work independently. A comment caught by the disallowed list never reaches the moderation queue; it skips straight to spam. A comment caught by the moderation list waits for manual review, even if the author has prior approved comments.

IP and email history: where external plugins step in

WordPress core doesn’t maintain a reputation database for IP addresses or email domains beyond the simple “previously approved” check. It doesn’t track how many times an IP has been flagged, or whether an email domain is a known spam source. For that, you need a plugin.

Akismet, bundled with most WordPress installs, sends every comment to its cloud service for scoring. It checks the comment content, author metadata, and submission context against a global spam database and returns a spam/not-spam verdict. Akismet’s accuracy is high, but it’s a third-party dependency with a commercial pricing tier (checked October 2026) for business sites. Free usage is limited to personal blogs.

Antispam Bee, a privacy-focused alternative, runs locally and uses pattern matching, honeypot fields, and country-based IP filtering. It doesn’t phone home, but it also doesn’t benefit from network-effect spam detection. Which tool fits depends on your privacy stance and comment volume.

When to adjust the defaults

If you’re launching a new site with zero comment history, uncheck “Comment author must have a previously approved comment.” Otherwise, every first-time commenter—including engaged readers—waits in the queue, and you create friction where you want conversation.

If your niche attracts keyword-heavy spam (crypto, pharma, affiliate), populate the disallowed list early. Start with obvious terms and expand as patterns emerge. But review the spam folder weekly; automated filters drift and catch legitimate comments over time.

If you cross-post to social media and drive external traffic, raise the link threshold to three or four. Readers who quote sources or share related articles shouldn’t wait for approval. If spam is minimal, you can disable link-count moderation entirely by leaving the field blank or setting it to a high number.

The comment system in WordPress hasn’t changed much in a decade, but the web around it has. Spam is more sophisticated, and legitimate commenters expect instant feedback. Tuning the moderation filters to match your traffic pattern is a small lever that improves the reader experience without adding workload.

Want more infrastructure walkthroughs like this? Subscribe to One Two Three Send—we break down the mechanics of online-business tools every week, no fluff.

WordPress auto-save is supposed to be invisible. You type, it saves, and you never think about it—until you refresh a draft and realise the last four paragraphs are gone.

The default auto-save interval is 60 seconds. That’s a full minute of typing that can vanish if your browser crashes, your session times out, or a plugin interferes with the AJAX request that writes the draft to the database.

Most solo operators don’t realise how often WordPress doesn’t save, or what conditions break the cycle. Here’s what actually happens, and how to adjust it if you’re losing work.

How WordPress auto-save works

WordPress fires an AJAX request to wp-admin/admin-ajax.php every 60 seconds while you’re editing a post or page. That request writes a revision to the wp_posts table with post_status = 'auto-draft'.

If the request succeeds, you’ll see a faint “Draft saved at [time]” notice near the top of the editor. If it fails—because your session expired, your network dropped, or a security plugin blocked the request—you’ll see nothing. WordPress assumes the save worked.

The problem: WordPress doesn’t retry failed auto-saves. If the AJAX call times out or returns a 403, the next save attempt happens 60 seconds later. Anything you typed in between is at risk.

This is especially common on shared hosting, where PHP execution time limits, memory caps, or aggressive WAF rules can silently kill the auto-save request. You’ll only notice when you reload the page or lose focus and see an older version of your draft.

When auto-save fails silently

Four scenarios break auto-save more often than operators expect:

• Multiple tabs editing the same post. WordPress locks posts to a single session, but if you open the same draft in two browser tabs, the second tab’s auto-save requests return 409 conflicts. The editor doesn’t warn you—it just stops saving.
• Session timeout during long edits. Default WordPress sessions expire after 48 hours, but hosting providers often override this to 2–12 hours. If your auth cookie expires mid-edit, auto-save returns 401 and stops. You’ll only notice when you hit Publish and get bounced to the login screen.
• Security plugins blocking AJAX. Wordfence, Sucuri, and iThemes Security all have rules that can block rapid-fire AJAX requests from the same IP. If you’re editing quickly, the plugin may flag auto-save as suspicious and return 403. Check your security log—most operators never look.
• Browser background-tab throttling. Chrome, Safari, and Edge all throttle JavaScript timers in background tabs to save battery. If you’re editing a post in one tab while reading documentation in another, the auto-save interval can stretch to 2–5 minutes instead of 60 seconds.

How to shorten the auto-save interval

WordPress lets you override the 60-second default with a single line in wp-config.php:

define( 'AUTOSAVE_INTERVAL', 30 );

That changes the interval to 30 seconds. You can set it as low as 10 seconds, but be aware: shorter intervals increase database writes and server load. If you’re on shared hosting with tight I/O limits, aggressive auto-save can slow down the editor or trigger rate-limit warnings from your host.

A better approach for most solo operators: leave the interval at 60 seconds, but add client-side protection with a browser extension like Textarea Cache (Chrome) or Lazarus (Firefox). These tools store form content in local browser storage every few seconds, independent of WordPress. If the page crashes or the session expires, you can recover the text from the extension’s cache.

What gets saved and what doesn’t

WordPress auto-save only writes the post title, content, and excerpt. It does not save:

• Custom field values (ACF, Pods, or manual meta fields)
• Featured image selections
• Category or tag assignments
• Gutenberg block settings (only the block HTML is saved, not inspector-panel metadata)

If you’re using a page builder like Elementor or Bricks, auto-save behaviour is entirely different—they maintain their own revision systems and save intervals. Check the plugin’s settings; most default to 60–120 seconds and store data in custom database tables, not wp_posts.

When to disable auto-save

Some operators disable auto-save entirely to reduce database bloat, especially on sites with hundreds of posts and thousands of revisions. You can turn it off with:

define( 'AUTOSAVE_INTERVAL', 86400 );

That sets the interval to 24 hours—effectively disabling it. But unless you’re manually saving every few minutes with Cmd+S or Ctrl+S, this is risky. A single browser crash can lose an hour of work.

A safer middle ground: leave auto-save enabled, but limit the number of revisions WordPress stores. Add this to wp-config.php:

define( 'WP_POST_REVISIONS', 5 );

That keeps only the five most recent revisions per post. It prevents database bloat without removing the safety net.

Reply and let us know: Have you ever lost a draft to a failed auto-save? What interval do you run, and have you adjusted it? Hit reply—we read every response.