Notes

The Avada Problem

Avada is the worst case for WordPress development because the page builder makes it easier to edit in the admin than at the template level, so that's where everything lives. Every Fusion Builder element can be overridden inline, and once anyone discovers that, the codebase becomes decorative. The theme looks like it controls the site but actually controls maybe 10% of what renders.

The really insidious part: Avada changes made in the admin get serialized into post meta as Fusion Builder shortcodes. If you want to find out "why is this button blue," the answer is buried in a _fusion_builder_content field in the database, not in any file you can search. You can't grep for it. You can't diff it. You can't code-review it. The source of truth for page content is the database, and the database is full of opaque shortcode blobs.

What this means for the handoff: Anyone who inherits the marketing site needs to understand that "reading the code" means clicking through nested element settings in a UI that wasn't designed to be audited. Template-level changes will have no effect on content that's been overridden inline. Migrating or refactoring page content is brutal because you're extracting from database blobs, not reorganizing files.

The reservations site is somewhat better because the Moc-Avada child theme has real business logic in its functions/ directory — but the page layouts themselves still suffer from the same Fusion Builder serialization problem.

WP Engine: The Safe Enterprise Choice

WP Engine is priced like a premium host but its model is built around managed simplicity. The things that make dev work pleasant — SSH that works the way you want, real staging workflows, sane Git deploys, the ability to run arbitrary tooling — are either restricted, awkward, or behind upcharges. You're paying enterprise prices for a sandbox that fights you.

The agency probably picked WP Engine because "WP Engine" is the answer that doesn't get questioned in a meeting. The practical complaints:

• Git deploys are push-to-deploy with no review gate. One bad push and production is broken.
• SSH is limited. You can't install tools, run long processes, or do anything beyond basic file inspection.
• Staging is a single environment with manual snapshot-based syncing. No proper staging-to-production promotion workflow.
• Caching is aggressive and has broken dynamic features three separate times on the marketing site (Makers pagination, Gravity Forms uploads, content updates invisible to logged-out users).
• EverCache broke WooCommerce reports within 24 hours of being enabled on their recommendation.

What I'd change: If starting fresh and the client would entertain it, I'd put these on a standard VPS with a proper Docker deployment pipeline. Hetzner or a well-configured DigitalOcean droplet would give more control at lower cost. But the switch isn't worth the migration risk for a working system, and the client's IT team is used to WP Engine's dashboard.

WooCommerce Is Massive Overkill

The reservations site is a catering order form. Customers browse a menu, build a cart, pick a store and a date, and submit. No payments. No shipping. No taxes. No coupons. No refunds. No inventory counts.

WooCommerce brings an entire ecommerce engine — payment gateways, shipping zones, tax calculations, coupon logic, refund workflows, inventory management, order status state machines — and the site uses approximately none of it.

The practical cost:

• ~50+ plugins in the plugins/ directory, most of them WooCommerce plumbing
• Update anxiety — every WooCommerce update risks breaking the checkout flow, reports, or seasonal logic
• Plugin compatibility treadmill — the Google for WooCommerce plugin alone has caused tracking issues three times
• Performance overhead — WooCommerce loads its entire stack on every page load

The rebuild case: A Next.js + Payload CMS stack was scoped in March 2026. The core data models are simple — products, stores, orders, seasons, supper club config. Seasonal logic that's 1000+ lines of WordPress hooks would become a few utility functions. But the rebuild would cost real money, and the current system works.

The realistic path: The system will keep working. The risk isn't catastrophic breakage — it's that maintenance costs will slowly grow as WooCommerce updates require more testing and compatibility patches. Budget 30-45 hours/month for normal maintenance, 60-80 for busy months, 80-100+ during October/November holiday prep.

Things That Will Bite During Holiday Season

Holiday season (October through December) is when everything gets stressed. Based on three years of Basecamp history:

• PHP memory limits caused reporting failures during Thanksgiving 2023. The PHP memory limit is set to 512M in wp-config.custom.php, which handles current order volumes, but growth could trigger it again.
• Order status automation depends on statuses being set correctly. MoC has historically changed statuses from "Processing" to "Pending Payment" which broke the 2-day reminder automation in 2023.
• Report generation is resource-intensive. Two separate incidents of staff being locked out of reports due to PHP memory during the 2023 holiday season.
• Date logic edge cases — a year-change glitch on December 31, 2025 broke Supper Club date displays. DST transitions need attention for pickup time slot generation.
• Smartsheet data quality is inconsistent — duplicate PLUs, missing images, wrong categorizations. Budget time for data cleanup before every seasonal push.

The Catering Site Needs Modernization

The Google Merchant Center tracking breakdown was the first domino, not an isolated incident. The gla_ prefix mismatch went undetected for over a year (November 2024 to March 2026) — 100% of product IDs were failing to match in Google Ads, and roughly half of cart data was being silently discarded. That's not a configuration mistake. That's a symptom of a system where the integration surface between plugins is too large, too opaque, and too fragile to maintain reliably.

The stack is a chain of plugins that each assume they're the only ones touching the data layer: WooCommerce generates product data, GTM4WP transforms it into dataLayer events, Google Listings & Ads syncs it to Merchant Center with its own ID format, and Google Ads tries to match the two. When any link in that chain changes behavior — a plugin update, a settings change, a new prefix convention — the failure is silent. There's no validation, no error, no alert. You only find out when someone downstream (in this case, the ad agency) notices the numbers don't add up.

This is going to keep happening. Every WooCommerce update risks breaking the checkout flow, reports, or seasonal logic. Every plugin compatibility change is a potential silent failure. The Google for WooCommerce plugin alone has caused tracking issues three separate times. The MNTN and Meta pixels add more surface area. The custom reports plugin already needed a cache-bypass fallback after WP Engine's own recommendation (EverCache) broke it within 24 hours.

The reservation site doesn't need an ecommerce engine. It needs a form that takes orders. The longer it stays on WooCommerce, the more time gets spent on plugin compatibility instead of features. A rebuild was scoped in March 2026 (Next.js + Payload CMS) — the data models are simple, the seasonal logic becomes straightforward, and the entire plugin treadmill goes away. The question isn't whether to modernize — it's when the maintenance cost of not modernizing exceeds the rebuild cost.

What I'd Change

1. Replace WooCommerce with a purpose-built reservation system. The Next.js + Payload CMS scope exists. No plugin compatibility treadmill. The Google Ads / Merchant Center integration becomes a direct API call instead of a chain of four plugins hoping they agree on an ID format.

2. Move off WP Engine to a Docker deployment. Proper Git-based deploy pipeline with review gates, real staging, SSH access that doesn't fight you.

3. Extract the marketing site from Avada. Rebuild on a clean theme or static site. The content would need to be extracted from Fusion Builder database blobs — painful but one-time. The result would be version-controlled, greppable, diffable content.

4. Consolidate the media offload into the yax-offload-media plugin, which is more capable than the current s3-uploads + mu-plugin chain. It handles conversion, cleanup, discovery, and thumbnail regeneration.

Item 1 is the one with real urgency. The rest are quality-of-life improvements. The system works today, but the catering site's plugin stack is accumulating fragility faster than it's accumulating features.

Time Estimates for Context

From Basecamp hours tracking:

• Normal month: 30-45 hours
• Busy month: 60-80 hours
• Peak (October/November): 80-100+ hours
• MoC fiscal year runs November through October
• Quarterly reporting billed to job number 25-MARKET-509