Skip to main content
Krodox
Back to writing

Upgrading to Statamic 6: what actually breaks

Krodox Team July 17th, 2026 Statamic Laravel

Statamic 6 requires PHP 8.3 and Laravel 12 or 13. We upgraded this site from Statamic 5 recently, and this is what the process actually involved rather than what the changelog promises.

The short version: if your site is mostly content and templates, the upgrade is small. If you have built custom control panel screens or Vue components, it is not.

The control panel is a different application

The control panel moved from Vue 2 to Vue 3, and custom pages now render through Inertia rather than Blade. Blade-rendered pages still work but trigger full page reloads instead of SPA transitions, and utilities move from ->view() to ->inertia().

This is the single change that decides how hard your upgrade is. A site with no custom CP code — ours has none — is unaffected. A site with bespoke fieldtypes or admin screens is looking at a Vue 2 to Vue 3 migration, which is real work with its own upgrade guide.

Two related removals: the Breadcrumb class is gone, with breadcrumbs now derived from control panel navigation, and Moment.js has been dropped entirely in favour of native date handling.

Globals were restructured

On a single-site install, global variables now live in a default subdirectory, with the original file keeping only configuration:

content/globals/seo.yaml          ->  configuration only
content/globals/default/seo.yaml  ->  the actual values

Multi-site installs describe their localizations through a sites array. Ours is bilingual, and Statamic rewrote the files itself during the upgrade — the root file kept title and a sites map, and the per-locale values stayed where they were.

The events changed with it: listen for GlobalVariablesSaving, GlobalVariablesCreated and GlobalVariablesSaved rather than the old GlobalSet* events. GlobalSet::addLocalization() and removeLocalization() are replaced by in() with save() or delete().

Search configuration will stop your build

This one is worth knowing in advance because it fails loudly, mid-upgrade:

'searchables' => 'all' is no longer supported.

all used to include users alongside content. It now throws, and you must be explicit — either 'content' for entries, terms and assets, or a list:

'searchables' => ['collection:blog', 'taxonomy:tags'],

Ours failed on statamic:search:update during composer update, which is a good place for it to fail: obvious, immediate, and fixed in one line.

Dates are now UTC at runtime

Statamic 6 converts dates to UTC at runtime. If your config/app.php timezone is not UTC, dates will appear shifted — stored in the application timezone, displayed as UTC. The fix is to add 'localize_dates_in_modifiers' => true to config/statamic/system.php.

The control panel also now shows dates in the user's own operating system timezone rather than the application's. That is more correct and will still surprise an editor who expects otherwise.

Smaller changes worth checking

  • Bard: inline: break splits into inline: true plus inline_hard_breaks: true. Strikethrough now outputs <strike> rather than <s> — check your CSS selectors.
  • Entry queries: ->where('status', ...) throws. Use ->whereStatus().
  • URL encoding: urlencode and rawurlencode now encode forward slashes. Use the _except_slashes variants to keep the old behaviour.
  • Wildcard tags: {{ session:foo }} treats foo as a literal string. Use {{ session :handle="foo" }} for dynamic values.
  • Super users no longer bypass every authorization check globally, only Statamic's. Restore the old behaviour with a Gate::before() hook if you relied on it.
  • Glide 3 brings intervention/image 3.x, so custom manipulators need updating.
  • Cache driver: replace 'driver' => 'statamic' with 'driver' => 'file'.

Database-backed users gain two-factor and passkey migrations — run php artisan migrate and add a 'two_factor_confirmed_at' => 'datetime' cast to the User model. File-driver installs like ours skip this entirely.

What it cost us

Two config edits and one content restructure that Statamic performed itself. The version chain was the expensive part, not Statamic: Statamic 5 caps at Laravel 12, so moving to Laravel 13 forced Statamic 6, which forced majors of both our addons.

If you are planning this, do the dependency audit first. The CMS upgrade is rarely the thing that surprises you.