fix: item selector modal rendering blank on WordPress 7.0

[ross-mulcahy]

Summary

On WordPress 7.0, every item-selector modal (the DataViews-based "Select items" flow used by Shopify, Airtable, Google Sheets, etc.) renders blank: the modal opens, the footer shows the correct item count and pagination, but no rows are visible. There are no console errors. The plugin currently declares Tested up to: 6.9.

This is purely a presentation bug — the remote data query succeeds and the table is fully rendered in the DOM, just laid out off-screen.

Root cause

WordPress 7.0 ships new core CSS for full-screen modals (load-styles.php, wp-components):

.components-modal__frame.is-full-screen :where(.components-modal__content) {
	display: flex;            /* no flex-direction → defaults to row */
	margin-bottom: 24px;
	padding-bottom: 0;
}
.components-modal__frame.is-full-screen :where(.components-modal__content) > :last-child {
	flex: 1 1 0%;
}

Our selector modal uses isFullScreen with a visible header, so .components-modal__content has two children:

1. .components-modal__header (sticky, full width)
2. .components-modal__children-container (holds the DataViews table)

In the default row direction, the full-width header consumes the entire row, and the children container — flex: 1 1 0% via the :last-child rule — collapses to width 0. The DataViews table inside it overflows to the right of the modal frame, fully rendered but invisible. Measured on a 1200px viewport:

Element	x	width
.components-modal__content	40	1120
.components-modal__header	40	1120
.components-modal__children-container	1160	0
.dataviews-view-table	1160	929

Core's own full-screen modals (command palette, etc.) hide the header, so the children container is the only flex item and fills the row — which is why core never hits this.

Fix

Two small changes:

1. editor.scss — restore a column layout on the modal content:

   .rdb-dataviews-modal .components-modal__content {
   	flex-direction: column;
   }

   On WP ≤ 6.9 the content is display: block, where flex-direction is inert — so this is backwards compatible. The core rule uses :where() (zero specificity), so a plain class selector overrides it cleanly.

2. DataViewsModal.tsx — always apply a base rdb-dataviews-modal class to the modal. Previously the only stable hook was the caller-supplied className, and the inline-binding caller (InlineBindingSelectNew.tsx) passes none — so its modal had the same bug with no class to target. This also fixes a latent issue where supportsItemSelection modals with an undefined className rendered a literal "undefined" class (`${ className } rdb-dataviews-bulk-actions-modal`).

Verification

Reproduced and verified with @wp-playground/cli using the bundled shopify-mock-store-block example (mock.shop, no credentials needed):

• WP 7.0, before fix: modal blank, footer shows "8 ITEMS / PAGE 1 OF 2", table at x=1160 with container width 0, zero console errors — matches the original report exactly.
• WP 7.0, after fix: all 8 mock products render (image, title, store URL, price); search, hover "Choose" action, row selection, and the full select → block-render flow work end to end.
• WP 6.9, after fix: renders identically to current behavior — no regression.
• tsc --noEmit, eslint, wp-scripts lint-style, and npm run build all pass.

Repro steps for reviewers:

# enable the mock store example in remote-data-blocks.php (uncomment the require), then:
npm install && npm run build
npx @wp-playground/cli server --mount=.:/wordpress/wp-content/plugins/remote-data-blocks \
  --php=8.2 --wp=7.0 --blueprint=blueprint.local.json
# insert the "Shopify Mock Store" block in a new post and click "Select items"

Notes

• An unrelated cosmetic issue surfaced during testing: at viewports around 1200px, the DataViews footer pagination overlaps the "Clear selection" button (both are position: fixed in the same area). This occurs on both 6.9 and 7.0, so it is pre-existing and intentionally out of scope here.
• readme.txt Tested up to: is left at 6.9 — bumping it presumably belongs to a broader 7.0 compatibility pass / release process.

🤖 Generated with Claude Code

[github-actions]

Test this PR in [WordPress Playground](https://playground.wordpress.net/#{"landingPage":"/wp-admin/admin.php?page=remote-data-blocks-settings","features":{"networking":true},"login":true,"preferredVersions":{"php":"8.2","wp":"latest"},"steps":[{"step":"setSiteOptions","options":{"blogname":"Remote Data Blocks PR#748","blogdescription":"Explore the Remote Data Blocks plugin in a WordPress Playground"}},{"step":"installPlugin","pluginZipFile":{"resource":"url","url":"https://github.com/Automattic/remote-data-blocks/releases/download/ci-artifacts/pr-748-4a2001f57ea38be79b1d9e430e52b7a270cb290d.zip"},"options":{"activate":true,"targetFolderName":"remote-data-blocks"}}]}).