Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[5.x]: Assets don't scale with 100+ sites

Aperta
  • Qualcosa non va?
#19,761 1 commento 4 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
php
Ambito
backend, databases

Direzione di ricerca

Start by reviewing how asset rows are stored in elements_sites, assets_sites, and searchindex, then compare that with the per-site settings approach used for sections. Trace the element-query joins that currently require an elements_sites row for the requested site. Done should include reduced duplication for multi-site assets without breaking site availability or queries.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
Description

An asset is a single file, but Craft stores it once per site. For every asset and every site, Craft creates:

  • 1 row in elements_sites
  • 1 row in assets_sites
  • 1 row in searchindex per searchable attribute/field

This happens regardless of whether anything on the asset is translatable. Even if every translation method is set to none, and every per-site row therefore holds identical values, the rows are still created for every site.

On installs with many sites, this multiplies the asset data by the number of sites.

Numbers from our install

I know this is crazy, but the site that I'm currently profiling has 127 sites with ~138k assets.

Table Rows
assets_sites ~16.9M (≈ 138k assets × 127 sites)
elements_sites ~16.7M, almost entirely assets
searchindex rows belonging to assets ~96.1M of ~100.6M total

In practice, nearly all of these rows are identical copies across sites.

Rough estimate of the potential savings, if assets were stored once per language (2 instead of 127 rows per asset):

Table Current size (data + index) Estimated savings
searchindex ~8.8 GB ~8 GB
elements_sites ~6.6 GB ~4–6 GB
assets_sites ~0.75 GB ~0.7 GB
Total ~12–15 GB

(This estimate is based on each table's share of asset rows. Actual savings depend on row size)

Idea

I'm aware that element queries rely on an elements_sites row existing for the queried site, so the fallback options would need changes to how element queries join site data?

Maybe a "simple" solution would be to save assets only for the primary site and other languages that are defined by the translation settings of the fields, and fallback to it in case an asset isn't in the requested site.

Per-volume site settings would probably be the least invasive option, since it follows the pattern sections already use. However, it doesn't help when the same assets need to be available in every site, which is our case. Only the fallback approaches would reduce the data there.

Craft CMS version

5.10.14

PHP version

8.3

Operating system and version

No response

Database type and version

No response

Image driver and version

No response

Installed plugins and versions
Lingua principale
PHP
Stelle
3.6k
Fork
706
Merge medio
12h 30m
PR unite (30g)
274

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di craftcms/cms

Tutte le issue di craftcms/cms

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.