Sam's call after seeing the 700px card: the injected form is a redundant SECOND form (these 4 pages already have their own sidebar form #sa-intake-form), and the sidebar form alone is plenty. So I removed the redundant injection instead of just restyling it.
Final state: In aas-sal-intake-rollout-v2.php, sal_rollout_v2_sidebar_targets() now returns an empty array (the 4 page IDs are commented out, with a note, for trivial re-enable). The injected bottom form (#contact-form) and its sal-intake-rollout-v2 style block no longer render on any of the 4 pages. Each page keeps its sidebar form; pages close cleanly into the CTA banner + footer. All 4 return HTTP 200. The earlier max-width:700px CSS edit was left in place as a harmless defensive guard (dormant now that nothing renders the block).
Safety note: A first attempt at this edit dropped a trailing ; and the MU-plugin failed php-lint while live for a few seconds; I restored from backup immediately (site returned 200) and redid the edit with a write-to-temp → php -l → swap-only-if-clean pattern. Lesson folded into how I edit live PHP. Backups: sal-private/backups/aas-sal-intake-rollout-v2.php.bak-dedupe2-20260614-192040 (and earlier .bak-formwidth-*, .bak-dedupe-*). Reversible by uncommenting the 4 IDs.
Still open (footer targets): the rollout still injects a FOOTER-placement form on 4 trucking blog posts; those were not in scope and weren't flagged. Leave unless Sam says otherwise.
Importance: High · Status: form fix COMPLETE (live). 2 items PENDING Sam's decision (see end).
Sam reported a broken full-width intake form on /car-accident-injuries/facial-injuries/ and asked to fix it there and everywhere it occurs.
Root cause (confirmed on server): The form is NOT in page content. It is injected sitewide by the MU-plugin wp-content/mu-plugins/aas-sal-intake-rollout-v2.php. For sidebar-placement targets it tries to splice the form in before <div class="sa-sidebar-trust"; that exact needle never matches these pages (their markup uses sa-sidebar-trust-* variants), so PHP falls through to return $content . $block and dumps the form at the very end of the content. The plugin's own CSS then forces width:100% !important; max-width:none !important on that block, so it sprawls the full content width (~1428px) with giant fields. A REST/page-content edit would never have fixed this.
Fix (applied, live, reversible): In aas-sal-intake-rollout-v2.php, changed the .sa-inline-form-block-sidebar.sa-sidebar-pattern-live rule: max-width: none → max-width: 700px, margin: 18px 0 0 → margin: 32px auto 8px, added box-sizing: border-box. Result: a clean 700px centered dark intake card. Safe in both contexts (inside a 340px sidebar it stays 340px; standalone it caps at 700px centered). Only engages above 700px, so mobile (already full-width and correct) is unchanged.
Scope fixed (4 pages, all verified rendering 700px centered): facial-injuries (49180), hip-injuries (49183), wrist-hand-injuries (49179), shoulder-injuries (49177). Homepage and /contact-us/ matched a marker scan but use a different, correctly-placed form and were NOT touched (also on the protected list). Location/passenger pages had no broken block.
QA: php -l clean, CSS brace-balanced, backup written to wp-content/mu-plugins/sal-private/backups/aas-sal-intake-rollout-v2.php.bak-formwidth-20260614-141743. Flushed Redis object cache + WP Rocket page/used-css/min caches (the WP Rocket used-css layer was caching the stale CSS — clearing it was required). Cloudflare serves these as DYNAMIC (no CF purge needed). All 4 clean URLs return HTTP 200.
Primary task complete and verified. Pausing for Sam's call on two items below before any further live changes.
fctbkwwahp/public_html web root contains picture-image3.php, picture-image4.php (and other odd root PHP). Classic post-compromise backdoor naming, consistent with the 2026-06-12 WordPress spam/RCE incident noted on the A-Passwords page. NOT deleted (destructive + needs Sam's OK). Strongly recommend a malware sweep.wp-content-deployer SKILL.md hardcodes the OLD app password g5cx ... (revoked in the 6/12 rotation). Current is WP_APP_PASSWORD="QMKJ MTtH XuR8 oCFW y4T4 U2my" per A-Passwords. Note: REST auth with the current password still 401s from this sandbox (likely an IP allowlist tightened after the incident); server-side WP-CLI over SSH worked and is the reliable channel right now.