[BUG] When editing an item, the "Location Display Name" resets

[SethGower]

🐞 Bug Description

After creating a "Location", I add the actual address to the "Location Display Name" so that I can use this easily to navigate with a map app. However if I later go and edit a location, then the display name resets back to some description of it, I think generally the city, state/province.

🔄 Steps to Reproduce

Steps to reproduce the behavior:

1. Create a new Location (formerly "Adventure")
2. Set a real location for it, possibly by searching for a landmark in the first page. For example below, I used the Louvre
3. Set the Location Display Name to be something other than what is automatically populated
4. Save the location
5. Reopen the Location by hitting the three dots -> "Edit Location"
6. After a couple of seconds, the display name gets overwritten with something way more generic
7. Observe the error

✅ Expected Behavior

I expect it to maintain what I manually put in the Display Name field. If it wasn't manually modified by me (or another user in the case of shared collections and such), then it's fine if AdventureLog modifies it if for some reason it changed (although I don't see this happening)

📸 Screenshots / Logs

Below is a screen shot of an example I created for the Louvre Museum

This following is a screencast of the bug happening. Notice that in the overview / list page, it shows the address (75001 Paris, France), however when I attempt to edit the location, the display name gets overwritten to "Paris, Île-de-France, FR"

Screencast.From.2026-01-25.16-42-37.webm

I didn't see any logs come through for adventurelog-frontend.service when I tried to edit, and I was following the log with journalctl -u adventurelog-frontend.service -f

🐳 Environment Details

• Platform: Proxmox
• Install Method: Quick Install Script
• AdventureLog Version: v0.11.0
• Reverse Proxy: Caddy

📎 Additional Context

I am using an external PostgreSQL database that I have hosted in another VM for central DB access across services. However I doubt this is related at all.

[madmp87]

Hey @seanmorley15! 👋

Fixed the collection filter UI reset issue:

Root Cause: SvelteKit reactive blocks ($:) were resetting UI state before server data loaded on navigation, causing filter/sort state to appear broken.

Fix:

1. Replaced $: reactive block with afterNavigate() for URL sync
2. Added full state synchronization after every navigation event
3. Fixed orderDirection default mismatch (asc → desc)
4. Added visual indicators for active filters on mobile and sidebar
5. Removed debug console.log statements

Technical changes:

• collections/+page.svelte: Added afterNavigate() callback for state sync
• Collections data arrays (adventures, shared, archived) now persist across navigation
• Pagination state (next, previous, count, currentPage) synchronized
• Filter/sort parameters from URL preserved

Status:

• ✅ Implemented and tested locally
• ✅ Collection filter UI now works reliably across all navigation methods
• 🔄 Will be included in upcoming PR bundle

Thanks!

[madmp87]

Fix submitted in PR #1009

Root Cause

The collections page (collections/+page.svelte) manually synced local state variables (like collections, orderBy, orderDirection, statusFilter) inside each navigation function (goToPage, updateSort, updateStatusFilter). When using browser back/forward or deep links, the local state fell out of sync with the server data because those code paths weren't hit.

Additionally, orderDirection defaulted to 'asc' while the server default was 'desc', causing a mismatch on initial load.

Changes

• collections/+page.svelte: Add centralized afterNavigate() callback that syncs all local state (collections, sharedCollections, archivedCollections, count, currentPage, orderBy, orderDirection, statusFilter, invites) from data.props after every navigation event
• Remove duplicate state-sync logic from goToPage(), updateSort(), and updateStatusFilter() — these now only set optimistic values and call goto()
• Fix orderDirection default from 'asc' to 'desc' to match server behavior
• Add visual badge indicator for active filters on both mobile hamburger button and sidebar header
• Remove leftover debug console.log

Testing

• Apply sort/filter on collections page → navigate away → navigate back → state is preserved
• Browser back/forward → filter and sort state matches URL params
• Mobile: active filter shows dot indicator on filter button

[madmp87]

Update: PR #1009 has been rebased onto origin/development to resolve merge conflicts. The branch is now clean and both CI tests (Backend + Frontend) pass.

Fixed in PR #1009 — Collection filter state now persists across navigation. An afterNavigate callback syncs all filter/sort/data state, and the orderDirection default mismatch was corrected.