Does "Identify" layer state persist through Project → Share / shared project URLs?

[AMonteroUNAV]

Hi, thank you for building GeoLibre — really appreciate having a free, open alternative for this kind of work.

I'm running into an issue with the per-layer "Identify features" toggle (the one that opens a popup with feature attributes on click).

Steps to reproduce:

1. Load a vector layer (in my case, a GeoJSON polygon layer with clean property names).
2. Enable "Identify features" on that layer — confirmed working, clicking a feature opens the popup correctly.
3. Project → Share, upload to share.geolibre.app.
4. Open the resulting share.geolibre.app URL (same browser session, immediately after sharing).
5. Click the same feature — no popup appears.

I also tested this with the ?url=...&maponly embed parameter, same result.

Is "Identify enabled" per layer expected to be part of the saved/shared project state? I couldn't find it listed among the things documented as persisted (view, basemap, layers, styles, controls like scale bar/legend/HTML overlays, etc.), so I want to confirm whether this is:
(a) expected behavior (identify is session-only, by design), or
(b) a gap that should be tracked as a bug/feature request.

If it's (a), is there a recommended way to give viewers of a shared/embedded map click-to-inspect functionality without the full editing UI? A custom HTML popup approach, or something in the plugin API, would also be a helpful pointer.

Thanks!

[giswqs]

If you use the Add Vector Layer panel to load data, popup is enabled by default, and it will be persisted in shared project.

Try this: https://web.geolibre.app/?url=https://share.geolibre.app/giswqs/vector-popup-demo.geolibre.json&maponly

[AMonteroUNAV]

Follow-up with a more precise repro, using three screenshots of the same shared project at different stages.

First, confirming your earlier suggestion worked: I reloaded the layer via the "Add Vector Layer" panel (instead of drag-and-drop) and enabled Popup there — the popup now works correctly and persists in the shared project. Thank you for that.

However, I've found a separate issue, specific to &maponly:

1. Full editor view (editing session) — renders correctly, both the choropleth polygon layer (colored by development level) and the graduated circle layer show properly, matching the Legend.

2. Shared project URL, full UI (share.geolibre.app, no maponly) — also renders correctly, same as above.

3. Same shared URL with &maponly — the graduated circle (point) layer renders correctly (right sizes, right positions), and the Legend component renders fully and correctly (including the choropleth color swatches) — but the choropleth polygon layer itself shows no fill at all. Countries appear as the plain basemap terrain color instead of the level-based color scheme.

So this seems more specific than a general "nothing loads" issue — in maponly mode specifically, it's the polygon fill layer that fails to paint on load, while the point layer and the Legend UI component (which is presumably reading the same style/classification) both work fine. Both layers were loaded via the Add Vector Layer panel, not drag-and-drop.

Workaround I found: even in maponly, if I open the layer selector and toggle that polygon layer's visibility off and back on, it repaints correctly. So the style/classification itself is fine — it's specifically the initial paint on load that fails. This isn't a usable workaround for a real deployment though, since maponly is meant for embedded/public viewers (e.g. someone scanning a QR code to a museum/report display) who won't have access to a layer selector to do this manually.

Screenshots attached in order (1: editor, 2: shared/full UI, 3: shared/maponly, 4: maponly with layers edited).

[giswqs]

Can you share the link to the project file?

[AMonteroUNAV]

Sure, here's the project link:
https://share.geolibre.app/amontero/world-map-of-paediatric-palliative-care-development.geolibre.json

One more data point that might help: I just reopened the &maponly URL again (without touching or changing anything since my last message) and this time the polygon layer painted correctly on load, no toggling needed.

So the bug seems intermittent rather than 100% reproducible — sometimes it loads correctly, sometimes it doesn't. That fits with it possibly being a timing/race condition (style applied before the vector source fully loads), as I guessed earlier, rather than something wrong with the layer/style configuration itself.

Let me know if there's anything else useful I can check or send over.