fix: style --ap-address and --handle identity-token modifiers (issue 163 Part B)#180
Merged
Conversation
…163 Part B) Extends the existing `.fosse-token--host` / `.fosse-admin-token--host` font-weight: 500 rule so it also covers the `--ap-address` and `--handle` modifier variants (plus their `fosse-status-card__token--*` siblings, which are emitted by `class-bluesky-provider.php` and `class-ap-provider.php`). Resolves the load-bearing-but-invisible state where call sites emitted modifier classes that the test regex pinned but no stylesheet rule honored. Also extends `provide_identity_token_modifier_selectors` in `Admin_CSS_Test.php` so the existing data-provider contract test (which exists precisely to catch "selector emitted in PHP but missing from admin.css") covers the six new selectors. Future accidental deletion of any of them now fails a test instead of slipping through silently. Part A of issue 163 (handle-shape defense in `Bluesky_Provider::get_status()`) is already on trunk and is not part of this PR. See issue 163
Contributor
There was a problem hiding this comment.
Pull request overview
Adds missing styling support for emitted identity-token modifier classes in the wp-admin UI, and extends the existing CSS contract test so future regressions (classes emitted in PHP but not styled) are caught automatically.
Changes:
- Extend
admin.cssto applyfont-weight: 500to--ap-addressand--handletoken modifiers (including status-card variants), matching existing--hostbehavior. - Expand
Admin_CSS_Test’s data provider to require CSS rules for the newly-styled modifier selectors.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
tests/php/Admin/Admin_CSS_Test.php |
Extends the modifier-selector data provider to assert CSS rules exist for --handle and --ap-address (including status-card variants). |
src/Admin/assets/css/admin.css |
Adds --ap-address and --handle selectors to the existing font-weight: 500 modifier rule set. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolves Part B of issue 163 — the leftover unstyled identity-token modifier classes called out by the PR 161 maintainability review.
Part A of the issue (handle-shape defense moved into
Bluesky_Provider::get_status(), plus its unit test) is already on trunk and not part of this PR.What this PR ships
CSS: style the
--ap-addressand--handlemodifierssrc/Admin/assets/css/admin.csshad a font-weight: 500 rule for.fosse-token--host/.fosse-admin-token--host. The matching modifiers for--ap-addressand--handlewere being emitted by every call site (class-ap-provider.php,class-bluesky-provider.php,class-onboarding-wizard.php) and pinned by regex assertions inOnboarding_WizardTest.php, but no stylesheet rule honored them. They were load-bearing for tests yet invisible to users — the worst of both worlds.Extended the existing selector list to include all six emitted variants:
The
fosse-status-card__token--*variants are included because grep against the source tree confirmedclass-ap-provider.phpandclass-bluesky-provider.phpboth emit them on real render paths. No status-card variant of--hostis emitted anywhere, so it's deliberately absent from the rule.Test: extend the data-provider contract guard
tests/php/Admin/Admin_CSS_Test.phphastest_identity_token_modifiers_have_css_rules, a data-provider-driven test built precisely to catch the "class emitted in PHP but missing from admin.css" gap this PR is fixing. The provider only listed--host. Extended it to include all six newly-styled selectors so future accidental deletion of any of them fails a test instead of slipping through silently. PHPUnit confirms: 9 tests, 18 assertions, all green.What this PR does not do
The code-review pass caught one additional concern that's intentionally out of scope:
--didand--urlmodifier classes are also unstyled. They're emitted at four call sites inclass-bluesky-provider.php(lines 429, 437, 801, 811) but have no CSS rule of their own. The issue body claimed they were already styled — that's stale info from before the CSS file was restructured. Adjacent to the now-styled--handlesiblings in the same Bluesky status-card surface, the unstyled--did/--urlwill read as visually quieter, which may or may not be the right call (DIDs and URLs are opaque references, not identity strings — the typographic distinction is arguably correct). Worth a separate decision in its own follow-up, not silently in this one.Test plan
vendor/bin/phpunit --filter Admin_CSS_Test— 9 tests, 18 assertionsvendor/bin/phpunit --filter Bluesky_ProviderTest— 131 tests, 345 assertionsvendor/bin/phpunit --filter Onboarding_WizardTest— 106 tests, 414 assertionstools/vendor/bin/phpcs tests/php/Admin/Admin_CSS_Test.php— cleanpnpm exec prettier --check src/Admin/assets/css/admin.css— clean@user.bsky.socialhandles and@user@example.comAP addresses render with the same bold treatment as host tokensReview
Ran
/ce-code-review(multi-agent) and/codex challenge(adversarial). Round 1 surfaced one cross-reviewer finding (theAdmin_CSS_Testdata provider gap, called out independently by correctness, testing, and maintainability) — addressed in this same PR. Codex challenge round returned no production failures. Single-reviewer--did/--urlconcern carried forward as a known follow-up above.Fixes #163