humanmade / humanmade/hm-query-loop
E2E suite fails on WordPress 7.0 and 7.1
- Dominant language
- JavaScript
- Stars
- 7
- Forks
- 0
- Avg merge
- 4h 17m
- Merged PRs (30d)
- 1
Description
The e2e suite passes on WordPress 6.9 (22/22) but fails on 7.0 and 7.1. Those two lanes were added in #37 and are currently **non-blocking** so they cannot gate merges — they still run and report on every PR. Move them back into `DEFAULT_BLOCKING` in the `lanes` job of `.github/workflows/playwright-tests.yml` once this is closed.
No test is skipped or disabled; the failures are live and visible.
## Current state
| Lane | Result |
| --- | --- |
| 6.9 | 22 passed |
| 7.0 | 8 failed / 14 passed |
| 7.1 | 11 failed / 11 passed |
## Failure groups
**A. Plugin's `core/query` inspector panels not found in the 7.x site editor** (8 tests, both 7.0 and 7.1)
- `elasticpress-toggle.spec.js` — both tests
- `posts-per-page.spec.js` — 3 tests
- `query-presets.spec.js` — 3 editor tests
These fail on `label:has-text("Query Preset")` and `.components-panel__body-title:has-text("Extra Query Loop Settings")` not being found. The correlation is exact: every spec that opens the settings sidebar **in the site editor** fails; specs that use the post editor pass.
**B. 7.1 only** (3 further tests)
- `multiple-post-templates.spec.js` — 2 tests. Post editor, does not open the settings sidebar, so outside group A. Passes on 7.0.
- `query-presets.spec.js › should apply query preset on frontend` — a **frontend** assertion. This cannot be a selector problem and is the most likely candidate for a real plugin bug on 7.1.
## Already ruled out
Please don't re-tread these:
- **Not a stale `@wordpress/e2e-test-utils-playwright`.** `openDocumentSettingsSidebar` is byte-identical in 1.33.2 (`wp-6.9`), 1.40.1 (`wp-7.0`), 1.50.0 (pinned) and 1.54.0. The per-WordPress dist-tags do not help.
- **Not renamed landmarks.** `Editor top bar` and `Editor settings` are unchanged between the 6.9.7 and 7.1 builds of `wp-includes/js/dist/editor.js`.
- **Not a renamed panel class.** `components-panel__body-title` still exists in 7.1's `components.js`.
- **Not a broken site editor.** The test asserting the site editor layout loads passes on 7.0.
- **Not the sidebar failing to open.** Fixed in #37 — the `openDocumentSettingsSidebar` timeout is gone from the 7.0 log.
- **Not the sidebar tab.** Selecting the Block tab after opening the sidebar changed nothing; 7.0 stayed at exactly 8 failures.
## Fixed in #37 along the way
`tests/e2e/database.sql` pins `db_version` to 60717 (WordPress 6.9.7). 7.0, 7.1 and trunk expect 61833, so core redirected every admin request to `wp-admin/upgrade.php` and the suite ran **0 tests**. Resolved with `wp core update-db` after the fixture import. This was latent and would have broken the suite on any core bump.
## Suggested approach
The remaining diagnosis needs someone who can actually run WordPress 7.x and open the site editor — the work in #37 was done in a sandbox with no Docker images available, so every 7.x conclusion above is inferred from CI logs rather than observed. Start by opening a Query Loop block in the 7.1 site editor and checking whether this plugin's panel renders at all; that single observation splits group A into "test selector" versus "plugin does not register its controls there".
Group B's frontend failure is worth treating separately and first, since it is the one that would affect real sites.
Contributor guide
No contributing guide indexed for this repository
Research direction
Run the lanes job in .github/workflows/playwright-tests.yml against WordPress 7.0 and 7.1, starting with the Query Loop site-editor cases in elasticpress-toggle.spec.js, posts-per-page.spec.js, and query-presets.spec.js. Check the plugin panels in the 7.1 site editor, then reproduce the separate frontend failure and multiple-post-templates.spec.js failures. Done means the 7.x suite passes and those lanes return to DEFAULT_BLOCKING.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, javascript, playwright, wordpress
- Domain
- ci-cd, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100