Add Sort Controls to Game List Entries #784

New issue

Closed

opened 2026-06-30 05:52:50 -05:00 by Veilor · 3 comments

Veilor commented

2026-06-30 05:52:50 -05:00

Member

Game list pages should let users sort entries the way the old site did, so members can quickly compare a list by name, rating, date added, priority, ownership type, or platform.

The current list view renders status sections from GameListSections and orders each section by game-list name, then id. The table already displays the fields users want to sort by, but the headers are static and load-more URLs do not carry any sort state.

Scope

User-owned and public game list pages.
Status tab sections and load-more behavior generated by GameListSections.
Desktop table sorting for Name, Rating, Date Added, Priority, Ownership Type, and Platform.
Mobile list/card behavior for the same sorted results.
Existing status tabs, owner actions, and list entry edit/delete routes.

Acceptance Criteria

Users can choose a sort field for visible game-list entries.
Supported sort fields include name, rating, date added, priority, ownership type, and platform.
Sorting works within the selected status tab and the All view sections.
Sort state is preserved when loading more rows.
Sort links or controls are accessible and clearly indicate the active sort direction.
Public profile list views and the signed-in owner list view use the same sorting behavior.
Existing status filtering, replaying sections, and owner-only edit/delete actions continue to work.

Test Coverage Required

Extend GameListPageTest to cover sorting by at least name, rating, date added, priority, ownership type, and platform.
Cover sort state in generated load-more URLs and load-more responses.
Cover sorting on both the owner list route and public user list route.
Preserve existing coverage for status tabs, preloaded panels, missing platform fallback, and owner actions.
Run focused game-list page tests before closing the issue.
Run vendor/bin/pint --dirty --format agent before implementation closeout if PHP files change.

Progress Checklist

Define allowed sort fields and directions for game lists
Add sorting to GameListSections queries
Add accessible sort controls to the desktop table and mobile-friendly behavior
Preserve sort state across status tabs and load-more requests
Add focused sorting and load-more regression coverage
Run focused GameListPageTest coverage
Run vendor/bin/pint --dirty --format agent if PHP files changed
Move the issue out of Codex review once verification is complete

Implementation verification and re-review (2026-10-16)

Re-reviewed the implementation against the description, all acceptance criteria, and required test coverage. All six sort fields work in both directions on owner and public routes, independently within status tabs and All-view sections. Sort state survives tab links, partial requests, cached/preloaded panels, browser history, and load-more URLs/responses. Desktop controls expose the active direction through chevrons and aria-sort; inactive chevrons appear on hover and keyboard focus. Mobile controls sort the same results. Existing status/replaying filtering, missing-platform fallback, owner-only actions, and authorization coverage remain intact.

The re-review found and fixed a browser-test portability issue: Forgejo sets MariaDB as the default connection, whereas the original browser renderer assumed an existing local SQLite database. Browser fixtures now migrate their own in-memory SQLite database and ignore inherited database connection names, URLs, and database names. No existing database or .env.testing file is required for those fixtures.

Added regression coverage for every status tab on both routes and for 201-entry replaying lists across three cursor pages in both directions for all six fields. These cases verify mixed sort values, missing values, exact row ordering without duplicates or omissions, All-section continuation, and subsequent next_url state.

A further review reproduced and fixed a browser-history bug: returning to the initial URL without a status hash could leave the previous tab visible. Tab restoration now handles native popstate events and resolves the selected status from both the hash and query string. Load-more also blocks repeated keyboard activation while a request is pending and ignores responses/errors for a panel that has since been replaced. The four browser scenarios now exercise these cases on owner/public routes at both widths.

Verification passed:

168 focused GameListPageTest tests, 2,103 assertions.
Four Chromium browser scenarios: public and owner lists at 375px and 1440px, including hover/focus styling, sort changes, cached tabs, back/forward navigation to the initial URL without a hash, pagination resets, repeated keyboard activation, delayed responses after switching tabs, and load-more.
vendor/bin/pint --dirty --format agent.
composer stan.
npm run build passed after the final JavaScript history and load-more fixes.
git diff --check.

All eight progress checklist items are complete. PR #980 was merged by jimmyb as b5df1dd36d91cb271b39f83c7a65473b41e55326. The issue is closed with status/done; local master has been pulled. Dev and production are deployed at the merged revision. Checksums, Blade caches, release manifests, live HTTP/assets, and read-only MariaDB sorting/pagination checks passed on both environments. Existing dev-only changes were preserved. See the deployment comment for rollback locations and verification details.

Game list pages should let users sort entries the way the old site did, so members can quickly compare a list by name, rating, date added, priority, ownership type, or platform. The current list view renders status sections from `GameListSections` and orders each section by game-list name, then id. The table already displays the fields users want to sort by, but the headers are static and load-more URLs do not carry any sort state. ## Scope - User-owned and public game list pages. - Status tab sections and load-more behavior generated by `GameListSections`. - Desktop table sorting for Name, Rating, Date Added, Priority, Ownership Type, and Platform. - Mobile list/card behavior for the same sorted results. - Existing status tabs, owner actions, and list entry edit/delete routes. ## Acceptance Criteria - Users can choose a sort field for visible game-list entries. - Supported sort fields include name, rating, date added, priority, ownership type, and platform. - Sorting works within the selected status tab and the All view sections. - Sort state is preserved when loading more rows. - Sort links or controls are accessible and clearly indicate the active sort direction. - Public profile list views and the signed-in owner list view use the same sorting behavior. - Existing status filtering, replaying sections, and owner-only edit/delete actions continue to work. ## Test Coverage Required - Extend `GameListPageTest` to cover sorting by at least name, rating, date added, priority, ownership type, and platform. - Cover sort state in generated load-more URLs and load-more responses. - Cover sorting on both the owner list route and public user list route. - Preserve existing coverage for status tabs, preloaded panels, missing platform fallback, and owner actions. - Run focused game-list page tests before closing the issue. - Run `vendor/bin/pint --dirty --format agent` before implementation closeout if PHP files change. ## Progress Checklist - [x] Define allowed sort fields and directions for game lists - [x] Add sorting to `GameListSections` queries - [x] Add accessible sort controls to the desktop table and mobile-friendly behavior - [x] Preserve sort state across status tabs and load-more requests - [x] Add focused sorting and load-more regression coverage - [x] Run focused `GameListPageTest` coverage - [x] Run `vendor/bin/pint --dirty --format agent` if PHP files changed - [x] Move the issue out of Codex review once verification is complete ## Implementation verification and re-review (2026-10-16) Re-reviewed the implementation against the description, all acceptance criteria, and required test coverage. All six sort fields work in both directions on owner and public routes, independently within status tabs and All-view sections. Sort state survives tab links, partial requests, cached/preloaded panels, browser history, and load-more URLs/responses. Desktop controls expose the active direction through chevrons and aria-sort; inactive chevrons appear on hover and keyboard focus. Mobile controls sort the same results. Existing status/replaying filtering, missing-platform fallback, owner-only actions, and authorization coverage remain intact. The re-review found and fixed a browser-test portability issue: Forgejo sets MariaDB as the default connection, whereas the original browser renderer assumed an existing local SQLite database. Browser fixtures now migrate their own in-memory SQLite database and ignore inherited database connection names, URLs, and database names. No existing database or .env.testing file is required for those fixtures. Added regression coverage for every status tab on both routes and for 201-entry replaying lists across three cursor pages in both directions for all six fields. These cases verify mixed sort values, missing values, exact row ordering without duplicates or omissions, All-section continuation, and subsequent next_url state. A further review reproduced and fixed a browser-history bug: returning to the initial URL without a status hash could leave the previous tab visible. Tab restoration now handles native popstate events and resolves the selected status from both the hash and query string. Load-more also blocks repeated keyboard activation while a request is pending and ignores responses/errors for a panel that has since been replaced. The four browser scenarios now exercise these cases on owner/public routes at both widths. Verification passed: - 168 focused GameListPageTest tests, 2,103 assertions. - Four Chromium browser scenarios: public and owner lists at 375px and 1440px, including hover/focus styling, sort changes, cached tabs, back/forward navigation to the initial URL without a hash, pagination resets, repeated keyboard activation, delayed responses after switching tabs, and load-more. - vendor/bin/pint --dirty --format agent. - composer stan. - npm run build passed after the final JavaScript history and load-more fixes. - git diff --check. All eight progress checklist items are complete. PR #980 was merged by jimmyb as `b5df1dd36d91cb271b39f83c7a65473b41e55326`. The issue is closed with status/done; local master has been pulled. Dev and production are deployed at the merged revision. Checksums, Blade caches, release manifests, live HTTP/assets, and read-only MariaDB sorting/pagination checks passed on both environments. Existing dev-only changes were preserved. See the deployment comment for rollback locations and verification details.

Veilor added the

Rows
Columns