fix: scope calendar progressive day-loader to caller date range#228
Merged
fix: scope calendar progressive day-loader to caller date range#228
Conversation
When a caller passes explicit date_start/date_end to the calendar REST endpoint (the progressive day-loader's per-day fetch), CalendarAbilities ignored the caller's range for pagination boundaries. compute_unique_event_dates() built SQL without applying date_start/date_end, then PageBoundary returned "page 1" boundaries (e.g. May 3..May 7), and the progressive branch rewrote query_params['date_start']/'date_end'] to page_dates[0] (May 3). The actual event query returned May 3 events, the renderer emitted 5 date groups, and the frontend day-loader picked the first .data-machine-events-wrapper out of the response and injected May 3's events under May 4, May 5, May 6, May 7. Backend: when user_date_range is true, honor the caller's range as authoritative, skip pagination boundary computation and the progressive branch entirely, and scope events_per_date / total_event_count / date_boundaries to the requested range so the counter and pagination metadata reflect what was asked for. Non-progressive page-1 path is unchanged. Frontend: scope the wrapper lookup in injectDayHtml() to .data-machine-date-group[data-date="$date"] so the wrong day's wrapper can never be injected even if the backend regresses.
Member
Author
|
Ready for review <@532385681268408341> |
Contributor
Homeboy Results —
|
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.
Fixes #227.
Summary
The
/wp-json/datamachine/v1/events/calendarendpoint ignoreddate_start/date_endfor pagination boundaries. When the frontend day-loader fetched a single deferred day, it got back the full 5-day calendar page and injected the wrong day's events under every deferred shell. User-visible symptom on https://events.extrachill.com: events from May 3 appeared duplicated under May 4, May 5, May 6, and May 7. Same on every location archive (e.g. Charleston with geo filter).Root cause (3 cooperating bugs from #227)
compute_unique_event_dates()ignored the caller's date range — built SQL only fromshow_past, taxonomy, and geo, sounique_dateswas always the full upcoming universe.PageBoundary::get_date_boundaries_for_page()returned canonical "page 1" boundaries (May 3..May 7) regardless of what the caller asked for, and theprogressivebranch then overwrotequery_params['date_start']/['date_end']topage_dates[0](May 3). The actual event query returned May 3 events, the renderer emitted 5 date groups, and the counter said "Viewing May 3 - May 7" for a single-day request.day-loader.ts::injectDayHtml()picked the first.data-machine-events-wrapperout of the response viaquerySelector. Even with the backend fixed, this would happily inject the wrong day if a response ever contained multiple wrappers.Fix
Backend —
inc/Abilities/CalendarAbilities.php::executeGetCalendarPage()When
user_date_rangeis true (caller passed an explicitdate_startand/ordate_end):query_params['date_start']/['date_end'].progressivebranch entirely (the day-loader is already asking for a single day; nothing to defer).events_per_dateand recomputetotal_event_countto only include dates inside the requested range, so the counter and pagination metadata reflect what was actually asked for.date_boundariesto the caller's range withmax_pages = 1.When
user_date_rangeis false, behavior is unchanged: pagination + progressive deferral on page 1 still produce the full 5-day spread on first paint of the homepage / archives.Frontend —
inc/Blocks/Calendar/src/modules/day-loader.ts::injectDayHtml()Scope the source wrapper lookup to the matching date group (defensive against backend regressions):
Before / after
Before: 5 date groups (May 3, 4, 5, 6, 7), all events inside the May 3 group, the others empty/deferred. Counter: "Viewing May 3 - May 7 (500 of 31783 Events)".
After: one date group (May 4), only events whose start falls on May 4 (with late-night cutoff applied). Counter scoped to the requested range.
Validation
php -l inc/Abilities/CalendarAbilities.php— no syntax errors.homeboy lint data-machine-events --path <worktree> --changed-since origin/main— PHPCS findings on my changed file reduced to only the 4 pre-existing findings (lines 376, 478, 479, 666). PHPStan passed. The 15 ESLint findings onday-loader.tsare pre-existing JSDoc/dependency-group warnings on lines I didn't touch.npm run buildininc/Blocks/Calendar— webpack compiled successfully (74.7 KiB frontend bundle). Build artifacts are gitignored per repo convention; the deploy pipeline /homeboy buildproduces them.?date_start=2026-05-04&date_end=2026-05-04confirms the new branch setsquery_params['date_start']/['date_end']to2026-05-04, filtersevents_per_dateto May 4 only, setsdate_boundariesto May 4..May 4 withmax_pages = 1, and skips the progressive branch entirely.elsebranch and is functionally unchanged: samePageBoundarycall, samerange_start/range_endlogic, same progressive-deferral kick-in for pages with ≥PROGRESSIVE_THRESHOLDevents.cc <@532385681268408341>