nohype/main-site
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix admin messages never auto-dismissing (root cause) #66

Merged
mark merged 1 commits from fix/admin-messages-auto-dismiss-v3 into main 2026-03-19 10:59:41 +00:00
Conversation 0 Commits 1 Files Changed 2 +77 -33
claude commented 2026-03-19 10:55:55 +00:00
Member
Copy Link

Summary

PRs #54 and #64 attempted to fix persistent admin notifications but neither addressed the root cause. After thorough investigation:

  • Sessions are clean — no messages are stuck server-side. Django's messages framework correctly consumes messages when the template renders them.
  • The real bug is client-side — Wagtail's w-messages Stimulus controller has no connect() lifecycle method. Its autoClearValue only applies to messages added dynamically via JavaScript (the add() method). Server-rendered <li> elements — produced by Django's messages framework after a redirect — sit in the DOM indefinitely with no auto-dismiss.
  • PR #64's data-w-messages-auto-clear-value="8000" correctly handles dynamic messages but has zero effect on server-rendered ones.
  • PR #64's {% ifchanged %} de-duplication was cosmetic and doesn't address persistence.

Fix

  • Mark server-rendered message <li> elements with data-server-rendered
  • Add an inline <script> that queries those elements and removes them after 8 seconds (matching the dynamic message auto-clear timeout)
  • Clean up has-messages body class when all messages are gone
  • Remove the ineffective {% ifchanged %} de-duplication

Test plan

  • All 202 existing tests pass
  • New test verifies auto-dismiss script is present when messages are rendered
  • New test verifies all messages render (no filtering)
  • Manual: publish a page in admin → messages appear → messages auto-dismiss after ~8 seconds
  • Manual: create a snippet → message appears → auto-dismisses
  • Manual: navigate via sidebar after messages appear → clean page (no stale messages)
## Summary PRs #54 and #64 attempted to fix persistent admin notifications but neither addressed the root cause. After thorough investigation: - **Sessions are clean** — no messages are stuck server-side. Django's messages framework correctly consumes messages when the template renders them. - **The real bug is client-side** — Wagtail's `w-messages` Stimulus controller has no `connect()` lifecycle method. Its `autoClearValue` only applies to messages added dynamically via JavaScript (the `add()` method). Server-rendered `<li>` elements — produced by Django's messages framework after a redirect — sit in the DOM indefinitely with no auto-dismiss. - PR #64's `data-w-messages-auto-clear-value="8000"` correctly handles dynamic messages but has zero effect on server-rendered ones. - PR #64's `{% ifchanged %}` de-duplication was cosmetic and doesn't address persistence. ### Fix - Mark server-rendered message `<li>` elements with `data-server-rendered` - Add an inline `<script>` that queries those elements and removes them after 8 seconds (matching the dynamic message auto-clear timeout) - Clean up `has-messages` body class when all messages are gone - Remove the ineffective `{% ifchanged %}` de-duplication ## Test plan - [x] All 202 existing tests pass - [x] New test verifies auto-dismiss script is present when messages are rendered - [x] New test verifies all messages render (no filtering) - [ ] Manual: publish a page in admin → messages appear → messages auto-dismiss after ~8 seconds - [ ] Manual: create a snippet → message appears → auto-dismisses - [ ] Manual: navigate via sidebar after messages appear → clean page (no stale messages)
claude added 1 commit 2026-03-19 10:55:55 +00:00
Fix server-rendered admin messages never auto-dismissing
All checks were successful
CI / nightly-e2e (pull_request) Has been skipped
Details
CI / deploy (pull_request) Has been skipped
Details
CI / ci (pull_request) Successful in 1m25s
Details
CI / pr-e2e (pull_request) Successful in 1m24s
Details
ff587d9e1b 
Root cause: Wagtail's w-messages Stimulus controller only auto-clears
messages added dynamically via JavaScript (the add() method).  Server-
rendered messages — the <li> elements produced by Django's messages
framework after a redirect — have no connect() lifecycle handler and
sit in the DOM indefinitely.

PR #64 added data-w-messages-auto-clear-value="8000" which correctly
handles dynamic messages, but server-rendered ones were unaffected.
PR #64 also added {% ifchanged %} for de-duplication, which doesn't
address persistence.

Fix: mark server-rendered <li> elements with data-server-rendered and
add an inline script that removes them after 8 seconds (matching the
auto-clear timeout for dynamic messages).  Also remove the ineffective
{% ifchanged %} de-duplication.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
mark merged commit 92c1ee425d into main 2026-03-19 10:59:41 +00:00
mark deleted branch fix/admin-messages-auto-dismiss-v3 2026-03-19 10:59:42 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude codex_a codex_b codex_c mark
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: nohype/main-site#66
Delete Branch "fix/admin-messages-auto-dismiss-v3"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?