Theme the selectors every front-office page inherits, and the 1.7 gap that exposed

[PrestaEdit]

Started as "cover Hummingbird on the front-office pages". The premise was wrong, and correcting it is most of the work.

The premise was wrong

I had reported that 25 of 31 front-office pages lacked a theme map. Literally true, and misleading: 24 of those declare no selectors at all — they are bare stubs (class Page extends BasePage {}). A theme map for them would be empty. I had counted files, not coverage.

The real gap is one level up. desktopLogo, userInfoLink and accountLink are declared once on FrontOfficePage and inherited by all 31 pages. Probed against a live 9.2 shop, all three miss on Hummingbird on every one of 18 pages tested. The catalog had nowhere to fix that: the chain FrontOffice\Page strips to a single usable segment and is dropped by the existing guard, so the only expressible fix was to repeat each key in all 31 page blocks — which is what Home already did for desktopLogo.

What changed

_common, a reserved per-area block (1871d82), merged as the least specific tier and beaten by any page block, including a parent's. It cannot collide with a page name: page segments come from class namespaces and never start with an underscore.

The three Hummingbird selectors are measured, not guessed — verified present on five pages before being written. Resolving them through the real page objects and querying the running shop gives 60 matches out of 60 across 15 pages and both themes. Dropping the block turns 30 of those red.

Two smoke steps (9cdd635), both on Stores, a page that declares no selectors of its own, so everything it resolves comes from the area. Nothing had ever asserted this markup, because no page declares it.

accountLink was the sharp one: probed anonymously it misses on both themes — the one shape that reads as "no divergence" while hiding one. Against a logged-in session it misses on Hummingbird and matches on Classic.

The 1.7 registration route (e59ca85). /registration arrived in 8.0; a 1.7.8.11 shop answers pagenotfound. goToRegistration() had been walking into a 404 on every 1.7 run. The v7 page was a bare stub inheriting the v9 route and nothing exercised it — the Registration scenario was in neither smoke suite, so the gap sat in "supported" territory with no run behind it.

Two defects found on the way

EnsureTestAccount has a dead branch on PrestaShop 9. It logs in with the FO_EMAIL / FO_PASSWD defaults, which match PrestaShop's demo customer, so it only works on a shop carrying demo data. Its register-if-missing fallback cannot stand in: 9.2 rejects that same password, answering "The minimum score must be: Strong". On a shop without the fixture — the duplicated second shop — both branches fail. An early green here proved nothing: it was the fixture passing, not the scenario. The smoke step uses Registration instead, which creates its own account and needs nothing from the shop's fixtures. EnsureTestAccount itself is left as-is and still carries this defect.

This corrects a prediction I got wrong in #62. There I forecast the v7/v8 rows would be red, they were green, and I reframed the risk as an over-broad green. The 1.7 route is one: found by running the widened suite against 1.7 before pushing, not by CI.

Verification

All four matrix combinations pass 11/11: 1.7.8.11, 8.2.8, 9.2.0 Hummingbird, 9.2.0 Classic. 332 unit tests green.

Every addition was checked able to fail, which is the point:

Remove	Result
the _common block	30 of 60 live checks red
accountLink from it	the logged-in step alone reddens
the v7 override	1.7 alone reddens
the parent spread in v7	the unit guard fails

Three of the six new theme tests failed before the change. The other three pin which tier wins on conflict — they passed while _common did nothing, so they are regression guards, not evidence, and are labelled as such.

What this does not cover

• Measured on one run per combination, not seven. The 7 runs per combination note in the workflow header describes the earlier 7-step suite; the two added steps do not have that behind them. The added steps touch registration and a session, which are noisier paths than navigation.
• These commits reached origin/dev without CI: both workflows fire on push to main or on a pull request, so a push to dev with no open PR triggers nothing. This PR is the first runner-side check — local greens are not runner greens, which is exactly where a timing-sensitive step can differ.
• Local runs were briefly red for an unrelated reason: post-reboot Spotlight indexing pushed load average to 27 and POST /cart returned 499. The unmodified suite from HEAD failed identically, which is how that was separated from the change.
• Back-office pages get no _common block. Only the front-office area was measured.

🤖 Generated with Claude Code