[Opus 4.7] "Claude failed to flag the well-known WooCommerce shop page hijack despite multiple iterations of the same problem; cost ~24 hours of debugging"

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

Help me build a curated Elementor landing page to replace the default WooCommerce shop archive on dev.berksfhs.org. Architecture decisions, plugin stack recommendations, and debugging help across multiple sessions over 28-29 April 2026.

What Claude Actually Did

Helped competently with surface-level tasks (page layout, widget choices, CSS) but failed three times in a row to recognise that recurring "page is broken" symptoms shared a single structural cause: WooCommerce's shop page assignment hijacks the URL render of whatever page is assigned to it. Each recurrence was treated as a fresh bug to debug, with different cosmetic fixes (slug renames, redirect cleanups, plugin deactivations, permalink regeneration) - none of which addressed the actual cause.

Also recommended FiboSearch Pro + Search and Filter Pro as best-in-class for this use case without surfacing the implementation friction inherent to that stack: S&F Pro v3 versus WP.org legacy v1.2.18 codebase divergence, vendor-portal site-linking handshake required for activation, WC shop page assignment interaction. Each became a debugging surprise during installation rather than a known cost noted up-front.

The "hardware lock" pattern (filter option_woocommerce_shop_page_id to force-read a fixed value, filter pre_update_option_woocommerce_shop_page_id to block writes, must-use plugin so it can't be deactivated through admin UI) only emerged after the third failed repair cycle. This is a defensive idiom that should have been suggested proactively the first time a critical option was being silently reassigned.

Expected Behavior

1. When a user first describes "a curated Elementor landing page that's also the WC shop page", Claude should immediately flag that this is mutually exclusive at the URL render layer - WC's archive template hijacks the assigned shop page's URL regardless of slug. Decouple, or use Elementor Pro Theme Builder for a Product Archive template. This is well-known WC architecture, not obscure trivia.
2. When the same symptom recurs across sessions, Claude should pattern-match: "We've fixed this exact symptom before. Recurrence suggests the cause is structural, not transient." Instead of diagnosing it as new each time. Especially when I kept saying 'But we've been here before - we already fixed this, supposedly!'
3. When recommending paid plugin stacks, Claude should surface known implementation friction alongside feature comparisons. Best-in-class on functionality is not the same as best-in-class on time-to-deploy.
4. When a critical WordPress option keeps getting silently reassigned, Claude should suggest the defensive lock pattern (option_ + pre_update_option_ filters in a must-use plugin) on the first or second occurrence, not the third or fourth.

Files Affected

This is a behavioural issue with Claude Code rather than a file-specific bug. For context, the artifacts created during the eventual fix were:

wp-content/mu-plugins/berksfhs-shop-page-lock.php (5 iterations to v1.1.3) - the hardware lock
wp-content/uploads/berksfhs/shop-page-lock.log - forensic stack-trace evidence of WC settings save flow
Project CLAUDE.md updated with the WC hijack pattern, hardware lock pattern, and decoupled architecture sections
recap.md updated with full session timeline and root-cause analysis

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Use Claude Code on a WordPress site with WooCommerce installed.
2. Tell Claude: "I want to build a curated Elementor landing page that will be my WooCommerce shop."
3. Follow Claude's suggestions to build the page and assign it as the shop page in WooCommerce → Settings → Products → General → Shop page.
4. Visit the page's URL on the front-end. Observe that WC has hijacked the render - the Elementor design is partial or absent, and a default product loop appears.
5. Ask Claude to diagnose. Note that the suggestions focus on slug changes, redirect cleanups, or plugin conflicts rather than flagging the architectural mismatch.
6. Apply Claude's fix. Watch it last roughly 60 minutes.
7. Ask Claude to diagnose again. Note that Claude treats the second occurrence as a new bug.
8. Repeat steps 5-7 a third time before either the user or Claude eventually pattern-matches.

The expected behaviour is for step 2 to trigger an immediate architectural warning about the hijack, before any building happens.

Claude Model

Opus

Relevant Conversation

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.77

Platform

Anthropic API

Additional Context

1. Estimated equivalent of £1500 in professional time lost
2. The first session ended with a context-overflow crash from a 2.1M-character HTML paste; the recap for that session had to be reconstructed from the JSONL transcript
3. The fix that actually worked: decoupled architecture (curated landing page is NOT WC's shop page; a separate empty placeholder is) plus a must-use plugin lock that filters reads, blocks writes, and surfaces both reactive (after blocked save) and proactive (on WC settings page visit) admin banners with full stack-trace logging
4. Project CLAUDE.md has been updated with all five lessons learned, so future Claude sessions on this codebase will start from a stronger position. The remaining feedback is for Claude Code's general behavioural defaults
5. Happy to share the full lock plugin source, log entries with stack traces, and recap files if useful for case-study purposes