Fix media modal crash on WP 7.0 due to attachment filters wrapper change

[kraftbj]

WP core commit 61757 wrapped the media attachment filters <select> and <label> in a container <div> for accessibility. This changed toolbar.get('filters') from returning the AttachmentFilters view directly to returning a wrapper wp.media.View, causing customizeFilters() to crash with:

Uncaught TypeError: Cannot read properties of undefined (reading 'all')
    at n.customizeFilters

This broke the media modal for any SCF image/file field on WP 7.0.

The fix resolves the actual AttachmentFilters view by checking whether the returned view has a .filters property. If not (WP 7.0+), it traverses the wrapper's subviews to find the AttachmentFilters instance. This is compatible with both WP < 7.0 and WP 7.0+.

Tested on both WP 6.9.4 and WP 7.0-RC2 with the full E2E suite passing.

Fixes #396
See https://core.trac.wordpress.org/ticket/64948

Use of AI Tools

This PR was authored with assistance from Claude Code (Anthropic). The fix was developed after debugging the root cause using Playwright-based investigation of the media modal behavior on WP 7.0-RC2.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props kraftbj, cbravobernal, bernhard-reiter.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.65%. Comparing base (b448e17) to head (e6c450e).
⚠️ Report is 7 commits behind head on trunk.

Additional details and impacted files

@@             Coverage Diff              @@
##              trunk     #399      +/-   ##
============================================
- Coverage     54.00%   52.65%   -1.35%     
  Complexity     4423     4423              
============================================
  Files           298      298              
  Lines         39467    39475       +8     
============================================
- Hits          21314    20786     -528     
- Misses        18153    18689     +536     

Flag	Coverage Δ
e2e-js	45.76% <100.00%> (+0.03%)	⬆️
e2e-php	40.58% <ø> (-2.15%)	⬇️
javascript	15.06% <0.00%> (-0.02%)	⬇️
phpunit	29.95% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ockham]

I was going to wait a bit longer for https://core.trac.wordpress.org/ticket/64948 to be potentially fixed before WP 7.0 is released 🤔

[kraftbj]

That's fine! I figure it's quick to merge and ship a quick compat release if we need to this way.

[cbravobernal]

The approach looks right and is adaptive to both structures: on WP < 7.0 (and on a future core where toolbar.get( 'filters' ) returns the AttachmentFilters view directly again), the ! filtersView.filters check falls through and nothing changes; on WP 7.0 the wrapper's subviews are searched.

One edge worth hardening while we're here: if toolbar.get( 'filters' ) returns undefined, or no subview exposes .filters, filters remains the wrapper (or undefined) and the function still crashes a few lines later at filters.filters.all. A small guard after the lookup would make this bulletproof:

if ( ! filters || ! filters.filters ) {
	return;
}

With that, the media modal degrades gracefully (default filters, no SCF customization) instead of breaking if core moves the view again.

Review run via Claude Code, reviewed by @cbravobernal.