Manual:Image administration/it

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:". "Immage:" viene mantenuto come alias per la compatibilità con il passato.



Caricamenti e utilizzo delle immagini
Vedere



Abilitare il caricamento delle immagini
Per caricare i file, devono essere soddisfatte le seguenti condizioni:


 * 1) MediaWiki deve avere i caricamenti abilitati. Impostare  a.
 * 2) Il tipo di file deve essere consentito. Ulteriori informazioni:.
 * 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, e 



Parametri importanti per la gestione dei file
Questi sono i parametri importanti:





Miniatura immagine
La sintassi delle immagini di MediaWiki consente il ridimensionamento dinamico e il thumbnailing delle immagini (vedere 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 comes with GD enabled by default. GD will not require any configuration or modification to be used.

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  impostando  a.

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

Once ImageMagick is installed, you must enable ImageMagick and point MediaWiki to the  or   program on your computer in  like this:

Se si utilizza ImageMagick, impostare 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.

Se il rendering fallisce senza avvisi, controllare e aumentare.

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



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

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:   Si noti che MediaWiki rifiuterà i file SVG contenenti JavaScript, per motivi di sicurezza.
 * Per evitare un falso positivo, aggiungere  al file.
 * Se si utilizza MediaWiki 1.34 o superiore, non viene mai applicato e ora è sempre . Potete tranquillamente rimuoverlo nel vostro file LocalSettings.php.
 * Se si ottiene un errore che dice che il file è corrotto, verificare che il funzioni correttamente.
 * 1) Aggiungere   a  e impostare il renderizzatore che si desidera utilizzare.
 * Le opzioni disponibili sono ImageMagick, ImagickExt , sodipodi , inkscape , batik , rsvg , and imgserv.
 * Per esempio:
 * 1) * 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.
 * 2) * 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.
 * 3) * 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  o similare, cercherà di creare le directory   e   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.
 * 4) * Sodipodi è il programma da cui Inkscape è stato derivato. Valgono le stesse considerazioni. Sodipod non è più in fase di sviluppo attivo.
 * 5) * 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, che consente anche gli spazi nel percorso.
 * 6) ** 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.
 * 7) * L'estensione PHP Imagick supporta il rendering SVG, ma valgono le stesse considerazioni fatte per ImageMagick.
 * 8) * 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.
 * 9) * La maggior parte dei browser web attuali tranne Internet Explorer (fino alla versione 9) può visualizzare direttamente gli SVG. Using librsvg to render SVGs to a PNG will give much more accurate results, as well as less bandwidth consumption. La visualizzazione diretta di SVG non è supportata di default in MediaWiki, a meno che non si installi l'estensione.
 * 1) * La maggior parte dei browser web attuali tranne Internet Explorer (fino alla versione 9) può visualizzare direttamente gli SVG. Using librsvg to render SVGs to a PNG will give much more accurate results, as well as less bandwidth consumption. La visualizzazione diretta di SVG non è supportata di default in MediaWiki, a meno che non si installi l'estensione.

Set  if SVG rendering is not needed and you wish to make your users download the svg file in order to view it.

Troubleshooting
If you see a blank square instead of SVG (Chrome) or no image at all (Firefox) and all PNG links lead to 404 error and you don't see any other error message anywhere please check variable. Setting it to false may make SVG transformation deferred always. Make sure that proc_open and symlink PHP methods are enabled (they may be disabled in php.ini for security or performance reasons).

JPEG (using GD)
Simply add the following line to LocalSettings.php, this will cause auto fall back to GD library.

For errors with JPEG thumbnails, see JPEG (using GD).

TIFF
Generating thumbnails of TIFF files requires MediaWiki 1.15.0 or newer.

Consider appropriate settings for  and
 * 1) Allow upload of TIFF files in the LocalSettings.php file:
 * 1) Add   to  and set to either jpg or png to specify which type of thumbnail you wish to have generated.
 * 1) Making thumbnails of TIFF files may require system resources beyond those needed for thumbnailing JPEG, GIF, or PNG files.

Deletion of images
Files, like wiki pages, can only be deleted by users with the " (delete)" permission ( by default). Deletion of files is done by deleting the associated description page (or by clicking the "" link in the "" table).

Deletion of individual revisions
If a file has been altered, there is a revision history of the files which is displayed on the file article page. Each revision has a "" link. If this is clicked, the revision and the file are deleted.

Information about old revisions of files are stored in the table while information on old revisions of the pages are stored in the  table.

Undeleting files
Files can be undeleted in exactly the same way as normal wiki pages. The directory in which deleted files are stored is defined by. Information about deleted images are stored in the table.

Deletion of Archived Files
Since MediaWiki version 1.11, deleted images are still stored on the server by default. If you want to delete selected archived images, you can do so using the maintenance script. If you want to delete all of them completely, you can do that with the script. If you delete archived files, you can not undelete those files anymore.

Reasons for Deleting a File
When choosing to delete a file, as described above, users will be asked to provide a reason for deletion. The available reasons can be edited on the MediaWiki:Filedelete-reason-dropdown of your wiki.

Data storage
Whenever an image is uploaded, several things are created:

This page is stored and can be edited like any other page. These are stored in the thumb directory of the image directory, in a separate directory for each main file.
 * 1) An article in the file namespace with the name of the file, e.g. File:MyPicture.png.
 * 1) The file itself is stored in a folder on the file system with whitespaces merged and replaced with.
 * 1) If necessary and thumbnailing is available, thumbnailed versions of the file will be created when necessary (such as for the usage on the file description page).

If is enabled (by default), MediaWiki creates several subdirectories in the images directory.

The directory names are from the first two characters of the md5 hash of the final filename.

Folders
All image files are stored in a folder determined by (, by default).

Description of named image subfolders:

(Due to, these files may not always be automatically deleted) If these are deleted, they are automatically regenerated when needed.
 * archive: This is the storage place for files that have been replaced by newer versions.
 * temp: used for temporary storage of files during image uploading.
 * thumb: Thumbnails (automatically generated) for the files.

Depending on the configuration, there may be additional image subfolders:

See for more details on why this might be desired and how this system works.
 * math: Folder to store your rendered TeX input, see also Extension:Math or Manual:Math.
 * x/xy: If is set to true (which is the default), images will be stored in subfolders of the images, thus making file paths look like.

Database tables

 * The file description page is stored as any page in the page, text, revision etc. tables
 * - Holds some metadata such as the size of the file and the upload date.
 * - This stores information for files that have been replaced with newer versions.
 * - holds the information on the deleted files.
 * - Records what pages use a file.

Space usage
Files need considerably more space than articles. The following calculations assume a block size of 4KB with Linux/Unix servers.

The default setting is.

Space requirements for all directories:


 * image directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB
 * archive directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB
 * thumb directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB
 * temp directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB

Therefore, the basic amount of space needed without any images uploaded is 4 MB in theory (although the directories are created only when needed).

For each file we need:


 * size of the original image file + 2 KB average overhead

For files that need to be thumbnailed:


 * size of the created thumbnail(s) + 2 KB average overhead (each)
 * directory for thumbnail (4KB) (each image has its own thumbnail directory)

Examples:


 * image 20778 Byte png (small size, no thumb): 24 KB for the image: Total 24 KB
 * image 123.000 Byte jpeg (big size, auto thumb): 124 KB for the image, 4 KB for the thumb directory, 64KB for the thumb: Total: 192 KB

File Access
Uploaded files are generally served directly by the web server, not through MediaWiki. While there may be a minimal level of security through obscurity with path encryption (e.g. /c/c4/...) if is set, the path can be calculated easily from the file name and does not provide true protection.

For limiting access to authorized users, see.

Upload form
See the documentation on configuring the upload form.

Licensing
A feature of MediaWiki allows the Special:Upload Page to streamline licensing of images. Wikipedia's Upload Page has a Licensing drop down box below image summary. To make use of this feature a sysop needs to edit Licenses in the MediaWiki namespace (example: MediaWiki:Licenses). They can do this by going to the MediaWiki:Licenses page of their wiki and clicking 'create' or 'edit'.

The page MediaWiki:Licenses expects a certain format in a wiki list.

Line 1 will produce "License text" and substitute the license 1 template in the image page and transclude license 2.

Line 2 will show a greyed out header with text "Header 1:"

Line 3 will produce "Attribution ShareAlike 2.5" and transclude template cc-by-sa-2.5 on the image page.

For detailed real world example, see Wikipedia:MediaWiki:Licenses or Commons:MediaWiki:Licenses.

Foreign Repositories
It is possible to access files stored in foreign repositories, without needing to upload them to the wiki, by setting the array. This feature offers several possibilities:


 * ForeignAPIRepo accesses files from a remote MediaWiki installation, such as Wikimedia Commons, through its API
 * ForeignDBRepo accesses files through a database, and is useful for creating wiki families
 * FSRepo accesses files from a local folder

In all cases, one would be able to embed files into a page using ordinary image syntax and specifying the name of the file in the foreign repository. Note that some of the above implementations are still experimental, and might not be suitable for production sites.