Una foto scattata con un telefono di fascia alta esce a più di 6000 pixel di lato lungo. WordPress, appena la carichi, ne fabbrica una copia ridotta a 2560 pixel e promuove quella a immagine “piena” dell’articolo: il file originale resta su disco e non lo apre più nessuno. Se quella foto portava una firma di provenienza — le Content Credentials di un Pixel, di una Leica o di un generatore AI — la prova è rimasta nel file che non pubblichi.
La soglia dei 2560 pixel e cosa succede dopo
Il numero non è arbitrario: dalla 5.3 WordPress applica il filtro big_image_size_threshold, che ha valore predefinito 2560 e vale come larghezza e altezza massime. Sopra quella soglia l’immagine viene scalata, e lo scalato diventa la versione più grande disponibile, compreso il valore di _wp_attached_file. L’originale non sparisce, ma esce dal circuito: lo raggiungi solo con wp_get_original_image_path(), e nessun tema lo serve da solo.
Il problema non è solo di percorso. L’issue #421 del repository WordPress/ai, aperta il 12 aprile 2026, lo dice senza giri di parole: la pipeline immagini di WordPress, sia con GD sia con Imagick, distrugge i manifest C2PA durante la generazione delle dimensioni derivate, e nessun plugin o funzione del core rileva oggi quei manifest. Ridimensionare cambia i pixel firmati: la firma originale non riverifica dopo il resize, e WordPress non ne genera una nuova sulla copia. L’unica finestra utile per leggere la provenienza è il momento dell’upload, prima che la lavorazione cominci.
Registra la provenienza prima che il file venga lavorato
L’ordine delle operazioni in WordPress ti lascia un punto di innesto pulito: add_attachment scatta dopo l’inserimento del media ma prima di wp_generate_attachment_metadata(), che è la funzione che scala e genera le copie. A quel punto get_attached_file() punta ancora al file caricato intatto. Leggilo lì e scrivi il risultato in postmeta: costa una lettura sola e ti lascia un dato interrogabile per sempre, anche quando il file servito non dirà più niente.
// Marca gli allegati che arrivano con un manifest di provenienza.
add_action( 'add_attachment', 'lr_rileva_provenienza' );
function lr_rileva_provenienza( $attachment_id ) {
if ( ! wp_attachment_is_image( $attachment_id ) ) {
return;
}
$file = get_attached_file( $attachment_id );
if ( ! $file || ! file_exists( $file ) ) {
return;
}
// Il manifest sta in testa al file: JPEG lo mette in un marker APP11,
// PNG in un chunk caBX, WebP in un chunk RIFF chiamato C2PA. Nei WebP
// molto grandi il chunk può finire oltre questa finestra: in quel caso
// il rilevatore tace, e va allargata la lettura.
$testa = file_get_contents( $file, false, null, 0, 512 * 1024 );
if ( false === $testa ) {
return;
}
$trovato = ( false !== strpos( $testa, 'jumb' ) && false !== strpos( $testa, 'c2pa' ) )
|| false !== strpos( $testa, 'caBX' );
update_post_meta( $attachment_id, '_lr_provenienza', $trovato ? 'c2pa' : 'nessuna' );
}È un rilevatore, non un validatore: cerca i marcatori dei contenitori, non decodifica il manifest e non verifica nessuna firma. Per PMI e studi professionali basta e avanza, perché la domanda operativa non è “questa firma è valida” ma “questo file ne aveva una, e dove sta adesso l’originale”. Il guard sul tipo evita letture inutili sui PDF.
Il secondo punto di perdita sono i plugin di ottimizzazione
Anche se tieni l’originale, resta un modo per buttarlo via senza accorgersene. I plugin di ottimizzazione non lavorano solo sulle copie: in ShortPixel l’impostazione Resize large images, sotto Impostazioni, agisce proprio sui file full original, non sulle miniature, e riscrive il file in posizione. Imagify, EWWW e il modulo immagini di LiteSpeed Cache hanno controlli equivalenti. Ogni ricompressione ripulisce i metadati che non servono alla resa, e un manifest rientra in quella categoria. Lo stesso vale per la conversione automatica in WebP o AVIF, e per qualsiasi passaggio in un generatore di immagini: è un nuovo file, con nuovi pixel, e nessuno ci ricopia dentro niente.
La regola pratica è una sola: se il sito pubblica foto che devono restare dimostrabili — perizie, cantieri, stato di un prodotto prima della spedizione, documentazione di un intervento — l’ottimizzazione dell’originale va disattivata, oppure il backup dell’originale va tenuto attivo e fuori dalla cartella uploads che il plugin tocca. Verificalo su un file di prova: carica, ottimizza, riscarica l’originale e ricontrolla i marcatori.
L’errore da evitare: confondere il badge con la prova
La tentazione, appena hai il dato in postmeta, è stampare un bollino “foto verificata” sotto l’immagine. Non farlo, e non venderlo a un cliente: quel bollino direbbe che un marcatore esiste nel file caricato, non che la foto è autentica. Sono due affermazioni diverse, e nessun plugin WordPress oggi sostiene la seconda. Quel dato sta nel registro interno degli asset, come per i materiali generati con l’AI: serve a chi risponde, non al visitatore.
Il confine lo ha reso evidente Apple. Il 15 settembre 2026 ha pubblicato sul blog Security Research il funzionamento di Apple Reference Image, la funzione degli iPhone 18 Pro che firma i dati del sensore subito dopo la cattura e conserva un “negativo digitale” in formato DNG sul dispositivo. Nel testo Apple critica esplicitamente l’approccio C2PA, che attacca i metadati dopo la cattura e resta vulnerabile in ogni anello della catena di editing. Qualunque sia il sistema che vince, la verifica avviene fuori dal tuo sito: al CMS resta il compito più noioso, cioè non distruggere l’unica copia che porta la prova.
Cosa fare oggi, in ordine
Tre passaggi, nell’ordine in cui conviene farli. Primo: metti lo snippet e carica una foto di prova da un telefono recente o da un generatore, per vedere se il tuo flusso produce davvero file con manifest — se non ne produce, il resto può aspettare. Secondo: apri le impostazioni del plugin di ottimizzazione e decidi consapevolmente se l’originale va toccato, invece di scoprirlo fra sei mesi. Terzo: se pubblichi foto che documentano fatti, definisci dove vive l’originale intatto, perché è l’unico artefatto che qualcun altro potrà verificare.
La take: la provenienza delle immagini, per chi gestisce siti, non è un tema di visualizzazione ma di conservazione. Il lavoro non consiste nel mostrare che una foto è vera, consiste nel non rendere impossibile dimostrarlo. Su WordPress si traduce in due decisioni prese una volta sola: dove finisce l’originale, e chi ha il permesso di riscriverlo.