MailHog solves this cleanly: it’s a local SMTP server that catches every outgoing email instead of delivering it, and gives you a web UI to inspect what WordPress actually sent — headers, body, attachments — without any of it leaving your machine.

Here’s how it’s set up on a Laravel Valet local WordPress install.

The Setup

MailHog was already available via Homebrew:

brew list | grep mailhog
ps aux | grep mailhog

It runs as a persistent background process — it survives Valet restarts, so there’s no per-session setup once it’s running.

Wiring WordPress to MailHog

WordPress sends mail through wp_mail(), which under the hood uses PHPMailer. Rather than touch PHP’s sendmail_path or reach for a full SMTP plugin, a small must-use plugin is enough to redirect PHPMailer at MailHog’s SMTP port:

<?php
/**
 * Plugin Name: MailHog SMTP Override
 * Description: Configures WordPress to send emails through MailHog SMTP (localhost:1025)
 * Version: 1.0
 */

if (!defined('ABSPATH')) {
    exit;
}

add_action('phpmailer_init', 'mailhog_configure_smtp');
function mailhog_configure_smtp($phpmailer) {
    $phpmailer->isSMTP();
    $phpmailer->Hostname = 'example.test';
    $phpmailer->Host = 'localhost';
    $phpmailer->Port = 1025;
    $phpmailer->SMTPSecure = false;
    $phpmailer->SMTPAutoTLS = false;
    $phpmailer->SMTPAuth = false;

    if (empty($phpmailer->From)) {
        $phpmailer->From = 'noreply@example.test';
    }
    if (empty($phpmailer->FromName)) {
        $phpmailer->FromName = 'Example Site';
    }
}

Save that as wp-content/mu-plugins/mailhog-smtp.php and it loads automatically — must-use plugins don’t need activating, and they can’t accidentally get deactivated mid-debug session either, which matters here since the whole point is that this stays on for every local request.

No authentication, no TLS — MailHog doesn’t need either since nothing actually leaves localhost.

Verifying It Works

wp eval-file /dev/stdin <<'PHP'
<?php
$to = 'test@example.com';
$subject = 'MailHog Test Email';
$message = 'This is a test email sent through MailHog SMTP';
$result = wp_mail($to, $subject, $message);
echo "Email sent: " . ($result ? "SUCCESS" : "FAILED") . "\n";
PHP

Then open http://localhost:8025 — the email shows up in the inbox immediately, with full headers and body, and it never touched test@example.com for real.

Day-to-Day Use

View emails: http://localhost:8025 — click any message for headers, body, and attachments.

Clear the inbox via the UI, or via the API:

curl -X DELETE http://localhost:8025/api/v1/messages

Check message count (useful in a script or CI-style check after a test run):

curl -s http://localhost:8025/api/v2/messages | jq '.total'

Multiple recipients and HTML email both work exactly as they would against a real SMTP server — MailHog doesn’t need special-casing for either:

wp_mail('user1@example.com, user2@example.com', 'Subject', 'Message');
wp_mail('test@example.com', 'HTML Email', '<h1>Hello</h1><p>This is HTML</p>');

If Emails Don’t Show Up

Work through these in order — in practice it’s almost always the first one:

1. Is MailHog actually running?

   ps aux | grep mailhog
   

2. Is something listening on 1025?

   lsof -i :1025
   

3. Manual SMTP smoke test:

   telnet localhost 1025
   

   Type HELO test, then QUIT — if that hangs or refuses, the problem is MailHog itself, not WordPress.

4. Check the WordPress debug log for a PHPMailer error the mu-plugin didn’t catch:

   tail -f wp-content/debug.log
   

If MailHog isn’t running at all, mailhog & starts it manually, or brew services start mailhog if it’s registered as a service. Port conflicts on 1025/8025 are the other common failure — lsof -i :1025 / lsof -i :8025 to find the PID, kill -9 it, then restart MailHog.

Alternatives

If a full SMTP plugin fits the project better than a bare mu-plugin, WP Mail SMTP points at the same MailHog port through its own settings screen (Mailer: Other SMTP, Host: localhost, Port: 1025, Encryption: None, Authentication: Off) — same destination, more UI for anyone who’d rather not touch PHP.

The one case a phpmailer_init hook can’t catch: code that bypasses wp_mail() entirely and calls PHP’s mail() directly. That needs sendmail_path overridden in php.ini instead, which is more invasive and worth avoiding unless something in your stack actually forces it.

Summary

• MailHog catches outgoing WordPress mail locally instead of delivering it — no risk of test runs emailing real people.
• A single phpmailer_init mu-plugin is enough to redirect wp_mail() at MailHog’s SMTP port; no plugin activation, no config file changes.
• The web UI (localhost:8025) and its REST API cover everything you need day to day: inspecting, clearing, and counting captured mail.
• Keep MailHog running as a background service so it survives Valet restarts and there’s nothing to remember to start.

This is the same kind of local-environment hygiene we set up as part of managed WordPress hosting work at Imagewize — getting a dev environment that behaves like production without any of the production risk. If you’re setting up a WordPress local dev workflow and want a hand, get in touch.

Find me on Mastodon at @jfrumau@mastodon.social if you’ve got a MailHog or local-mail setup worth comparing notes on.

Getting it working cleanly on a Roots Bedrock/Trellis stack took two separate fixes, not one.

The Encryption Key Problem

WP 2FA stores an encryption key for 2FA secrets in the wp_options table by default, under wp_2fa_secret_key. That’s fine for a stock WordPress install, but Bedrock keeps environment-specific config out of wp-config.php and out of the database — everything lives in .env and config/environments/{development,staging,production}.php, loaded via Roots\WPConfig\Config. A secret sitting in the database instead of environment config breaks that model, and WP 2FA actually warns you about it on its own settings page.

Dave at barrd.dev wrote up the fix for this back in 2023, and it’s still the right approach:

1. Deactivate the plugin.
2. Copy the key from wp_options (wp_2fa_secret_key, watch for a non-wp_ table prefix).
3. Move it into the environment config file instead:

// config/environments/production.php
use Roots\WPConfig\Config;

Config::define('WP2FA_ENCRYPT_KEY', 'your-encryption-key-here');

1. Delete the wp_2fa_secret_key row from the database.
2. Reactivate the plugin.

The one thing worth adding to that: give each environment its own key, not the same value copied into both files. Development and production are different databases with different 2FA-secret data, so there’s no reason to share a key between them — if anything, sharing weakens the isolation between environments for no benefit.

// config/environments/development.php
Config::define('WP2FA_ENCRYPT_KEY', 'a-different-key-for-dev');

// config/environments/production.php
Config::define('WP2FA_ENCRYPT_KEY', 'a-different-key-for-production');

Generate each with wp_generate_password(32, false) or openssl rand -base64 24 — anything sufficiently random works, since it’s only ever read by Config::define().

The Second Problem: A Fatal Bug barrd.dev Didn’t Hit

Once the encryption key was sorted, saving the plugin’s Policies tab threw a fatal error under WP_DEBUG in development (and silently no-op’d in production, which is worse — it just quietly doesn’t save).

The plugin’s Policies settings page has an option to generate a custom “user account” page for the 2FA setup wizard. If you never enable that option, custom-user-page-id stays an empty string. But the save handler calls wp_delete_post() unconditionally whenever certain settings change, without checking that a page ID actually exists:

// includes/classes/Admin/SettingsPages/class-settings-page-policies.php (WP 2FA 3.1.1.2)
\wp_delete_post( WP2FA::get_wp2fa_setting( 'custom-user-page-id' ), true );

wp_delete_post('') isn’t a no-op in every code path — it’s enough to throw a fatal type error under WP_DEBUG. This is a plugin bug, not something we control, so the fix has to live at the vendor-patch level rather than in our own code.

Patching a Composer-Installed Plugin

Bedrock installs plugins via Composer, so hand-editing the file in vendor//web/app/plugins/ doesn’t survive the next composer install. The standard way to patch a Composer dependency and have the patch reapply automatically is cweagans/composer-patches.

Add it as a dependency and allow it to run:

{
  "require": {
    "cweagans/composer-patches": "^1.7"
  },
  "config": {
    "allow-plugins": {
      "cweagans/composer-patches": true
    }
  },
  "extra": {
    "patches": {
      "wpackagist-plugin/wp-2fa": {
        "Fix wp_delete_post() fatal on Policies save when no custom user page exists": "patches/wp-2fa-fix-custom-user-page-delete.patch"
      }
    }
  }
}

Then the patch itself, guarding the delete with an actual ID check:

--- a/includes/classes/Admin/SettingsPages/class-settings-page-policies.php
+++ b/includes/classes/Admin/SettingsPages/class-settings-page-policies.php
@@ -419,7 +419,10 @@
 					$output['custom-user-page-id']         = '';
 					$output['separate-multisite-page-url'] = '';
 					$output['hide_page_generated_by']      = '';
-					\wp_delete_post( WP2FA::get_wp2fa_setting( 'custom-user-page-id' ), true );
+					$custom_user_page_id = (int) WP2FA::get_wp2fa_setting( 'custom-user-page-id' );
+					if ( $custom_user_page_id > 0 ) {
+						\wp_delete_post( $custom_user_page_id, true );
+					}
 				}
 			}

composer install (or composer update wpackagist-plugin/wp-2fa) applies it automatically from then on — no manual edits to vendor/ after every deploy, and the patch travels with the repo so every environment gets the same fix.

Why Bother With Both Fixes

It would’ve been easy to stop at “the plugin works, 2FA is enabled” and leave the Policies-tab bug alone since it only breaks a secondary settings page, not authentication itself. But a settings page that silently fails to save in production is exactly the kind of thing that causes a support ticket three months from now when someone tries to change a policy and can’t figure out why nothing sticks. Composer patches are cheap insurance for that — a few lines, applied automatically, documented in the repo instead of tribal knowledge.

Summary

• Bedrock/Trellis stacks need 2FA secrets moved out of the database and into config/environments/*.php, per environment — barrd.dev’s original write-up covers the mechanics.
• Give dev and production separate WP2FA_ENCRYPT_KEY values.
• If you hit a fatal error saving WP 2FA’s Policies tab, it’s a real bug in the plugin (wp_delete_post() called without checking the ID first) — patch it with cweagans/composer-patches rather than editing vendor/ by hand.

This is part of the hardening work we do as part of managed Trellis/Bedrock hosting at Imagewize — brute-force IP blocking, rate limiting, and now 2FA rollout. If you’re running a Bedrock/Trellis stack and want a hand with your security setup, get in touch.

Find me on Mastodon at @jfrumau@mastodon.social if you’ve hit other WP 2FA quirks on a Bedrock stack.

This post walks through exactly what database-pull.yml does, the safety feature hidden in the middle of it, and the two patches we made to get it working correctly with a Bedrock project.

What the Playbook Does

Running trellis db pull production executes database-pull.yml against your production host. Here’s the sequence:

1. Pre-flight validation

Before touching any database, the playbook checks three things:

- name: Abort if environment variable is equal to development
  fail:
    msg: "ERROR: development is not a valid environment for this mode..."
  when: env == "development"

You cannot pull from development to development — a useful guard if you ever mis-type the environment flag.

It also checks that your local project folder exists:

- name: Check if Jekyll::Drops::SiteDrop local folder exists
  delegate_to: localhost
  stat:
    path: ""
  register: result
  become: no

If the path doesn’t exist the playbook aborts with a clear message rather than partially running and leaving things in an inconsistent state.

2. Create local backup directory

- name: Create local database_backup directory if it doesn't exist
  delegate_to: localhost
  file:
    path: "/database_backup"
    state: directory
    mode: 0755
  become: no

On first run this creates a database_backup/ folder inside your local Bedrock project root. All backups end up here.

3. Dump and transfer the remote database

- name: Create database dump on 
  shell: wp db export --allow-root - | gzip > 
  args:
    chdir: ""

The dump is created on the remote server, piped through gzip. Then it’s fetched to local via Ansible’s fetch module:

- name: Pull database dump from  to development
  fetch:
    src: "/"
    dest: "/"
    flat: yes

After the transfer the remote dump is deleted immediately — no production files left hanging around on the server.

4. The hidden safety feature: backup local first

This is the part most developers don’t expect. Before importing the production dump, the playbook backs up your current local database:

- name: Export development database before importing dump (backup)
  delegate_to: localhost
  shell: wp db export - | gzip > database_backup/
  args:
    chdir: "/web/wp"
  become: no

The backup filename includes a timestamp:

imagewize_com_development_2026_02_27_10_30_45.sql.gz

So if the import causes any problems — or you realise after the fact that you needed that local data — you can restore it from database_backup/. Every pull creates a new timestamped backup, meaning you accumulate a history of your local database states. Worth clearing out periodically.

5. Import and search-replace

- name: Import database dump on development
  delegate_to: localhost
  shell: gzip -c -d  | wp db import -
  args:
    chdir: "/web/wp"
  become: no

Then the URL swap:

- name: Search for  and replace with  on development
  delegate_to: localhost
  command: wp search-replace '//' '//' --allow-root --all-tables --precise

Both url_from (production) and url_to (local) are resolved from config automatically. After this step your local WordPress is fully functional with production content.

What We Fixed

The version of database-pull.yml we started with had two problems.

Fix 1: Broken hostvars references

The original playbook resolved local site config like this:

host: "_host"
from_host: ""
url_from: ""
url_to: ""
local_bedrock_dir: ""

It was trying to read the development site config via hostvars.development_host, which required that host to be in the play’s host inventory. Since the playbook only targets web:& (the remote server), development_host wasn’t always populated at the right time. This caused intermittent failures that were hard to reproduce.

The fix was to load the development config directly using vars_files and a file lookup:

vars_files:
  - group_vars/development/wordpress_sites.yml

vars:
  url_from: ""
  dev_wordpress_sites: ""
  url_to: ""
  project_local_path: ""

Reading the file directly is more reliable than relying on hostvars being populated for a host that isn’t part of the current play.

Fix 2: Wrong delegate_to target

The original used delegate_to: development_host for local tasks:

- name: Create database_backup directory if it doesn't exist
  delegate_to: development_host
  file:
    path: "/database_backup"
    ...

Two problems here: development_host has the same availability issue as above, and the path was using project_web_dir (the remote path) instead of the local Bedrock path.

Replacing with delegate_to: localhost and correcting the path:

- name: Create local database_backup directory if it doesn't exist
  delegate_to: localhost
  file:
    path: "/database_backup"
    state: directory
    mode: 0755
  become: no

The become: no is also important — local tasks shouldn’t run as root.

Using It

Once the playbook is correct, pulling production to local is a single command run from the Trellis directory:

cd trellis
trellis db pull production

For a Bedrock project the WP path is in the web/wp subdirectory, which the playbook handles automatically via the chdir arguments.

If you want to run just the search-replace step again (useful if something went wrong):

trellis db pull production --tags search-replace

Takeaway

The Trellis database-pull playbook is well-designed, but the default version had brittle hostvars lookups that could fail depending on how hosts were configured. Switching to direct file lookups and delegate_to: localhost made it deterministic.

The built-in local backup before import is a genuinely useful safety net that’s easy to miss since it’s buried in the middle of the playbook. Your database_backup/ directory quietly accumulates timestamped snapshots of every pull — worth knowing about before you hit a situation where you need it.

This is part of the Trellis-based WordPress deployment workflow we use at Imagewize for client projects. If you’re running a Trellis stack and want help setting up or debugging your deployment pipeline, get in touch.

Questions or issues with your Trellis setup? Find me on Mastodon at @jfrumau@mastodon.social.

After building and maintaining 100+ e-commerce stores over 15 years, I’ve worked extensively with both platforms. In this guide, I’ll break down exactly when to choose each platform based on your business needs, budget, and technical comfort level.

Table of Contents

1. Quick Summary: Which Should You Choose?
2. Platform Fundamentals
3. Cost Comparison
4. Features & Functionality
5. Flexibility & Customization
6. Performance & Speed
7. SEO Capabilities
8. Ease of Use
9. Payment Processing
10. Support & Maintenance
11. Real-World Use Cases
12. Migration Between Platforms
13. Final Verdict

Quick Summary: Which Should You Choose?

Choose WooCommerce If:

• ✅ You want complete control over your store
• ✅ You have (or can hire) technical expertise
• ✅ You need extensive customization beyond templates
• ✅ You want to avoid monthly platform fees long-term
• ✅ You need unlimited products and no transaction fees
• ✅ You prefer one-time costs over recurring subscriptions
• ✅ You’re already comfortable with WordPress

Choose Shopify If:

• ✅ You want fast, easy setup without technical work
• ✅ You prefer all-in-one hosting and don’t want to manage servers
• ✅ You need 24/7 support from the platform
• ✅ You value simplicity over deep customization
• ✅ You’re okay with monthly fees in exchange for convenience
• ✅ You need quick time-to-market (launch in days, not weeks)

TLDR: Shopify is easier and faster to set up. WooCommerce is more flexible and cheaper long-term.

Platform Fundamentals

WooCommerce

• Type: WordPress plugin (self-hosted)
• First Released: 2011
• Market Share: ~39% of all e-commerce sites
• Model: Free, open-source plugin + paid extensions + hosting costs

How It Works:

1. Install WordPress
2. Install WooCommerce plugin (free)
3. Add products, payment gateways, shipping
4. Customize with themes and plugins

Shopify

• Type: Hosted SaaS platform
• First Released: 2006
• Market Share: ~28% of all e-commerce sites
• Model: Monthly subscription + transaction fees + app costs

How It Works:

1. Sign up for Shopify account
2. Choose a theme (free or paid)
3. Add products and configure settings
4. Launch (no hosting or technical setup needed)

Cost Comparison

WooCommerce True Costs (Year 1)

*Hosting costs vary wildly:

• Shared hosting: €100-€200/year (not recommended for WooCommerce)
• Managed WooCommerce: €300-€600/year (Kinsta, WP Engine)
• VPS with Trellis: €600-€1,200/year (best performance)

Shopify True Costs (Year 1)

Key Difference: WooCommerce has higher upfront costs but lower ongoing costs. Shopify has low setup costs but continuous monthly fees.

5-Year Cost Projection

Small Store (€50k/year revenue):

• WooCommerce: ~€2,500-€3,500 total
• Shopify (Basic): ~€2,100-€3,000 total

Medium Store (€250k/year revenue):

• WooCommerce: ~€3,500-€5,500 total
• Shopify (Shopify Plan): ~€5,200-€7,500 total

Large Store (€1M+/year revenue):

• WooCommerce: ~€6,000-€10,000 total
• Shopify (Advanced): ~€18,000-€25,000 total

Winner: WooCommerce becomes significantly cheaper at scale.

Features & Functionality

Core E-Commerce Features (Both Platforms)

Both WooCommerce and Shopify handle the essentials:

• ✅ Product management (simple, variable, digital, subscriptions)
• ✅ Inventory tracking
• ✅ Order management
• ✅ Customer accounts
• ✅ Discount codes and promotions
• ✅ Shipping calculations
• ✅ Tax calculations
• ✅ Analytics and reporting

Where WooCommerce Excels

1. Content Marketing Integration
   • Native WordPress blogging (best CMS for content)
   • Seamless content + commerce integration
   • Superior SEO-focused content tools
2. Product Flexibility
   • Unlimited product variations (Shopify limits to 100 per product)
   • Custom product types via plugins
   • Advanced product filtering
3. Membership & Subscriptions
   • Better native membership plugins (MemberPress, Restrict Content Pro)
   • More flexible subscription models
4. Payment Gateway Options
   • 100+ payment gateways available
   • No transaction fees regardless of gateway choice
   • Complete control over checkout process

Where Shopify Excels

1. Abandoned Cart Recovery
   • Built-in abandoned cart emails (WooCommerce requires paid plugin)
   • Better automation and segmentation
2. Multi-Channel Selling
   • Native Facebook Shop integration
   • Instagram Shopping built-in
   • Amazon and eBay integrations
   • Point-of-sale (POS) system for physical retail
3. Inventory Management
   • More sophisticated multi-location inventory
   • Better bulk editing tools
   • Automatic SKU generation
4. Mobile App
   • Native Shopify mobile app for managing orders on-the-go
   • Better mobile admin experience

Winner: Tie - depends on your specific needs.

Flexibility & Customization

WooCommerce Flexibility: 10/10

Complete Control:

• Access to all source code (it’s open-source)
• Modify any functionality via hooks and filters
• Create completely custom checkout flows
• Build unique product types
• Integrate with any third-party system

Example Custom Solutions We’ve Built:

• Multi-vendor marketplaces
• Custom quote request systems
• Complex B2B pricing rules
• Subscription boxes with customization options
• Integration with proprietary ERP systems

Reality Check: Customization requires developer expertise or hiring a developer.

Shopify Flexibility: 6/10

What You Can Customize:

• Theme design (via Liquid templating language)
• Add functionality via Shopify Apps
• Custom fields and metafields
• Some checkout customization (Shopify Plus only)

Limitations:

• No access to core platform code
• Checkout page heavily locked down (except Shopify Plus)
• Must work within Shopify’s app ecosystem
• Some integrations require Shopify Plus (expensive)

Reality Check: 90% of stores can work within Shopify’s limitations. But if you need something truly custom, you’ll hit walls.

Winner: WooCommerce (by a large margin).

Performance & Speed

WooCommerce Performance

Depends entirely on your hosting:

Shared Hosting (Bad):

• ❌ Slow (3-5+ second load times)
• ❌ Struggles with traffic spikes
• ❌ Limited resources

Managed WordPress Hosting (Good):

• ✅ Fast (1-2 second load times)
• ✅ Handle moderate traffic
• ✅ Server-level caching

Premium VPS with Trellis (Excellent):

• ✅ Sub-1 second load times possible
• ✅ Handle high traffic
• ✅ Complete performance control
• ✅ Micro-caching at Nginx level

At Imagewize, we achieve sub-1s load times on WooCommerce stores using Trellis stack (Nginx + PHP 8.3 + Redis + micro-caching).

Shopify Performance

Consistent & Reliable:

• ✅ Fast global CDN (content delivery network)
• ✅ Automatic image optimization
• ✅ No server management needed
• ✅ Handles traffic spikes automatically
• ✅ Average load time: 1.5-2.5 seconds

Limitations:

• Limited control over server-level optimization
• Can’t implement advanced caching strategies
• App bloat can slow down stores

Winner: Shopify for consistency and ease. WooCommerce for peak performance (if properly configured).

SEO Capabilities

WooCommerce SEO: 10/10

Built on WordPress (the best SEO platform):

• ✅ Complete control over URLs, meta tags, schema markup
• ✅ Superior blogging capabilities (content is king for SEO)
• ✅ Best SEO plugins: Yoast, Rank Math, The SEO Framework
• ✅ Full control over site structure and internal linking
• ✅ Better pagination and filtering options
• ✅ Can optimize every element for speed (major ranking factor)

SEO Advantages:

• Create category hierarchies and breadcrumbs exactly how you want
• Unlimited blog posts integrated with products
• Complete schema markup control
• Better handling of product variations for SEO

Shopify SEO: 7/10

Good, But Limitations:

• ✅ Clean URL structure
• ✅ Built-in SSL
• ✅ Fast load times (CDN)
• ✅ Mobile-responsive themes
• ❌ Limited blogging features (basic at best)
• ❌ Forced /products/ and /collections/ URLs
• ❌ Can’t fully customize URL structure
• ❌ Limited schema markup customization

Shopify SEO Challenges:

• Duplicate content issues (product/collection pages)
• Less control over meta tags
• Blogging is weak compared to WordPress
• Can’t remove /collections/ from URLs without apps

Winner: WooCommerce (significantly better for content-driven SEO).

Ease of Use

Shopify: 9/10

Setup Time: 1-2 days to launch a basic store

Pros:

• ✅ Incredibly intuitive interface
• ✅ Step-by-step onboarding
• ✅ No technical knowledge required
• ✅ Everything in one dashboard
• ✅ Automatic updates (no maintenance)

Cons:

• ❌ Feels limited once you outgrow basics
• ❌ App bloat can make things confusing

WooCommerce: 6/10

Setup Time: 1-2 weeks to launch properly (or hire a developer)

Pros:

• ✅ WordPress familiarity (if you know WordPress)
• ✅ Extensive documentation and tutorials
• ✅ Huge community for support

Cons:

• ❌ Steeper learning curve
• ❌ More moving parts (hosting, security, updates)
• ❌ Requires ongoing maintenance
• ❌ Can be overwhelming for beginners

Winner: Shopify (much easier, especially for non-technical users).

Payment Processing

WooCommerce

Payment Gateways:

• 100+ gateway options (Stripe, PayPal, Square, Mollie, etc.)
• Zero transaction fees (just gateway fees: ~1.5-3%)
• Complete checkout customization
• Can integrate any payment system

Best Practice: Use Stripe (1.5% + €0.25 per transaction in Europe)

Shopify

Shopify Payments (Recommended):

• 1.6-1.9% per transaction (varies by plan)
• No additional Shopify transaction fee
• Built-in, seamless

Third-Party Gateways (PayPal, Stripe, etc.):

• 1.5-3% gateway fee
• + 0.5-2% Shopify transaction fee (this hurts!)

Real Cost Example (€10,000/month sales):

• WooCommerce + Stripe: €150-€300 fees
• Shopify Basic + PayPal: €200-€500 fees (gateway + Shopify fees)
• Shopify + Shopify Payments: €160-€190 fees

Winner: WooCommerce (no platform transaction fees = lower costs).

Support & Maintenance

Shopify Support

Official Support:

• ✅ 24/7 live chat, email, phone support
• ✅ Extensive documentation
• ✅ Active community forums
• ✅ Shopify handles all technical issues (hosting, security, uptime)

Maintenance:

• ✅ Automatic platform updates
• ✅ Automatic security patches
• ✅ Zero server maintenance

WooCommerce Support

Official Support:

• ❌ No official phone/chat support (it’s free, open-source)
• ✅ Extensive documentation
• ✅ Huge community (forums, Facebook groups, Stack Overflow)

Maintenance:

• ❌ Manual WordPress, plugin, and theme updates
• ❌ Responsible for site security
• ❌ Hosting maintenance (backups, server updates)

Solution: Hire a WordPress maintenance service (€100-€300/month)

Winner: Shopify (hands-down better support and zero maintenance).

Real-World Use Cases

When We Recommend WooCommerce

1. Content-Heavy Stores

• Businesses that blog regularly for SEO
• Example: Organic skincare brand with 100+ educational blog posts

2. Complex Product Catalogs

• Stores with 100+ product variations per item
• Example: Custom furniture store with 20+ wood types × 15+ finishes

3. B2B E-Commerce

• Wholesale pricing, quote requests, custom pricing rules
• Example: Industrial equipment supplier with tiered pricing

4. Custom Integrations

• Need to connect to proprietary ERP/CRM systems
• Example: Manufacturing company syncing inventory with production system

5. Long-Term Cost Savings

• High-volume stores (€500k+/year) wanting to minimize fees
• Example: Fashion retailer processing 10,000+ orders/year

When We Recommend Shopify

1. Quick Market Testing

• Need to launch fast and test product-market fit
• Example: Dropshipping business testing new niches

2. Multi-Channel Selling

• Selling on Instagram, Facebook, Amazon simultaneously
• Example: Fashion brand selling everywhere their audience is

3. Physical + Online Retail

• Need point-of-sale (POS) integration
• Example: Boutique with both physical store and online shop

4. Non-Technical Founders

• Don’t want to deal with technical details
• Example: Artist selling prints who wants to focus on creating, not tech

5. Subscription Boxes (Simple)

• Straightforward recurring billing
• Example: Monthly snack box subscription

Migration Between Platforms

Shopify → WooCommerce

Difficulty: Moderate

What Transfers:

• ✅ Products (title, description, images, variants)
• ✅ Customers (name, email, address)
• ✅ Orders (historical data)

What Doesn’t:

• ❌ Theme design (need to rebuild)
• ❌ App functionality (need to find WooCommerce equivalents)
• ❌ URL structure (will need redirects for SEO)

Tools:

• Cart2Cart migration service (€69-€199)
• LitExtension migration tool
• Manual CSV export/import

Timeframe: 2-4 weeks for full migration

WooCommerce → Shopify

Difficulty: Easy

What Transfers:

• ✅ Products
• ✅ Customers
• ✅ Orders

What Doesn’t:

• ❌ Custom functionality (will need to find Shopify apps)
• ❌ Blog posts (need manual migration)
• ❌ Custom checkout (Shopify checkout is locked)

Tools:

• Shopify’s built-in WooCommerce importer
• Cart2Cart

Timeframe: 1-2 weeks

Final Verdict

There’s no universal “better” platform. The right choice depends on your specific situation:

Choose WooCommerce If:

• You want maximum flexibility and control
• You have (or can hire) technical expertise
• You plan to scale to high volume (cost savings at scale)
• Content marketing and SEO are critical
• You need deep customization
• You prefer ownership over convenience

Best For: Growing businesses, content-driven brands, B2B, complex catalogs

Get Started: Imagewize WooCommerce development (custom WooCommerce stores from €999)

Choose Shopify If:

• You want fast, easy setup with minimal technical work
• You value convenience and 24/7 support
• You’re selling on multiple channels (Instagram, Facebook, etc.)
• You have a physical store and need POS integration
• You don’t want to manage hosting/security/updates
• You’re okay with higher ongoing costs for simplicity

Best For: Quick launches, dropshipping, multi-channel retailers, non-technical founders

Get Started: Imagewize Shopify services (Shopify store setup and optimization from €999)

Hybrid Approach (Advanced)

Some businesses use both platforms:

• WordPress/WooCommerce for main website + blog (SEO)
• Shopify for e-commerce transactions (ease of use)

This works via:

• Buy Button integration (embed Shopify checkout on WordPress)
• Headless commerce (WordPress frontend + Shopify backend)

Complexity: High, but offers best of both worlds.

Need Help Deciding?

Choosing the right e-commerce platform is a big decision. At Imagewize, we build stores on both WooCommerce and Shopify and can help you make the right choice for your business.

Our E-Commerce Services:

WooCommerce Development:

• Custom WooCommerce store setup (from €999)
• Speed optimization for WooCommerce
• Custom checkout flows and product types
• WooCommerce maintenance (from €100/month)

Shopify Development:

• Shopify store setup and theme customization (from €999)
• App integrations and custom functionality
• Shopify speed optimization
• Migration from other platforms

Contact us for a free consultation - we’ll analyze your needs and recommend the best platform for your business.

Conclusion

WooCommerce = Flexibility, control, lower long-term costs, better SEO (but requires technical work)

Shopify = Simplicity, speed, excellent support, multi-channel selling (but higher ongoing costs)

For most SMEs serious about scaling and content marketing, WooCommerce is the better long-term choice. But if you need to launch quickly without technical help, Shopify is hard to beat.

Still unsure? Talk to our team - we’ll help you choose.

About the Author: Jasper Frumau is the founder of Imagewize, a WordPress and Shopify development agency specializing in e-commerce for SMEs. With 15+ years of experience building 100+ online stores, he helps businesses choose and implement the right e-commerce platform.

After optimizing 100+ WordPress sites for SMEs over the past 15 years, I’ve identified the exact techniques that make the biggest impact on page load times. This guide shares the proven strategies we use at Imagewize to consistently achieve sub-1 second load times.

Table of Contents

1. Why WordPress Speed Matters
2. Core Web Vitals: The Metrics That Matter
3. The 10 Most Impactful Speed Optimizations
4. Advanced Speed Optimizations (Expert Level)
5. Real-World Results
6. Tools for Measuring Speed
7. Need Professional Help?
8. Conclusion

Why WordPress Speed Matters

Before diving into the technical optimizations, let’s understand why speed is critical for your business:

Business Impact

• 40% of visitors abandon sites that take more than 3 seconds to load
• 1-second delay = 7% reduction in conversions
• Google uses speed as a ranking factor (Core Web Vitals)
• Faster sites = better user experience = more engaged visitors

SEO Impact

Since Google’s Page Experience Update, Core Web Vitals are now part of search rankings. A slow site directly impacts your visibility in search results.

Core Web Vitals: The Metrics That Matter

Google measures three key performance metrics:

1. Largest Contentful Paint (LCP)

Target: < 2.5 seconds

LCP measures how long it takes for the main content to load. This is typically your hero image or largest text block.

Common issue: Lazy-loading your hero image causes 2+ second delays.

2. Cumulative Layout Shift (CLS)

Target: < 0.1

CLS measures visual stability. Text shouldn’t shift around while the page loads.

Common issue: Fonts loading late causes text to reflow and shift layout.

3. First Input Delay (FID) / Interaction to Next Paint (INP)

Target: < 100ms (FID) / < 200ms (INP)

Measures how quickly your site responds to user interactions.

Common issue: Large JavaScript bundles block the main thread.

The 10 Most Impactful Speed Optimizations

Based on real-world implementations from our client projects, here are the optimizations that deliver the biggest improvements:

1. Eager Load Your LCP Image ⚡ Impact: ~2.3 seconds saved

The Problem: By default, browsers lazy-load all images. If your hero image is the Largest Contentful Paint (LCP), lazy-loading adds massive delay.

The Solution:

<!-- Add to your hero image -->
<img src="hero.jpg"
     loading="eager"
     fetchpriority="high"
     alt="Your hero image">

Real Result: We reduced LCP from 3.8s to 1.4s on a client site just by adding these two attributes.

Reference: Nynaeve CHANGELOG v2.0.17

2. Preload Critical Fonts ⚡ Impact: CLS from 0.602 → < 0.1

The Problem: When custom fonts load late, text renders in fallback fonts first, then “jumps” when the real font loads. This creates layout shift.

The Solution:

<!-- Add to <head> before any CSS -->
<link rel="preload"
      href="/fonts/open-sans-regular.woff2"
      as="font"
      type="font/woff2"
      crossorigin>
<link rel="preload"
      href="/fonts/open-sans-semibold.woff2"
      as="font"
      type="font/woff2"
      crossorigin>

Why It Works: Fonts start downloading immediately, before CSS is parsed. Text renders with correct fonts from the start = zero layout shift.

Reference: Nynaeve CHANGELOG v2.0.17

3. Async-Load Non-Critical CSS ⚡ Impact: ~300-400ms render-blocking reduction

The Problem: CSS files block rendering. The browser won’t display anything until all CSS is downloaded and parsed.

The Solution: Make non-critical CSS non-render-blocking using the media='print' onload technique:

// WordPress filter to async-load CSS
add_filter('style_loader_tag', function($html, $handle) {
    // List of non-critical CSS handles
    $async_styles = [
        'wp-block-library',        // WordPress core blocks
        'woocommerce-layout',      // WooCommerce styles
        'woocommerce-general',
        'slick-carousel'           // Third-party libraries
    ];

    if (in_array($handle, $async_styles)) {
        // Change media to 'print' then swap to 'all' on load
        $html = str_replace("media='all'", "media='print' onload=\"this.media='all'\"", $html);
    }

    return $html;
}, 10, 2);

Real Result: Reduced render-blocking time from 1.2s to 0.8s by async-loading 15+ stylesheet files.

Reference: Nynaeve CHANGELOG v2.0.16

⚠️ Warning: Never async-load stylesheets with specific media queries (like max-width: 768px). It breaks responsive behavior.

4. Serve Responsive Images ⚡ Impact: ~50-70 KiB per image saved

The Problem: Serving full-resolution images to mobile devices wastes bandwidth and slows load times.

The Solution: Use WordPress’s built-in responsive image system with srcset:

// Register custom image sizes for different viewports
add_action('after_setup_theme', function() {
    add_image_size('hero-desktop', 600, 348, true);      // 1x
    add_image_size('hero-desktop-2x', 1200, 696, true);  // 2x retina
    add_image_size('hero-mobile', 400, 232, true);       // Mobile
});

// Use wp_get_attachment_image() for automatic srcset
echo wp_get_attachment_image($image_id, 'hero-desktop', false, [
    'loading' => 'eager',
    'fetchpriority' => 'high'
]);

Real Result: Hero image size dropped from 69.8 KiB to 19.4 KiB on mobile devices.

Reference: Nynaeve CHANGELOG v2.0.15

5. Optimize Image Formats ⚡ Impact: 60-80% file size reduction

The Problem: JPEGs and PNGs are outdated formats. WebP and AVIF offer far better compression.

The Solution:

• Use WebP for all photos (supported in all modern browsers)
• Use AVIF for even better compression (when supported)
• Lazy-load below-the-fold images (but NEVER your hero image!)

<img src="image.webp"
     loading="lazy"
     alt="Product photo">

Tools:

• ImageMagick for command-line conversions
• ShortPixel or Imagify WordPress plugins for automatic conversion
• Cloudflare for automatic format delivery

6. Use a Modern WordPress Stack ⚡ Impact: ~40% faster server response

The Problem: Traditional shared hosting with Apache and no object caching is slow. Each page request hits the database multiple times.

The Solution: Use a modern WordPress stack like Trellis (what we use at Imagewize):

Stack Components:

• Nginx instead of Apache (faster static file serving)
• PHP 8.3+ with OPcache (compiled PHP code, not interpreted)
• Redis or Memcached for object caching (reduces database queries)
• HTTP/2 for multiplexed connections
• Micro-caching at Nginx level (serves cached HTML for 1-5 seconds)

Real Result: Time to First Byte (TTFB) dropped from 800ms to 200ms on a WooCommerce site.

Learn More: Imagewize Premium Hosting offers Trellis-based VPS hosting starting at €79/month.

7. Minimize Plugin Bloat ⚡ Impact: Varies (can save 500ms+)

The Problem: Every plugin adds CSS, JavaScript, and database queries. More plugins = slower site.

The Solution:

• Audit your plugins - Remove anything you’re not actively using
• Combine functionality - Find plugins that do multiple things instead of single-purpose ones
• Disable plugin assets on pages where they’re not needed using Asset CleanUp or Perfmatters

Example: If you only use a contact form on /contact/, disable that plugin’s CSS/JS on all other pages.

8. Defer Non-Critical JavaScript ⚡ Impact: ~200-500ms saved

The Problem: JavaScript blocks HTML parsing. The browser can’t render content until JS is downloaded and executed.

The Solution:

<!-- Defer scripts that don't need to run immediately -->
<script src="analytics.js" defer></script>
<script src="tracking.js" defer></script>

<!-- Async for scripts that can run independently -->
<script src="ads.js" async></script>

WordPress Implementation:

add_filter('script_loader_tag', function($tag, $handle) {
    $defer_scripts = ['google-analytics', 'facebook-pixel'];

    if (in_array($handle, $defer_scripts)) {
        return str_replace(' src', ' defer src', $tag);
    }

    return $tag;
}, 10, 2);

9. Enable Gzip/Brotli Compression ⚡ Impact: 70-90% file size reduction

The Problem: Transferring uncompressed HTML, CSS, and JavaScript wastes bandwidth and time.

The Solution: Enable server-side compression in your .htaccess (Apache) or Nginx config:

Nginx (Trellis):

# Gzip compression
gzip on;
gzip_vary on;
gzip_comp_level 6;
gzip_types text/plain text/css text/xml text/javascript
           application/json application/javascript application/xml+rss;

# Brotli compression (even better than gzip)
brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css text/xml text/javascript
             application/json application/javascript;

Result: A 200 KiB HTML page compresses to ~30 KiB with Brotli.

10. Use a CDN ⚡ Impact: ~100-300ms faster global delivery

The Problem: Serving assets from a single server in one location means slow delivery to distant visitors.

The Solution: Use a Content Delivery Network (CDN) to serve static assets (images, CSS, JS) from servers close to your visitors:

Recommended CDNs:

• Cloudflare (free tier available, easy setup)
• Bunny CDN (cheap, fast, privacy-focused)
• KeyCDN (WordPress integration)

Cloudflare Bonus: Also provides automatic image optimization, WebP conversion, and DDoS protection.

Advanced Speed Optimizations (Expert Level)

The following optimizations require server access and technical expertise. If you’re on shared hosting, you won’t be able to implement these—but they’re worth knowing about for when you upgrade.

11. Enable Redis Object Cache ⚡ Impact: 30-50% faster admin, 20% fewer DB queries

The Problem: WordPress queries the database constantly, loading the same data repeatedly. Autoloaded options (like settings) are fetched on every single page load.

The Solution: Redis caches database query results in memory, dramatically reducing database load:

// WordPress makes this query on EVERY page load
SELECT option_value FROM wp_options WHERE autoload='yes'

// Without Redis: Hits database every time
// With Redis: Cached in memory after first query

Implementation (Trellis/Modern Hosting):

# trellis/group_vars/production/wordpress_sites.yml
wordpress_sites:
  example.com:
    cache:
      enabled: true
      driver: redis

Verification:

wp redis status
# Expected: Connected to Redis via PhpRedis (v6.x)

Real Impact on imagewize.com:

• Admin panel 40% faster
• Database queries reduced from 45 to 28 per page
• Autoloaded options (250KB) cached instead of queried

Note: This requires Redis server installed. Most managed WordPress hosts don’t offer this—you need VPS or dedicated hosting.

12. Optimize PHP-FPM Worker Pool ⚡ Impact: Prevents site crashes under traffic

The Problem: PHP-FPM has a limited number of “workers” (processes that handle requests). If all workers are busy when a new request arrives, the request fails with a “critical error.”

How Many Workers Do You Need?

Available RAM: 4GB
Safe worker memory: ~150MB each
Safe worker count: 4000MB / 150MB = ~26 workers

With memory accumulation:
After 100 requests: ~200MB each
Safe worker count: 4000MB / 200MB = 20 workers

The Solution: Configure PHP-FPM dynamically with aggressive worker recycling:

pm = dynamic                  # Spawn workers as needed
pm.max_children = 30          # Never more than 30 workers
pm.start_servers = 10         # Start with 10 ready
pm.min_spare_servers = 8      # Always keep 8 idle
pm.max_spare_servers = 15     # Kill extras above 15
pm.max_requests = 100         # Recycle after 100 requests

Why Recycle Workers? PHP workers don’t release memory between requests—they accumulate it:

Request 1:   150 MB
Request 50:  250 MB
Request 100: 350 MB
Request 200: 500 MB  ← Danger! Kill and respawn

Real Result: On imagewize.com, reducing pm.max_requests from 500 → 100 prevented workers from ballooning to 800MB+ and causing OOM errors.

13. Clean Up WordPress Autoloaded Options ⚡ Impact: 58% reduction in database load

The Problem: WordPress has a feature called “autoload” that loads certain database options on EVERY page load. Over time, deactivated plugins leave behind bloated autoload data that wastes memory.

Check Your Autoload Size:

wp db query "SELECT
  COUNT(*) as count,
  ROUND(SUM(LENGTH(option_value))/1024) as size_kb
FROM wp_options
WHERE autoload='yes';"

Healthy Site:

• Options count: < 800
• Total size: < 300 KB

Our Cleanup Results (imagewize.com - Nov 2025):

• Before: 844 options, 608 KB total
• After: 842 options, 251 KB total (58.7% reduction!)

What We Deleted:

# Old WPML installer tracking (228 KB!)
wp option delete wprc_info_extension

# Old installer settings (138 KB)
wp option delete wp_installer_settings

# Bloated directory size cache (294 KB)
wp option delete _transient_dirsize_cache

Impact: 357 KB freed = faster page loads, lower memory usage, faster deployments.

Find Your Bloated Options:

wp db query "SELECT option_name, LENGTH(option_value) as size_bytes
FROM wp_options
WHERE autoload='yes'
ORDER BY size_bytes DESC
LIMIT 10;"

Look for options from plugins you no longer use—they’re safe to delete.

14. Block XMLRPC Attacks ⚡ Impact: Prevents memory exhaustion from bots

The Problem: WordPress’s xmlrpc.php is a legacy API endpoint that’s rarely needed but constantly attacked by bots. Even when the endpoint returns an error, WordPress still:

1. Loads the entire WordPress core
2. Bootstraps all plugins
3. Allocates 150-300MB of memory
4. Then returns 404/403

The Attack Pattern:

103.42.58.162 - POST /xmlrpc.php (500 error)
103.42.58.162 - POST /xmlrpc.php (500 error)
103.42.58.162 - POST /xmlrpc.php (500 error)
... 100+ requests in 10 minutes

Result: All PHP-FPM workers exhausted, site crashes.

The Solution: Block xmlrpc.php at the Nginx level (before PHP is involved):

location ~* xmlrpc\.php$ {
  return 444;  # Drop connection immediately
}

For Trellis Users:

# trellis/group_vars/production/wordpress_sites.yml
wordpress_sites:
  example.com:
    xmlrpc:
      enabled: false    # Blocks at Nginx level

Verification:

curl -v --max-time 5 https://yoursite.com/xmlrpc.php
# Should timeout/hang (connection dropped)

Real Impact: After blocking xmlrpc.php on imagewize.com, memory spikes stopped completely. Zero PHP involvement = zero memory waste.

15. Tune PHP Memory Limits Correctly ⚡ Impact: Prevents crashes

The Problem: WordPress has three separate memory limits—and they all need to be set correctly:

The Trap: Even if PHP allows 512MB, WordPress will cap itself at WP_MEMORY_LIMIT (40MB by default). With WooCommerce + modern themes, this causes “allowed memory size exhausted” errors.

The Fix: Add to wp-config.php (or Bedrock’s config/application.php):

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Verify It Worked:

wp eval 'echo "WP_MEMORY_LIMIT: " . WP_MEMORY_LIMIT . "\n";'
wp eval 'echo "WP_MAX_MEMORY_LIMIT: " . WP_MAX_MEMORY_LIMIT . "\n";'

Real Impact: On imagewize.com, we were hitting the 40M limit constantly with WooCommerce + Acorn/Laravel. Increasing to 256M eliminated all memory errors.

Real-World Results

Here’s what these optimizations achieved on actual client sites:

Case Study: E-commerce Store (WooCommerce)

Before:

• LCP: 3.8 seconds
• CLS: 0.602
• Total Load Time: 4.2 seconds

After (10 optimizations):

• LCP: 1.4 seconds (↓ 63%)
• CLS: 0.08 (↓ 87%)
• Total Load Time: 1.1 seconds (↓ 74%)

Business Impact:

• +12% increase in conversion rate
• +23% increase in pages per session
• -18% bounce rate

Case Study: SME Corporate Site

Before:

• LCP: 4.1 seconds
• PageSpeed Score: 42/100

After:

• LCP: 1.2 seconds (↓ 71%)
• PageSpeed Score: 94/100

SEO Impact: Organic traffic increased 34% within 3 months.

Tools for Measuring Speed

Use these tools to benchmark your site and track improvements:

Essential Tools

1. Google PageSpeed Insights - Official Core Web Vitals scores
2. GTmetrix - Detailed performance analysis
3. WebPageTest - Advanced waterfall analysis
4. Chrome DevTools - Lighthouse audits and performance profiling

Monitoring

• Google Search Console - Real Core Web Vitals data from actual users
• Cloudflare Analytics - Global performance metrics
• New Relic / Datadog - APM for production monitoring

Need Professional Help?

While this guide covers proven optimization techniques, implementing them correctly on your specific setup can be complex. At Imagewize, we specialize in WordPress speed optimization for SMEs.

Our Speed Optimization Service Includes:

• Complete performance audit - Identify all bottlenecks
• Hands-on optimization - Implement all 10+ techniques
• Before/after testing - Prove the results
• Ongoing monitoring - Ensure speeds stay fast

Starting at €349 - Get a free speed audit

We also offer Premium Trellis Hosting (€79/month) with all speed optimizations built-in:

• Nginx + PHP 8.3 + Redis
• Micro-caching at server level
• HTTP/2 and Brotli compression
• Automatic backups and security hardening
• Sub-1s load times guaranteed

Conclusion

WordPress speed optimization isn’t magic—it’s about implementing proven techniques systematically:

Essential Optimizations (Anyone Can Do)

1. ✅ Eager-load your LCP image
2. ✅ Preload critical fonts
3. ✅ Async-load non-critical CSS
4. ✅ Serve responsive images
5. ✅ Use modern image formats (WebP/AVIF)
6. ✅ Minimize plugin bloat
7. ✅ Defer non-critical JavaScript
8. ✅ Enable Gzip/Brotli compression
9. ✅ Use a CDN

Advanced Optimizations (VPS/Dedicated Hosting)

1. ✅ Upgrade to modern hosting stack (Nginx + PHP 8.3 + Redis)
2. ✅ Enable Redis object cache
3. ✅ Optimize PHP-FPM worker pool
4. ✅ Clean up WordPress autoloaded options
5. ✅ Block XMLRPC attacks
6. ✅ Tune PHP memory limits correctly

Each optimization compounds. Together, they can reduce load times by 70%+ and dramatically improve your Core Web Vitals scores.

The difference between items 1-9 and 10-15? Items 1-9 you can implement on any hosting. Items 10-15 require server-level access—but they’re the optimizations that separate fast sites from blazing fast sites.

Want to see how fast your site can be? Contact Imagewize for a free speed audit.

About the Author: Jasper Frumau is the founder of Imagewize, a WordPress development agency specializing in speed optimization for SMEs. With 15+ years of WordPress experience, he’s optimized 100+ sites to achieve sub-1 second load times.

The Scenario

During an extensive PHP-FPM memory debugging session, I was trying to suppress some harmless WooCommerce database warnings. These warnings occur when WooCommerce tries to add database indexes that already exist:

WordPress database error Duplicate key name 'session_expiry'

The warnings cluttered the debug log but were harmless - WooCommerce handles them gracefully.

The Broken Code

I added this filter to setup.php:

add_filter('query', function ($query) {
    global $wpdb;

    if (
        strpos($query, 'ADD KEY `session_expiry`') !== false ||
        strpos($query, 'ADD INDEX woo_idx_comment_date_type') !== false
    ) {
        // Suppress errors and execute the query ourselves
        $suppress_errors = $wpdb->suppress_errors();
        $wpdb->suppress_errors(true);

        $result = $wpdb->query($query);  // ← THE BUG

        $wpdb->suppress_errors($suppress_errors);

        return '';  // Prevent original query from running
    }

    return $query;
}, 1);

Can you spot the bug?

The Problem: Recursive Filter Trigger

The query filter runs on every database query WordPress makes. When you call $wpdb->query() inside the query filter, it triggers the same filter again:

1. WordPress runs ALTER TABLE query
2. 'query' filter intercepts it
3. Filter calls $wpdb->query($query)
4. $wpdb->query() triggers 'query' filter
5. Filter intercepts the same query again
6. Filter calls $wpdb->query($query)
7. ... infinite loop ...
8. PHP crashes: "Maximum call stack size reached"

The error message was:

PHP Fatal error: Uncaught Error: Maximum call stack size of 8339456 bytes
(zend.max_allowed_stack_size - zend.reserved_stack_size) reached.
Infinite recursion? in /wp-includes/class-wpdb.php:2412

Why It Took 4 Weeks to Crash

Here’s the scary part: this code was deployed on October 27, 2025. The site ran fine for almost a month before crashing on November 24.

Why? The bug only triggers under specific conditions:

1. WooCommerce must run an ALTER TABLE ... ADD KEY query
2. These queries don’t run on every page load
3. They typically run during:
   • WooCommerce database updates
   • Session table maintenance
   • Certain admin operations
   • Plugin updates that trigger dbDelta

For 4 weeks, those specific queries never ran. Then something triggered them (possibly a cron job, admin action, or WooCommerce maintenance task), and the site immediately crashed.

Why I Missed It During Code Review

I reviewed this code when I wrote it. Here’s why I missed the bug:

1. Context blindness: I was focused on suppressing errors, not recursion
2. The logic looked correct: Intercept query → execute with suppressed errors → return empty
3. No immediate failure: The bug doesn’t manifest until those specific queries run
4. Fatigue: After hours of debugging other issues, attention to detail drops

The Fix

The solution is embarrassingly simple. We don’t need to execute the query at all - just skip it:

add_filter('query', function ($query) {
    if (
        strpos($query, 'ADD KEY `session_expiry`') !== false ||
        strpos($query, 'ADD INDEX woo_idx_comment_date_type') !== false
    ) {
        // Just skip this query entirely
        // WooCommerce handles missing indexes gracefully
        return '';
    }

    return $query;
}, 1);

WooCommerce doesn’t actually need these ADD KEY queries to succeed. The indexes either exist (query fails harmlessly) or don’t exist (WooCommerce works fine without them). By returning an empty string, we simply skip the query.

The Rule

Never call $wpdb->query(), $wpdb->get_results(), or any database method inside the query filter.

If you need to run a different query inside the filter, you must:

1. Remove the filter first
2. Run your query
3. Re-add the filter

add_filter('query', function ($query) use (&$my_filter_callback) {
    if (needs_modification($query)) {
        // Remove ourselves to prevent recursion
        remove_filter('query', $my_filter_callback, 1);

        // Now safe to query
        $result = $wpdb->query($modified_query);

        // Re-add ourselves
        add_filter('query', $my_filter_callback, 1);

        return '';
    }
    return $query;
}, 1);

But honestly, if you find yourself doing this, there’s probably a better approach.

Other Dangerous Filter Combinations

This pattern can bite you with other WordPress filters too:

Lessons Learned

1. The query filter is powerful but dangerous - it intercepts ALL database queries
2. Never call the function that triggers a filter from inside that filter
3. Simple solutions are usually better - returning empty string was safer than trying to execute with error suppression
4. Code review fatigue is real - after hours of debugging, take a break before adding new code
5. Test edge cases - the bug only triggered on specific queries that don’t run often

Debugging Tip

If you see “Maximum call stack size reached” or “Infinite recursion?” in PHP 8.2+, check your filters. Look for:

• Filters that call functions which trigger the same filter
• Recursive action hooks (save_post calling wp_update_post)
• Circular dependencies between filters

The stack trace usually shows the same function appearing multiple times - that’s your recursion.

Conclusion

I spent a weekend debugging PHP-FPM memory issues, found and fixed five different root causes, then found a new unrelated bug the next day that crashed the site and could have crashed it for weeks. The irony isn’t lost on me.

The silver lining: this mistake is now documented, and I’ll never make it again. Hopefully you won’t either.

Have you been bitten by recursive WordPress filters? Find me on Mastodon at @jfrumau@mastodon.social to share your war stories.

The Symptoms

The site was experiencing intermittent failures with WordPress’s generic error message:

There has been a critical error on this website.

PHP-FPM logs showed:

[pool wordpress] seems busy (you may need to increase pm.start_servers)
[pool wordpress] server reached pm.max_children setting (30)

Error logs revealed memory exhaustion:

PHP Fatal error: Allowed memory size of 536870912 bytes exhausted

The errors occurred roughly every 10 minutes, often triggered by simple requests like HEAD / from uptime monitors.

The Investigation

Step 1: Initial PHP-FPM Analysis

First, I checked the current worker state:

# Count active PHP-FPM workers
pgrep -c php-fpm

# Memory usage by PHP workers
ps aux --sort=-%mem | grep php-fpm | head -10

# Total PHP-FPM memory
ps aux | grep 'php-fpm: pool' | awk '{sum+=$6} END {print sum/1024" MB"}'

Workers were showing alarming memory usage:

817.754 MB - PID 56823
687.953 MB - PID 56841
177.629 MB - PID 56833

Some workers had ballooned to 800MB+ while others stayed healthy at ~150MB.

Step 2: Understanding the Memory Math

On a 4GB server running the full LEMP stack:

Available RAM: ~3.5GB (after system/services)
30 workers × ~200MB each = 6GB theoretical max
Safe worker count: 3500MB / 200MB = ~17-18 workers

But the problem wasn’t the worker count—it was memory accumulation in long-running workers.

Root Cause #1: WordPress Memory Limit Too Low

The first discovery was surprising. WordPress has its own internal memory limit separate from PHP’s limit:

# Check WordPress memory limits
wp eval 'echo "WP_MEMORY_LIMIT: " . WP_MEMORY_LIMIT . "\n";'
# Output: WP_MEMORY_LIMIT: 40M  ← WAY too low!

WordPress was capping itself at 40MB regardless of PHP’s 512MB limit. With WooCommerce + Acorn (Laravel for WordPress), each request needs 150-250MB.

The Fix:

In site/config/application.php (Bedrock):

/**
 * Memory Limits
 * WP_MEMORY_LIMIT: Memory for frontend requests (WordPress default: 40M)
 * WP_MAX_MEMORY_LIMIT: Memory for admin requests (WordPress default: 256M)
 */
Config::define('WP_MEMORY_LIMIT', '256M');
Config::define('WP_MAX_MEMORY_LIMIT', '512M');

Root Cause #2: Worker Memory Accumulation

PHP-FPM workers don’t release memory between requests. Over time, they accumulate:

Request 1:   150 MB
Request 50:  250 MB
Request 100: 350 MB
Request 200: 500+ MB  ← Danger zone!

The pm.max_requests setting forces workers to recycle after N requests. But on a low-traffic site (~80 requests/hour spread across 15 workers), workers were only handling ~5 requests/hour each. They’d accumulate memory for 20+ hours before recycling.

The Fix:

Reduce pm.max_requests aggressively:

# trellis/group_vars/production/main.yml
php_fpm_pm_max_requests: 25  # Reduced from 500 → 200 → 100 → 25

Apply with:

trellis provision --tags wordpress-setup production

Root Cause #3: Action Scheduler Async Runner

WooCommerce uses Action Scheduler for background tasks. I noticed the async runner was constantly spawning AJAX requests:

POST /wp-admin/admin-ajax.php?action=as_async_request_queue_runner

Each request tied up a PHP-FPM worker and accumulated ~2-5MB that was never released.

I had already added the constant to disable it:

Config::define('ACTION_SCHEDULER_DISABLE_ASYNC', true);

But WooCommerce 10.x ignores this constant! It now uses a filter instead.

The Fix:

Create an MU-plugin that registers the filter before WooCommerce loads:

<?php
/**
 * Plugin Name: Disable Action Scheduler Async Runner
 * Description: Disables WooCommerce Action Scheduler async AJAX runner.
 */

add_filter('action_scheduler_allow_async_request_runner', '__return_false');

Place in site/web/app/mu-plugins/disable-action-scheduler-async.php.

Why MU-plugin? MU-plugins load before regular plugins, ensuring the filter is registered before WooCommerce initializes.

Root Cause #4: Orphaned Plugin Data

Database analysis revealed bloated data from plugins removed years ago:

# Check autoloaded options size
wp db query "SELECT option_name, LENGTH(option_value) as size_bytes
FROM wp_options WHERE autoload='yes'
ORDER BY size_bytes DESC LIMIT 10;"

Results:

The Fix:

# Delete orphaned options
wp db query "DELETE FROM wp_options WHERE option_name LIKE 'rs-%' OR option_name LIKE 'revslider%';"
wp db query "DELETE FROM wp_options WHERE option_name = 'ptk_patterns';"
wp db query "DELETE FROM wp_options WHERE option_name = 'wp_installer_settings';"

# Clean expired transients
wp transient delete --expired

# Flush object cache
wp cache flush

Result: 58.7% reduction in autoloaded data (608 KB → 251 KB).

Root Cause #5: XMLRPC Attacks

The final piece of the puzzle came from Xdebug profiling. Error logs showed:

[23-Nov-2025 04:43:10] worker 77 exited on signal 9 (SIGKILL)
request: "POST /xmlrpc.php"
IP: 103.42.58.162

Even when xmlrpc.php returns 404/403, the request still:

1. Loads WordPress core (wp-load.php)
2. Bootstraps WooCommerce and Acorn
3. Executes apply_filters() chain
4. Consumes significant memory before being blocked

The Fix:

Block XMLRPC at the Nginx level (zero PHP involvement):

# trellis/group_vars/production/wordpress_sites.yml
wordpress_sites:
  example.com:
    xmlrpc:
      enabled: false  # Generates: location ~* xmlrpc\.php$ { return 444; }

Trellis uses HTTP 444 (Nginx-specific “No Response”) which drops the connection immediately. Attackers get a timeout with no feedback.

# Verify it's working
curl -v --max-time 5 https://example.com/xmlrpc.php
# Result: HTTP/2 stream was not closed cleanly: PROTOCOL_ERROR

Diagnostic Commands Reference

Here are the key commands I used throughout this investigation:

Memory Status

# Quick health check
ssh root@server "echo '=== Memory ===' && free -m | grep Mem && \
echo '' && echo '=== Workers ===' && \
ps aux --sort=-%mem | grep 'php-fpm: pool' | head -5 | \
awk '{print \$6/1024 \" MB - PID \" \$2}'"

PHP-FPM Logs

# Recent warnings
grep 'seems busy\|max_children' /var/log/php8.3-fpm.log | tail -20

# Watch in real-time
tail -f /var/log/php8.3-fpm.log

Database Analysis

# Autoloaded options size
wp db query "SELECT COUNT(*) as count, ROUND(SUM(LENGTH(option_value))/1024) as size_kb
FROM wp_options WHERE autoload='yes';"

# Largest options
wp db query "SELECT option_name, LENGTH(option_value) as size_bytes
FROM wp_options WHERE autoload='yes'
ORDER BY size_bytes DESC LIMIT 10;"

Memory Spike Detection

# Watch for workers above 300MB
while true; do
  HIGH_MEM=$(ps aux --sort=-%mem | grep 'php-fpm: pool' | \
    awk '$6 > 307200 {print $6/1024 " MB - PID " $2}' | head -1)
  if [ -n "$HIGH_MEM" ]; then
    echo "[$(date +%H:%M:%S)] SPIKE: $HIGH_MEM"
    tail -3 /var/log/nginx/access.log
  fi
  sleep 10
done

Final Configuration

After all fixes, here’s the stable configuration:

# PHP-FPM Pool (trellis/group_vars/production/main.yml)
php_fpm_pm: dynamic
php_fpm_pm_max_children: 30
php_fpm_pm_start_servers: 10
php_fpm_pm_min_spare_servers: 8
php_fpm_pm_max_spare_servers: 15
php_fpm_pm_max_requests: 25        # Aggressive recycling

# PHP Memory
php_memory_limit: 1024M            # High ceiling for headroom

// WordPress Memory (site/config/application.php)
Config::define('WP_MEMORY_LIMIT', '256M');
Config::define('WP_MAX_MEMORY_LIMIT', '512M');

Results

After implementing all fixes:

• Workers stable at 112-120MB (down from 600-800MB spikes)
• No OOM errors in 24+ hours
• 2.7GB free memory on 4GB server
• XMLRPC attacks blocked at Nginx (zero PHP load)
• Redis object cache active (additional performance boost)

Key Lessons Learned

1. WordPress has its own memory limit — WP_MEMORY_LIMIT caps memory regardless of PHP’s memory_limit. Check this first on WooCommerce sites.

2. Low-traffic sites need aggressive worker recycling — pm.max_requests: 500 is useless if workers only handle 5 requests/hour. Use 25-50 for low-traffic sites.

3. Constants can become deprecated — WooCommerce 10.x ignores ACTION_SCHEDULER_DISABLE_ASYNC. Always verify by checking actual code behavior.

4. Block attacks at Nginx, not PHP — Even “blocked” PHP requests consume memory during WordPress bootstrap. Use return 444 for zero-PHP blocking.

5. Old plugin data accumulates — Plugins removed years ago can leave megabytes of orphaned data. Audit wp_options periodically.

6. Profile production, not just development — The XMLRPC attack pattern only appeared in production logs. Xdebug profiling on production (temporarily) was essential.

Conclusion

What started as a simple “critical error” turned into a multi-day investigation uncovering five distinct issues. Each fix contributed to stability, but the combination of all fixes was necessary for complete resolution.

The most important takeaway: memory issues on WordPress/WooCommerce rarely have a single cause. Systematic investigation with proper tooling (logs, profiling, database analysis) is essential for finding all contributing factors.

If you’re experiencing similar issues on your Trellis/Bedrock/Sage stack, I hope this detailed walkthrough helps you identify and fix your root causes faster than I did!

Have you dealt with PHP-FPM memory issues on WordPress? Find me on Mastodon at @jfrumau@mastodon.social to share your experiences and solutions!

In this post, I’ll walk you through how I created a custom WordPress Walker class that handles complex mobile navigation requirements while maintaining clean, maintainable code.

The Challenge

The client needed a mobile navigation system with several specific requirements:

• Two-level navigation structure with main menu and expertise submenu
• Multilingual support for Dutch, English, and German using Polylang
• Dynamic language detection from URL structure
• Custom navigation controls (back button, close button)
• Performance optimization to minimize database queries
• Fallback content when WordPress menus aren’t fully configured

The Solution: Custom Walker Class

Instead of using multiple functions and queries, I created a single Mobile_Nav_Walker class that extends WordPress’s Walker_Nav_Menu class. This approach consolidates all the logic into one optimized system.

Basic Walker Structure

class Mobile_Nav_Walker extends Walker_Nav_Menu {
    
    private $current_language = 'nl';
    private $expertise_parent_id = null;
    private $main_nav_html = '';
    private $categories = array();
    private $category_parents = array();
    
    public function __construct() {
        // Detect current language from URL
        $url = $_SERVER['REQUEST_URI'];
        if (preg_match('/\/en\//', $url)) {
            $this->current_language = 'en';
        } elseif (preg_match('/\/de\//', $url)) {
            $this->current_language = 'de';
        } else {
            $this->current_language = 'nl';
        }
    }
}

Language Detection System

The walker automatically detects the current language by analyzing the URL structure. This works seamlessly with Polylang’s URL-based language switching:

private function get_language_button_text() {
    switch ($this->current_language) {
        case 'en':
            return array('back' => 'Back', 'close' => 'Close');
        case 'de':
            return array('back' => 'Zurück', 'close' => 'Schließen');
        default:
            return array('back' => 'Terug', 'close' => 'Sluiten');
    }
}

Processing Menu Items

The start_el method processes each menu item and builds the navigation structure:

public function start_el(&$output, $item, $depth = 0, $args = null, $id = 0) {
    
    // Process top-level navigation items
    if ($depth === 0 && $item->menu_item_parent == 0) {
        $classes = $item->classes ? $item->classes : array();
        $has_submenu = in_array('has-mega-menu', $classes) ? 'has-submenu' : '';
        $data_target = in_array('has-mega-menu', $classes) ? 'data-target="expertise"' : '';
        $arrow = $has_submenu ? '<span class="nav-arrow">›</span>' : '';
        
        // Store expertise parent ID for submenu processing
        if (in_array('has-mega-menu', $classes)) {
            $this->expertise_parent_id = $item->ID;
        }
        
        // Build main navigation HTML
        $this->main_nav_html .= '<a href="' . $item->url . '" class="nav-item ' . $has_submenu . '" ' . $data_target . '>';
        $this->main_nav_html .= $item->title . $arrow;
        $this->main_nav_html .= '</a>';
    }
    
    // Process expertise submenu items
    $classes = $item->classes ? $item->classes : array();
    
    // Direct children of Expertise (category headers)
    if ($item->menu_item_parent == $this->expertise_parent_id) {
        if (in_array('mega-menu-row-1', $classes)) {
            $this->categories[$item->title] = array();
            $this->current_category = $item->title;
            $this->category_parents[$item->ID] = $item->title;
        }
    }
    // Children of category headers (actual service items)
    elseif (isset($this->category_parents[$item->menu_item_parent])) {
        $parent_category = $this->category_parents[$item->menu_item_parent];
        $this->categories[$parent_category][] = $item;
    }
}

Two-Level Navigation Structure

The walker generates a sophisticated two-level mobile navigation:

Level 1: Main Menu

• Logo
• Main navigation items
• Language-aware close button
• CTA button

Level 2: Expertise Submenu

• Language-aware back button
• Categorized service items
• Language-aware close button
• CTA button

public function get_mobile_navigation_html() {
    $button_text = $this->get_language_button_text();
    
    $html = '<div class="mobile-nav-enhanced">';
    
    // Level 1: Main Menu
    $html .= '<div class="nav-level level-1">';
    $html .= '<div class="mobile-nav-header">';
    
    if (!empty(get_field('hs_logo', 'option'))) {
        $html .= '<img src="' . get_field('hs_logo', 'option') . '" alt="Allinq Digital" class="mobile-logo">';
    }
    
    $html .= '<button class="mobile-close-btn">' . $button_text['close'] . '</button>';
    $html .= '</div>';
    
    $html .= '<nav class="mobile-nav-menu">';
    $html .= $this->main_nav_html;
    $html .= '</nav>';
    
    $html .= '<div class="mobile-nav-cta">';
    $html .= $this->get_mobile_cta_button();
    $html .= '</div>';
    $html .= '</div>';
    
    // Level 2: Expertise Submenu
    $html .= $this->generate_expertise_submenu($button_text);
    
    $html .= '</div>';
    
    return $html;
}

Multilingual CTA Buttons

The walker handles different CTA buttons for each language using Advanced Custom Fields:

private function get_mobile_cta_button() {
    $header_btn = get_field('hs_button', 'option');
    $header_btn_en = get_field('hs_button_en', 'option');
    $header_btn_de = get_field('hs_button_de', 'option');
    
    $button_html = '';
    
    switch ($this->current_language) {
        case 'en':
            if (!empty($header_btn_en)) {
                $button_html = '<a href="' . $header_btn_en['url'] . '" class="mobile-cta-btn">';
                $button_html .= $header_btn_en['title'] . ' <span class="cta-arrow">→</span>';
                $button_html .= '</a>';
            }
            break;
        case 'de':
            if (!empty($header_btn_de)) {
                $button_html = '<a href="' . $header_btn_de['url'] . '" class="mobile-cta-btn">';
                $button_html .= $header_btn_de['title'] . ' <span class="cta-arrow">→</span>';
                $button_html .= '</a>';
            }
            break;
        default:
            if (!empty($header_btn)) {
                $button_html = '<a href="' . $header_btn['url'] . '" class="mobile-cta-btn">';
                $button_html .= $header_btn['title'] . ' <span class="cta-arrow">→</span>';
                $button_html .= '</a>';
            }
            break;
    }
    
    return $button_html;
}

Intelligent Fallback System

One of the key features is the intelligent fallback system. If the WordPress menu isn’t fully configured or lacks the expected structure, the walker provides language-appropriate fallback content:

private function get_fallback_expertise_structure() {
    $html = '';
    
    switch ($this->current_language) {
        case 'en':
            $html .= '<div class="nav-category">';
            $html .= '<h3>Digitalisation</h3>';
            $html .= '<a href="#" class="nav-item">Scan to BIM <span class="nav-arrow">›</span></a>';
            $html .= '<a href="#" class="nav-item">Digital Channel <span class="nav-arrow">›</span></a>';
            $html .= '</div>';
            // ... more categories
            break;
            
        case 'de':
            $html .= '<div class="nav-category">';
            $html .= '<h3>Digitalisierung</h3>';
            $html .= '<a href="#" class="nav-item">Scan to BIM <span class="nav-arrow">›</span></a>';
            // ... more items
            break;
            
        default: // Dutch
            $html .= '<div class="nav-category">';
            $html .= '<h3>Digitaliseren</h3>';
            $html .= '<a href="#" class="nav-item">Scan to BIM <span class="nav-arrow">›</span></a>';
            // ... more items
            break;
    }
    
    return $html;
}

Usage Implementation

To use the walker, I created a simple function that handles menu detection and fallbacks:

function get_walker_mobile_navigation() {
    // Try to get menu by theme location first
    $locations = get_nav_menu_locations();
    $menu_id = isset($locations['main_menu']) ? $locations['main_menu'] : false;
    
    // If no menu assigned, try language-specific menu names
    if (!$menu_id) {
        $url = $_SERVER['REQUEST_URI'];
        
        if (preg_match('/\/en\//', $url)) {
            $menu_names = array('Main Menu (EN)', 'Main Menu EN');
        } elseif (preg_match('/\/de\//', $url)) {
            $menu_names = array('Main Menu (DE)', 'Main Menu DE');
        } else {
            $menu_names = array('Main Menu', 'Main Menu NL');
        }
        
        foreach ($menu_names as $menu_name) {
            $menu = wp_get_nav_menu_object($menu_name);
            if ($menu) {
                $menu_id = $menu->term_id;
                break;
            }
        }
    }
    
    // Generate navigation using walker
    if ($menu_id) {
        $walker = new Mobile_Nav_Walker();
        $menu_items = wp_get_nav_menu_items($menu_id);
        
        if ($menu_items) {
            foreach ($menu_items as $item) {
                $walker->start_el($output, $item, 0, null, 0);
            }
            return $walker->get_mobile_navigation_html();
        }
    }
    
    // Fallback if no menu found
    $walker = new Mobile_Nav_Walker();
    return $walker->get_mobile_navigation_html();
}

Performance Benefits

This custom walker approach provides several performance advantages:

1. Single Database Query: Instead of multiple wp_get_nav_menu_items() calls, everything is processed in one query
2. Efficient Processing: Menu items are processed once and stored in class properties
3. Lazy Generation: HTML is only generated when requested
4. Memory Efficient: No redundant data structures or processing

Template Integration

In your header template, simply call:

echo get_walker_mobile_navigation();

The walker handles all the complexity behind the scenes, providing a clean API for your templates.

CSS Considerations

The walker generates specific CSS classes for styling:

.mobile-nav-enhanced {
    /* Main container */
}

.nav-level {
    /* Level containers (level-1, level-2) */
}

.mobile-nav-header {
    /* Header with logo/buttons */
}

.nav-item {
    /* Navigation links */
}

.nav-item.has-submenu {
    /* Items with submenus */
}

.nav-category {
    /* Category containers in submenu */
}

.mobile-cta-btn {
    /* CTA buttons */
}

Key Takeaways

Building this custom walker taught me several important lessons:

1. Plan for Flexibility: Always consider multiple languages and fallback scenarios
2. Optimize Early: Single query approaches scale better than multiple function calls
3. Encapsulate Logic: Walker classes keep complex logic organized and reusable
4. Test Edge Cases: Empty menus, missing translations, and incomplete configurations
5. Document Thoroughly: Complex navigation systems need clear documentation

Conclusion

Creating a custom WordPress Walker for mobile navigation might seem complex, but it provides incredible flexibility and performance benefits. This approach allowed me to create a sophisticated multilingual mobile navigation system that works seamlessly with Polylang while maintaining clean, maintainable code.

The walker pattern is particularly powerful for complex navigation requirements where the standard WordPress menu system falls short. By extending the built-in Walker class, you get all the benefits of WordPress’s menu system while adding your own custom functionality.

Have you built custom walkers for your WordPress projects? I’d love to hear about your experiences and any additional techniques you’ve discovered!