Skip to content

v4.4.8 - Preserve Site → Page navigation context

Choose a tag to compare

@tallcms tallcms released this 01 May 05:14
· 23 commits to main since this release

Bug Fix / UX

When a user enters the page editor from a Site relation manager (Sites → Site → Pages → Edit or Create), the receiving Filament page now keeps the originating-site context — instead of dropping the user into the global Pages resource with no breadcrumb back.

  • New HasFromSiteContext trait captures ?from_site=<id> once at mount() into a public Livewire property — durable across /livewire/update round trips, so save / delete redirects don't silently lose context.
  • EditCmsPage and CreateCmsPage now show "Editing within site: " as a subheading, expose a "Back to site" header action, and redirect after save / delete / force-delete to the originating Site edit URL instead of the global Pages index.
  • CmsPage::hasSiteIdColumn() exposed as public; site() belongsTo relation added; 'site_id' => 'integer' cast added so loose Eloquent typing doesn't break validation.

Safety

  • Single-site installs: trait's first guard checks CmsPage::hasSiteIdColumn(). When the multisite migration hasn't added the column, every entry point returns null and lifecycle hooks fall through. Behaviour is identical to before.
  • Spoofed from_site: validated against the loaded record's site_id post-save (with a fallback to $ownerSiteId pre-save so the back action renders on Create before Save). A mismatched id falls through to default behaviour — no breadcrumb leak.
  • SiteResource URL resolution: try/catch around getUrl() on cms-core's SiteResource and the multisite plugin's SiteResource in turn. Hosts without either resource registered get null and the back action silently drops out — no RouteNotFoundException reaches the user.

Companion plugin release

The multisite plugin v2.3.0 (forthcoming) ships the ?from_site=<id> query addition on its PagesRelationManager. Hosts running the multisite plugin should update both core (this release) and the plugin to see the full UX. Either side can ship independently — old plugin + new core: trait stays inert because from_site is never sent. New plugin + old core: query param is ignored. No breakage in either combination.