"Unsaved changes" browser dialog on create→edit redirect leads to "slug already taken" error on retry

[buddy94]

Bug description

When saving a new entry in the Control Panel, Statamic correctly creates the entry and redirects from the create page to the edit page. However, intermittently, the browser fires a native beforeunload "You have unsaved changes — leave anyway?" dialog during this redirect.

• If the user clicks OK (leave), the redirect completes normally and everything is fine.
• If the user clicks Cancel (stay on the create page) and then tries to save again, they get an error: "The slug has already been used." — even though the entry was actually created successfully during the first save.

The browser dialog seems to appear because the CP's Vue/JS state still considers the form "dirty" at the moment the redirect is triggered, even after a successful save. The entry is created in the database, but the user is left stranded on the create form with no way to save again without a slug conflict.

This is intermittent — the vast majority of saves work correctly. We haven't been able to identify a consistent reproduction pattern.

How to reproduce

1. Open a collection (we observe it on the news collection) and click Create entry.
2. Fill in several fields and click Save.
3. Watch for the browser's native "You have unsaved changes, do you want to leave?" dialog appearing during the redirect from the create page to the edit page.
4. Click Cancel (stay on page).
5. Attempt to save again from the still-open create form.
6. Result: Error — "The slug has already been used." The entry was already created in step 2.

The bug is intermittent. We cannot reliably reproduce it on demand, but it happens regularly in production authoring workflow.

Logs

Environment

Environment
Application Name: CATH DEMO
Laravel Version: 13.1.1
PHP Version: 8.4.18
Composer Version: 2.9.5
Environment: production
Debug Mode: OFF
URL: demo.cath.ancom.ch
Maintenance Mode: OFF
Timezone: UTC
Locale: fr

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: redis
Database: mysql
Logs: stack / single
Mail: smtp
Queue: redis
Scout: collection
Session: file

Storage
public/storage: LINKED

Pulse
Enabled: ENABLED
Version: v1.7.2

Livewire
Livewire: v4.2.1

Statamic
Addons: 11
Sites: 1
Stache Watcher: Disabled (auto)
Static Caching: half
Version: 6.7.1 PRO

Statamic Addons
ancom/admin-toolbar: dev-main
ancom/analytics-dashboard: dev-dev
ancom/homepage-editor: dev-dev
ancom/newsletter-manager: dev-dev
ancom/tutorial: dev-dev
cboxdk/statamic-mcp: 2.0.2
statamic/eloquent-driver: 5.4.2
statamic/importer: 2.1.0
studio1902/statamic-peak-commands: 10.5.0
studio1902/statamic-peak-seo: 11.0.2
studio1902/statamic-peak-tools: 9.0.2

Statamic Eloquent Driver
Addon Settings: file
Asset Containers: eloquent
Assets: eloquent
Blueprints: file
Collection Trees: file
Collections: file
Entries: eloquent
Fieldsets: file
Form Submissions: file
Forms: file
Global Sets: file
Global Variables: file
Navigation Trees: eloquent
Navigations: eloquent
Revisions: file
Sites: file
Taxonomies: eloquent
Terms: eloquent
Tokens: file

Installation

Starter Kit using via CLI

Additional details

Revisions: Enabled on the affected collection.

Eloquent Driver: Entries are stored in the database via statamic/eloquent-driver (Entries: eloquent, Revisions: file).

Custom EntrySaving / EntrySaved listeners registered on the collection:

Listener	Event	What it does
ValidateNewsFieldsBeforePublishing	EntrySaving	Validates required fields before publishing. For new entries that fail validation, throws a 422 without saving to avoid exactly this slug-conflict issue. For existing entries, forces draft and saves.
ValidateNewsAfterSaving	EntrySaved	Re-runs a custom validation service after save and stores results in the session for display in the editor. Cleans up session keys used during the create flow.
DispatchPostNewsPublishJob	EntrySaved	Dispatches a queued job to invalidate frontend caches (homepage, tags) and update the Algolia search index. Supports scheduled publication dates with a delay.
PublishNewsToSocials	EntrySaved	Schedules a queued job to publish the news to configured social media channels.
InvalidateTagsCacheOnEntrySaved	EntrySaved	Invalidates the taxonomy tags cache.
InvalidateHomepageCacheOnEntrySaved	EntrySaved	Invalidates the homepage Antlers cache.
InvalidateNewsTagsCache	EntrySaved	Invalidates the news tags cache.

Statamic v5: We had the same setup (revisions, listeners) on Statamic 5 and never observed this issue. It started occurring only after upgrading to Statamic 6.

Questions:

• Is this a known issue with the CP's beforeunload / dirty-state handling on the create→edit redirect in v6?
• Do you have any guidance on how to debug why the form is considered dirty at redirect time, or how to hook into the JS side to trace when/why the dialog appears?

[duncanmcclean]

Are you able to provide the YAML for your news collection's blueprint? It's possible there's a fieldtype on there mistakingly marking itself as dirty right after the save.

[buddy94]

Thanks for the quick reply!

I believe I've identified the root cause — and I've already fixed a related manifestation of the same bug. Let me share what I found.

The custom fieldtype: news_validation_errors

The blueprint includes a custom fieldtype news_validation_errors in the Sidebar tab (see attached YAML). This fieldtype renders a validation widget that shows whether the news article is ready to publish.

The blueprint:
news.yaml

In the old implementation, preProcess() dynamically ran a validation service and returned a non-trivial array:

// OLD — caused dirty state issues
public function preProcess($data): array
{
    $errors = $service->validateNews($entryToValidate);
    return ['errors' => $errors, 'has_been_validated' => true];
}

The Vue component then read from this.value. After a save, Statamic calls preProcess() on all fields to build the response. The returned array could differ slightly from the previous value (different field order, working copy vs. base entry, etc.), causing the Container's deep watcher to fire dirty() — resulting in a false "unsaved changes" state.

Fix I already applied before I opened this ticket (edit mode)

I fixed edit-mode dirty state by moving validation out of preProcess():

• preProcess() now always returns null (stable, never triggers dirty)
• preload() handles the initial validation at page load (populates this.meta, which is not dirty-tracked)
• A hook on entry.saved fires an AJAX GET to a dedicated endpoint to refresh the widget after each save

This fixed the false dirty warning when editing an existing entry. I committed this fix on March 24.

The create→edit redirect bug (still present)

However I reported this issue because I still observe the dialog during the create→edit redirect, even after the fix above.

My current theory: during creation, Statamic responds with a redirect (not a JSON response), so the preProcess() response-based flow doesn't apply. The redirect happens at the Vue/router level in v6. If any watcher fires between clearDirtyState() and the actual navigation, the beforeunload dialog can appear.

The bug is intermittent, which is consistent with a race condition between clearDirtyState() and the router navigation.

Key difference vs. Statamic 5: We had the exact same setup on v5 (same listeners, same collection, same blueprint) and never saw this issue. It started with v6. This suggests the create→edit redirect mechanism changed in v6 (possibly from a full page navigation to a Vue router push), making the timing window for this race condition more likely to occur.

Reproducibility: We cannot reliably reproduce it on demand. It happens regularly in production authoring workflow, roughly a few times a week across our editorial team.

Summary

Scenario	Status
False dirty on edit (existing entry)	✅ Fixed — preProcess() → null
False dirty on create→edit redirect	❌ Still occurring

Happy to provide more details or test a specific build if that helps narrow it down.