[brandonkelly]

Note

This builds on #20061 (Sites pane), which should be merged first.

Adds a “Propagation Method” setting to asset volumes, similar to sections, with two options:

• Save assets to all sites (all)
• Let each asset choose which sites it should be saved to (custom)

New volumes default to custom. Existing volumes are set to custom on single-site installs (where nothing changes until a site is added), and keep all on multi-site installs, so new uploads there continue to be saved to all sites.

With custom, new assets are only saved to the site they were uploaded from, and can be added to other sites from the Sites pane on the asset’s edit page (from #20061). This avoids creating elements_sites, assets_sites, and search index rows for every site when assets don’t need to exist in all of them.

Related to #19761

Changes

• Added craft\models\Volume::$propagationMethod, stored in project config and a new volumes.propagationMethod column. Only all and custom are valid.
• The migration sets existing volumes to custom on single-site installs and all on multi-site installs, and records that in project config for any volumes that don’t have the setting yet. Volume configs without the setting are still treated as all, and the temporary uploads volume always uses all.
• Assets in custom volumes return true from hasCustomPropagation(), so their Sites pane is shown even once they’ve been saved to all sites.
• craft\elements\Asset::getSupportedSites() now follows the volume’s propagation method, mirroring how entries handle custom.
• When a volume is switched from custom to all, its assets are resaved so they get propagated to all sites.
• Assets are now saved to the site they were uploaded from (the asset index and Assets fields now send the current site ID).
• craft\services\Assets::getAssetById() now falls back to other sites when no site ID is passed and the asset doesn’t exist in the current site.
• Internal lookups that shouldn’t depend on the current site (asset indexing, filename conflict checks, folder moves and deletions, thumbnails, transforms, the image editor, user photos, volume deletion/restoration, etc.) now find assets regardless of which sites they exist in.
• Assets in custom volumes have a “Delete for site” action (index action and edit page menu item), available to users who can delete the asset. The UI only offers it when the asset exists in another site as well. If it’s requested for an asset’s only site anyway, it gets soft-deleted like a normal asset deletion (requiring normal delete permissions). The asset’s assets_sites row for the deleted site is removed too.
• When a new site is added, the propagation job no longer queries assets in custom volumes.
• Elements::deleteElementsForSite() now soft-deletes elements that only exist in the site they’re being deleted for, the same as a normal deletion. Drafts (which are always hard-deleted) and nested elements are still hard-deleted. Nested elements were switched to hard deletion in eb17c70 (Feature/cms 1236 propagate element site deletions to nested elements #14154) when site deletions started cascading to them, since they get deleted along with their owner’s site content and couldn’t be restored on their own.
• Fixed Elements::deleteElementsForSite() treating every element as multi-site on single-site installs. Element queries ignore the siteId param when there’s only one site, so the elements’ only site rows were removed without deleting the elements.

🤖 Generated with Claude Code

[linear-code]

CMS-2554