Manual:Amministrazione delle immagini

Questo articolo descrive come MediaWiki gestisce e memorizza i file e fornisce alcune informazioni sulla loro configurazione.

Questo vale sia per le immagini che per qualsiasi altro tipo di file che può essere caricato. Tutti i file sono memorizzati con un articolo corrispondente nel namespace "File:". Prima di MediaWiki 1.14, si usava invece lo spazio dei nomi "Image:". "Image:" viene mantenuto come alias per la compatibilità con il passato.

Caricamenti e utilizzo delle immagini

Vedere Help: Immagini

Abilitare il caricamento delle immagini

Per caricare i file, devono essere soddisfatte le seguenti condizioni:

1. MediaWiki deve avere i caricamenti abilitati. Impostare $wgEnableUploads a true.
2. Il tipo di file deve essere consentito. Ulteriori informazioni: $wgFileExtensions .
3. L'utente deve far parte di un gruppo con il diritto di "upload". Per impostazione predefinita, questa opzione viene assegnata a tutti gli utenti connessi.

I caricamenti vengono fatti utilizzando Special:Upload.

Vedere Manuale: Configurare l'upload dei file , Manual:MIME type detection e Manual:Adding support for new filetypes

Parametri importanti per la gestione dei file

Questi sono i parametri importanti:

• Image configuration
• Path configuration
• Upload configuration

Miniatura immagine

La sintassi delle immagini di MediaWiki consente il ridimensionamento dinamico e il thumbnailing delle immagini (vedere Manuale: Configurare l'upload dei file per un aiuto generale sul caricamento dei file).

La miniaturizzazione delle immagini richiede ImageMagick o GD library - nessuno dei due fa parte dell'installazione predefinita di MediaWiki.

GD

PHP viene fornito con GD abilitato per impostazione predefinita. GD non richiede alcuna configurazione o modifica per essere utilizzato.

Si raccomanda di usare GD sui sistemi Windows.

GD può essere scaricato da https://libgd.github.io/. In versioni recenti di PHP questo non è richiesto.

ImageMagick

In MediaWiki, abilitare ImageMagick in LocalSettings.php impostando $wgUseImageMagick a true.

ImageMagick può essere scaricato da https://imagemagick.org/.

Una volta installato ImageMagick, è necessario abilitarlo e puntare MediaWiki al programma convert o convert.exe sul computer in LocalSettings.php come segue:

$wgUseImageMagick = true;
#$wgImageMagickConvertCommand = 'C:/ImageMagick/convert.exe'; # for Windows
$wgImageMagickConvertCommand = '/usr/bin/convert'; # for Linux

Se si utilizza ImageMagick, impostare $wgUseImageMagick su true in LocalSettings.php. Assicurarsi che il comando sia eseguibile dal processo del server web. Ad esempio, gli utenti di Windows vorranno cambiare l'impostazione predefinita in "C:\ImageMagick\convert.exe" (o simile).

Per ricreare le vecchie miniature prima dell'uso di ImageMagick, si può usare $wgThumbnailEpoch .

Se il rendering fallisce senza avvisi, controllare e aumentare $wgMaxShellMemory .

Per la risoluzione dei problemi, consultare la pagina di aiuto su Image Thumbnails not working.

GraphicsMagick può essere usato anche come alternativa a ImageMagick. È necessario impostare $wgCustomConvertCommand come segue. Esempio:

$wgUseImageMagick = false;
$wgCustomConvertCommand = "gm convert %s -resize %wx%h %d";

Formati immagine

GIF

Per la miniatura di GIF-Animazioni in ambiente Windows, è necessario installare ImageMagick come descritto sopra.

SVG

Presentazione di Wikimania 2016 su Dynamic SVG

MediaWiki supporta il rendering delle immagini SVG: se abilitato, le immagini SVG possono essere usate come gli altri file immagine - saranno automaticamente rese come file PNG e miniaturizzate al volo secondo le necessità. Se si utilizza un host condiviso e non c'è un renderizzatore SVG preinstallato, probabilmente si dovrebbe chiedere al provider di installarlo per voi.

Per abilitare il supporto SVG:

1. Consentire il caricamento di file SVG nel file LocalSettings.php: $wgFileExtensions [] = 'svg'; Si noti che MediaWiki rifiuterà i file SVG contenenti JavaScript, per motivi di sicurezza.

   Se si ottiene un errore che dice che il file è corrotto, verificare che il rilevamento del tipo di file funzioni correttamente.

2. Aggiungere $wgSVGConverter a LocalSettings.php e impostare il renderizzatore che si desidera utilizzare.

   Le opzioni disponibili sono ImageMagick, ImagickExt, sodipodi, inkscape, batik, rsvg, and imgserv.

   Per esempio: $wgSVGConverter = 'ImageMagick';

   • Se il programma di conversione non si trova nel percorso di sistema, è necessario specificare la directory che contiene il programma usando $wgSVGConverterPath ..
   • librsvg è veloce ma non molto preciso. Dipende da un gran numero di librerie. Per installare automaticamente tutte queste librerie, si può usare un gestore di pacchetti. Il progetto Wikimedia utilizza rsvg.
   • Batik è il più accurato renderizzatore SVG disponibile, anche se il suo anti-aliasing è talvolta non ottimale. La sua analisi SVG è più rigorosa e lo porta a rifiutare file SVG "quasi validi" che altri renderizzatori accettano (ad esempio commons:File:UbuntuCoF.svg). Batik si basa su Java ed è molto più lento di rsvg, anche se questo potrebbe non essere un grosso problema a meno che non si aggiungano continuamente file SVG. Vedere SVG benchmarks. Richiede molto lavoro per funzionare, se non è incluso nella distribuzione.
   • Inkscape fa anche un lavoro accurato sugli SVG, a velocità dimezzata rispetto a rsvg, ma è stato progettato per l'uso grafico interattivo; tuttavia, viene fornito con inkview, che è un programma di visualizzazione/conversione - richiede una home directory scrivibile per l'utente con cui viene eseguito. Poiché verrà eseguito come utente www o similare, cercherà di creare le directory .inkscape/ e .gnome2/ nella home directory corrispondente e fallirà senza avvisi, crash o hang indefinitely se non ci riesce. Inkscape è preferibile a rsvg (a) su Windows (viene fornito come pacchetto standalone) o (b) se si hanno SVG importanti disegnati in Inkscape che non vengono resi correttamente in rsvg. Inkscape ha una catena di dipendenze complicata come librsvg: usatela solo se è presente nella vostra distribuzione o se è disponibile come pacchetto standalone completo.
   • Sodipodi è il programma da cui Inkscape è stato derivato. Valgono le stesse considerazioni. Sodipod non è più in fase di sviluppo attivo.
   • Dalla versione 6.x.x ImageMagick rende gli SVG, ma in modo imperfetto. È l'impostazione predefinita, ma è bene evitarla se possibile. Tuttavia, funziona. Su Windows, $wgConvertPath deve essere impostato per evitare un conflitto con convert.exe di Windows. Una semplice alternativa in questo scenario è aggiungere a LocalSettings.php la riga $wgSVGConverters['ImageMagick'] = '"' . $wgImageMagickConvertCommand . '" -background white -thumbnail $widthx$height^! $input PNG:$output';, che consente anche gli spazi nel percorso.
     • Per evitare errori nella creazione di miniature con ImageMagick, se è ≥ 7.0.9-25, allora Inkscape deve essere ≥ 1.x.x. Allo stesso modo, se ImageMagick è < 7.0.9-25, allora Inkscape deve essere < 1.x.x. Vedere ImageMagick issue.
   • L'estensione PHP Imagick supporta il rendering SVG, ma valgono le stesse considerazioni fatte per ImageMagick.
   • La Libreria GD non è in grado di convertire le immagini SVG nel formato PNG, almeno secondo il blog di Joen Asmussen del giugno 2008 NoScope.
   • Over 98% of web browsers have at least basic support for displaying SVG files directly, but MediaWiki does not use that by default. Without the NativeSvgHandler extension, MediaWiki only supports client-side rendering in MediaWiki 1.41 (released December 2023) and newer, by setting $wgSVGNativeRendering = true.

Impostare $wgSVGConverter = false se il rendering SVG non è necessario e si desidera che gli utenti scarichino il file svg per visualizzarlo.

Risoluzione dei problemi

Se si vede un quadrato vuoto al posto dell'SVG (Chrome) o nessuna immagine (Firefox) e tutti i collegamenti PNG portano all'errore 404 e non si vede nessun altro messaggio di errore, controllare la variabile $wgGenerateThumbnailOnParse . L'impostazione di false può rendere la trasformazione SVG sempre differita. Assicurarsi che i metodi PHP proc_open e symlink siano abilitati (potrebbero essere disabilitati in php.ini per motivi di sicurezza o di prestazioni).

JPEG (utilizzando GD)

È sufficiente aggiungere la seguente riga al file LocalSettings.php, per far sì che la libreria GD venga automaticamente ripristinata.

$wgUseImageMagick = false;

Per gli errori con le miniature JPEG, vedere JPEG (usando GD).

TIFF

La generazione di miniature di file TIFF richiede MediaWiki 1.15.0 o più recente.

1. Consentire il caricamento di file TIFF nel file LocalSettings.php: $wgFileExtensions [] = 'tif';
2. Aggiungere $wgTiffThumbnailType a LocalSettings.php e impostare jpg o png per specificare il tipo di miniatura che si desidera generare.
3. La creazione di miniature di file TIFF può richiedere risorse di sistema superiori a quelle necessarie per la creazione di miniature di file JPEG, GIF o PNG. Considerare le impostazioni appropriate per $wgMaxImageArea e $wgMaxShellMemory

DjVu

See also: Manual:How to use DjVu with MediaWiki

Cancellazione di immagini

I file, come le pagine wiki, possono essere cancellati solo da utenti con il permesso "Cancella pagine (delete)" (amministratori per impostazione predefinita). La cancellazione dei file avviene cancellando la pagina di descrizione associata. (oppure cliccando il collegamento "cancella tutto" nella tabella "Cronologia del file").

Cancellazione di singole revisioni

Se un file è stato modificato, esiste una cronologia delle revisioni dei file che viene visualizzata nella pagina dell'articolo del file. Ciascuna revisione ha un link "cancella". Se si fa clic su questa opzione, la revisione e il file vengono eliminati.

Le versioni dei file sono separate dalla cronologia della pagina di descrizione del file.

Le informazioni sulle vecchie revisioni dei file sono memorizzate nella tabella oldimage , mentre le informazioni sulle vecchie revisioni delle pagine sono memorizzate nella tabella revision .

Ripristinare i file

I file possono essere ripristinati esattamente come le normali pagine wiki. La directory in cui vengono memorizzati i file eliminati è definita da Manual:$wgDeletedDirectory . Le informazioni sulle immagini eliminate sono memorizzate nella tabella filearchive .

Cancellazione dei file archiviati

Dalla versione 1.11 di MediaWiki, le immagini cancellate sono ancora memorizzate sul server per impostazione predefinita. Se si desidera eliminare le immagini archiviate selezionate, è possibile farlo utilizzando lo script di manutenzione eraseArchivedFile.php . Se si desidera eliminare completamente tutti i file, è possibile farlo con lo script deleteArchivedFiles.php . Se si eliminano i file archiviati, non è più possibile ripristinarli.

Motivazioni per cancellare un file

Quando si sceglie di cancellare un file, come descritto sopra, agli utenti verrà chiesto di fornire un motivo per la cancellazione. I motivi disponibili possono essere modificati nella MediaWiki:Filedelete-reason-dropdown del wiki.

Archiviazione dei dati

Ogni volta che viene caricata un'immagine, vengono create diverse cose:

1. Una pagina nel namespace dei file con il nome del file, ad esempio File:MyPicture.png. Questa pagina viene memorizzata e può essere modificata come qualsiasi altra pagina.

1. Il file stesso viene memorizzato in una cartella del file system con gli spazi bianchi uniti e sostituiti con _.

1. Se necessario e se la miniatura è disponibile, le versioni miniate del file saranno create quando necessario (ad esempio per l'uso nella pagina di descrizione del file). Questi vengono memorizzati nella directory thumb della directory delle immagini, in una directory separata per ogni file principale.

Se $wgHashedUploadDirectory è abilitato (come impostazione predefinita), MediaWiki crea diverse sottodirectory nella directory delle immagini.

I nomi delle directory provengono dai primi due caratteri dell'hash md5 del nome finale del file.

Cartelle

Tutti i file immagine sono memorizzati in una cartella determinata da $wgUploadPath (images/, per impostazione predefinita).

Descrizione delle sottocartelle di immagini denominate:

archive

È il luogo di archiviazione dei file che sono stati sostituiti da versioni più recenti.

temp

Utilizzato per la memorizzazione temporanea dei file durante il caricamento delle immagini. (A causa di task T11018, questi file potrebbero non essere sempre eliminati automaticamente).

thumb

Miniature (generate automaticamente) per i file. Se questi vengono cancellati, sono rigenerati automaticamente quando sono necessari.

A seconda della configurazione, possono essere presenti ulteriori sottocartelle di immagini:

math

Cartella per memorizzare l'input TeX renderizzato, vedere anche Extension:Math oppure Manual:Math.

x/xy

Se $wgHashedUploadDirectory è impostato su true (che è il valore predefinito), le immagini saranno memorizzate nelle sottocartelle delle immagini, rendendo i percorsi dei file simili a images/a/ab/filename.jpg. Per maggiori dettagli sui motivi per cui questo sistema potrebbe essere utile e sul suo funzionamento, vedere Manual:$wgHashedUploadDirectory .

Tabelle database

• La pagina di descrizione del file viene memorizzata come una qualsiasi pagina nelle tabelle di pagina, testo, revisione, ecc.
• image - Contiene alcuni metadati, come la dimensione del file e la data di caricamento.
• oldimage - Memorizza le informazioni relative ai file che sono stati sostituiti con versioni più recenti.
• filearchive - contiene le informazioni sui file eliminati.
• imagelinks - Registra quali pagine utilizzano un file.

Utilizzo dello spazio

I file richiedono molto più spazio degli articoli. I calcoli seguenti ipotizzano una dimensione del blocco di 4KB con server Linux/Unix.

L'impostazione predefinita è $wgHashedUploadDirectory = true.

Spazio richiesto per tutte le directory:

• directory di immagini: 0-f/x0-f: max. 16*16 = 256 directory = 256*4 KB = 1024 KB
• directory di archivio: 0-f/x0-f: max. 16*16 = 256 directory = 256*4 KB = 1024 KB
• directory di miniature: 0-f/x0-f: max. 16*16 = 256 directory = 256*4 KB = 1024 KB
• directory temporanee: 0-f/x0-f: max. 16*16 = 256 directory = 256*4 KB = 1024 KB

Pertanto, la quantità di spazio di base necessaria senza immagini caricate è teoricamente di 4 MB (anche se le directory vengono create solo quando necessario).

Per ciascun file è necessario:

• dimensione del file immagine originale + 2 KB di overhead medio

Per i file che devono essere miniaturizzati:

• dimensione della/e miniatura/e creata/e + 2 KB di overhead medio (ciascuna)
• directory per le miniature (4KB) (ogni immagine ha una propria directory per le miniature)

Esempi:

• immagine 20778 Byte png (dimensioni ridotte, senza miniatura): 24 KB per l'immagine: Totale 24 KB
• immagine 123.000 Byte jpeg (dimensione grande, miniatura automatico): 124 KB per l'immagine, 4 KB per la directory del pollice, 64KB per il pollice: Totale: 192 KB

Accesso ai file

I file caricati sono generalmente accessibili direttamente dal server web, non attraverso MediaWiki. Sebbene ci possa essere un livello minimo di sicurezza attraverso l'indecifrabilità con la crittografia del percorso (ad esempio, /c/c4/...), se viene impostato $wgHashedUploadDirectory , il percorso può essere calcolato facilmente dal nome del file e non fornisce una vera protezione.

Per limitare l'accesso agli utenti autorizzati, vedere Manual:Image authorization .

Caricamento di form

Vedere la documentation on configuring the upload form.

Licenze

MediaWiki allows licenses to be added to files uploaded from the Special:Upload page. The list of licenses that appear in the license selection dropdown can be edited on the MediaWiki:Licenses page by a sysop.

The page should be a bulleted list of items, and can have sub-items. Each item can have one or more parameters, with the parameter separated by the pipe character (|).

To make headers/categories, use only one parameter in a list item. The text will be what appears in the dropdown list, and will appear greyed-out and unclickable.

To add license options, two or more parameters are required. The first parameter will be the template name to use, without the double square brackets. The last parameter will be what appears in the dropdown list for that license. Any additional parameters between the first and last parameters will be passed as arguments to the template. When a license is selected, a preview of what it would look like on the final page is shown in the upload wizard.

Below is a simple example (not using real templates) of how MediaWiki:Licenses should be formatted:

* no-lic|No license.
* Made by me:
** self-lic|And it can only be used on this wiki.
** self-lic|free=yes|And I allow it to be used anywhere.
* Made by someone else:
** pd-lic|It's in the public domain.
** copyright-lic|It's copyrighted.
** cc-lic|It uses some CreativeCommons license.
** cc-lic|by-sa|It uses the CC-BY-SA license.

The above assumes each template ending in "-lic" exists, where some of those templates take positional arguments such as "by-sa" and others take named arguments such as "free=yes". Selecting the "And I allow it to be used anywhere" option, for example, would add the following text to the page of the new file:

{{self-lic|free=yes}}

Sites like Wikipedia and WikiMedia Commons will also use the subst: tag, such as WikiMedia Common's usage of it below:

** subst:Template 2|flickrreview|subst:uwl|Image from Flickr and I do not know the license

"Template 2" is an actual template that will take two parameters (being template names) and surround them with double curly brackets so they get transcluded on the page of the new image. "uwl" is a template, whose documentation requires using it with the "subst:" tag instead of directly. The above will result in the following being added to the uploaded file's page:

{{flickrreview}}{{subst:uwl}}

On Wikipedia, substitution is used in other ways, such as adding a timestamp with the license at the time of upload.

Per un esempio dettagliato del mondo reale, vedere Wikipedia:MediaWiki:Licenses o Commons:MediaWiki:Licenses.

Repositori esterni

È possibile accedere ai file memorizzati in repository esterni, senza bisogno di caricarli sul wiki, impostando l'array $wgForeignFileRepos . Questa funzionalità offre diverse possibiità:

• ForeignAPIRepo accede ai file di un'installazione MediaWiki remota, come Wikimedia Commons, attraverso le sue API
• ForeignDBRepo accede ai file attraverso un database ed è utile per creare famiglie wiki.
• FSRepo accede ai file da una cartella locale

In tutti i casi, si potrebbe incorporare un file in una pagina usando la normale sintassi image e specificando il nome del file nel repository esterno. Si noti che alcune delle implementazioni di cui sopra sono ancora sperimentali e potrebbero non essere adatte ai siti di produzione.

Notes