Help:Image Administration

From FORwiki

(Difference between revisions)
Jump to: navigation, search
(Database tables)
 
(13 intermediate revisions not shown)
Line 18: Line 18:
== Image thumbnailing ==
== Image thumbnailing ==
-
MediaWiki's [[w:Wikipedia:Extended image syntax|extended image syntax]] allows images to be automatically '''thumbnailed''' (see ''[[Manual:Configuring file uploads]]'' for general help on file uploads).
+
FORwiki's extended image syntax allows images to be automatically '''thumbnailed'''.
-
 
+
-
Image thumbnailing requires either [[w:ImageMagick|ImageMagick]] or [[w:GD Graphics Library|GD library]]. ImageMagick is recommended since it produces better quality thumbnails; it can be downloaded from [http://www.imagemagick.org/ imagemagick.org]. GD can be downloaded from [http://www.libgd.org/Main_Page libgd.org]. Neither of these are part of the default MediaWiki installation, although PHP can come with GD.
+
-
 
+
-
For older versions of MediaWiki (prior to 1.10.0) set '''[[Manual:$wgUseImageResize|$wgUseImageResize]]''' to true to enable thumbnailing. In newer versions this is not needed anymore.
+
-
 
+
-
If you use ImageMagick, set '''[[Manual:$wgUseImageMagick|$wgUseImageMagick]]''' to true in LocalSettings.php. Make sure the [[Manual:$wgImageMagickConvertCommand|$wgImageMagickConvertCommand]] variable points to the (absolute) location of the convert command of your installation and that the command is executable by the web server process.
+
-
 
+
-
To re-create old thumbnail files before you used ImageMagick you can use [[Manual:$wgThumbnailEpoch|$wgThumbnailEpoch]].
+
=== GIF ===
=== GIF ===
Line 33: Line 25:
=== SVG ===
=== SVG ===
FORwiki supports SVG image rendering: if enabled, SVG images can be used like other image files: they will automatically be rendered as a PNG file and thumbnailed as needed on the fly.
FORwiki supports SVG image rendering: if enabled, SVG images can be used like other image files: they will automatically be rendered as a PNG file and thumbnailed as needed on the fly.
-
 
-
To enable SVG support:
 
-
 
-
# Allow upload of SVG files in the LocalSettings.php file: <tt>[[Manual:$wgFileExtensions|$wgFileExtensions]][] = 'svg';</tt> Note that MediaWiki will refuse SVG files containing JavaScript, for security reasons.
 
-
#:To avoid a false positive, add <tt>[[Manual:$wgAllowTitlesInSVG|$wgAllowTitlesInSVG]] = true;</tt> to the [[Manual:LocalSettings.php|LocalSettings.php]] file.
 
-
#:If you get an error saying the file is corrupt, make sure [[Manual:mime type detection|mime type detection]] is  working properly.
 
-
# Add <tt>[[Manual:$wgSVGConverter|$wgSVGConverter]]</tt> to [[Manual:LocalSettings.php|LocalSettings.php]] and set the renderer you want to use.
 
-
#:Available options are ''[[w:ImageMagick|ImageMagick]]'', ''[[w:sodipodi|sodipodi]]'', ''[[w:inkscape|inkscape]]'', ''[[w:batik (software)|batik]]'', ''[[w:rsvg|rsvg]]'', and ''[[imgserv]]''.
 
-
#*{{note}} '''If the converter program is not in the system path, you have to specify the ''directory'' that contains the program using <tt>[[Manual:$wgSVGConverterPath|$wgSVGConverterPath]]</tt>'''.
 
-
#* [[w:librsvg|librsvg]] is fast but not very accurate. It has a ridiculously large chain of dependencies, so you may not want to bother unless you have a repository that includes it and resolves the dependencies for you. The Wikimedia projects use rsvg 2.14. '''Note:''' As of version 2.22.3, there is a bug in locale handling (see [https://bugzilla.wikimedia.org/show_bug.cgi?id=16014 Wikimedia bug report] and [http://bugzilla.gnome.org/show_bug.cgi?id=557036 GNOME bug report]).  A [http://svn.wikimedia.org/viewvc/mediawiki/trunk/debs/librsvg2/debian/patches/cmdline-bugfixes.patch?revision=42255&view=markup patch is available] for the <code>rsvg-convert</code> tool.
 
-
#* [[w:Batik (software)|Batik]] is the most accurate SVG renderer available. It relies on Java. It is also much slower than rsvg, though this may not be a huge issue unless you're constantly adding SVG files. See [[SVG benchmarks]]. Requires a lot of work to get running.
 
-
#* [[w:Inkscape|Inkscape]] also does an accurate job of SVGs, half the speed of rsvg, but was designed for interactive graphical use - it requires a writable home directory for the user it's run as. Since it will be running as user <tt>www</tt> or something similar, it will try to create <tt>.inkscape/</tt> and <tt>.gnome2/</tt> directories in the corresponding home directory, and will fail silently if it is not able to. Inkscape is preferable to rsvg (a) on Windows (it comes as a standalone package) or (b) if you have important SVGs drawn in Inkscape that do not render correctly in rsvg. Inkscape has as complicated a dependency chain as librsvg &mdash; use only if it's in your distribution or available as a complete standalone package.
 
-
#* [[w:Sodipodi|Sodipodi]] is the program Inkscape was forked from. The same considerations apply. Sodipod is no longer under active development.
 
-
#* [[w:ImageMagick|ImageMagick]] renders SVGs, but very buggily, also slow. This is the default, but avoid it if possible. However, it does work.
 
-
#* The [[w:GD Graphics Library|GD library]] is not capable of converting SVG images to the PNG format, at least according to Joen Asmussen's June 2008 [http://noscope.com/journal/2008/06/converting-svg-to-png-on-the-fly-how NoScope] blog.
 
-
#* Most current web browsers ''except'' [[w:Internet Explorer|Internet Explorer]] can display SVGs directly. Using librsvg to render SVGs to a PNG will give much more accurate results. Direct SVG display is not supported in MediaWiki by default.
 
-
 
-
 
== Deletion of images ==
== Deletion of images ==
Line 61: Line 35:
{{Note}} The versions of files are separate from the page history of the file description page.   
{{Note}} The versions of files are separate from the page history of the file description page.   
-
Information about old revisions of files are stored in the [[oldimage table]].
+
Information about old revisions of files are stored in the oldimage table.
-
 
+
-
=== Undeleting files ===
+
-
{{warning}} Before MediaWiki version 1.8, deleted images/files ''can not be undeleted'' (only the associated description page can be restored).
+
-
 
+
-
From MediaWiki version 1.8 up to 1.10, archiving deleted images/files (and thus undeleting them) is disabled per default, but can be enabled by setting [[Manual:$wgSaveDeletedFiles|$wgSaveDeletedFiles]] = true.
+
-
 
+
-
Since MediaWiki version 1.11, this is enabled per default, and $wgSaveDeletedFiles is deprecated. Instead, the behavior is controlled  by [[Manual:$wgFileStore|$wgFileStore]].
+
-
 
+
-
Information about deleted images are stored in the [[filearchive table]].
+
== Data storage ==
== Data storage ==
Line 80: Line 45:
# 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. These are stored in the thumb directory of the image directory, in a separate directory for each main file.
# 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. These are stored in the thumb directory of the image directory, in a separate directory for each main file.
-
If [[Manual:$wgHashedUploadDirectory|$wgHashedUploadDirectory]] is enabled (by default), MediaWiki creates several subdirectories in the images directory.
+
If $wgHashedUploadDirectory is enabled (by default), FORwiki creates several subdirectories in the images directory.
The directory names are from the first two characters of the md5 hash of the final filename.
The directory names are from the first two characters of the md5 hash of the final filename.
Line 103: Line 68:
Files need considerably more space than articles. The following calculations assume a block size of 4KB with Linux/Unix servers.
Files need considerably more space than articles. The following calculations assume a block size of 4KB with Linux/Unix servers.
-
The default setting is [[Manual:$wgHashedUploadDirectory|$wgHashedUploadDirectory]] = true.
+
The default setting is $wgHashedUploadDirectory = true.
Space requirements for all directories:
Space requirements for all directories:
Line 127: Line 92:
=== File Access ===
=== 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 (eg. /c/c4/...) if [[Manual:$wgHashedUploadDirectory|$wgHashedUploadDirectory]] is set, the path can be calculated easily from the file name and does not provide true protection.
+
Uploaded files are generally served directly by the web server, not through FORwiki. While there may be a minimal level of security through obscurity with path encryption (eg. /c/c4/...) if $wgHashedUploadDirectory 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 [[Manual:Image Authorization|Image Authorization]]
+
== Licensing ==
== 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. This feature is turned off in default MediaWiki. To turn this feature on a sysop needs to edit Licenses in the MediaWiki namespace. Example:
+
A feature of Foresight Wiki allows the Special:Upload Page to streamline licensing of images. Foresight Wiki's Upload Page has a Licensing drop down box below image summary.
-
[[MediaWiki:Licenses]]
+
Licenses expects a certain format in a wiki list.
Licenses expects a certain format in a wiki list.
Line 147: Line 109:
Line 2 will show a greyed out header with text "Header 1:"<br />
Line 2 will show a greyed out header with text "Header 1:"<br />
Line 3 will produce "Attribution ShareAlike 2.5" and transclude template cc-by-sa-2.5 on the image page.
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 http://en.wikipedia.org/wiki/MediaWiki:Licenses
 
== Foreign Repositories ==
== Foreign Repositories ==
-
It is possible to access files stored in foreign repositories, without needing to upload them to the wiki, by setting the [[Manual:$wgForeignFileRepos|$wgForeignFileRepos]] array. This feature offers several possibilities:
+
It is possible to access files stored in foreign repositories, without needing to upload them to the wiki, by setting the $wgForeignFileRepos array. This feature offers several possibilities:
-
* '''ForeignAPIRepo''' accesses files from a remote MediaWiki installation, such as [[commons:|Wikimedia Commons]], through its API
+
* '''ForeignAPIRepo''' accesses files from a remote MediaWiki installation
-
* '''ForeignDBRepo''' accesses files through a database, and is useful for creating [[Manual:Wiki family|wiki families]]
+
* '''ForeignDBRepo''' accesses files through a database, and is useful for creating wiki families
* '''FSRepo''' accesses files from a local folder
* '''FSRepo''' accesses files from a local folder
In all cases, one would be able to embed files into a page using ordinary [[Help:Images|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.
In all cases, one would be able to embed files into a page using ordinary [[Help:Images|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.
-
 
-
{{Languages}}
 

Current revision as of 12:56, 8 February 2010

This article describes how FORwiki handles and stores files, and gives some information on configuring.

This applies to images as well as to any other type of file that can be uploaded. All files are stored with a corresponding article in the namespace "File:".

Contents

Upload and usage of images

See: Help:Images

Enable upload of images

To upload files, three conditions have to be met:

  1. FORwiki must have uploads enabled. Set $wgEnableUploads to true.
  2. The file type must be allowed. More information: $wgFileExtensions.
  3. The user has must be in a group with the "upload" right. By default this is given to all logged-in users.

Uploads are done using Special:Upload.

Image thumbnailing

FORwiki's extended image syntax allows images to be automatically thumbnailed.

GIF

For thumbnailing GIF-Animations under windows, you need to install ImageMagick as described above.

SVG

FORwiki supports SVG image rendering: if enabled, SVG images can be used like other image files: they will automatically be rendered as a PNG file and thumbnailed as needed on the fly.

Deletion of images

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

Deletion of individual revision

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 "delete" link. If this is clicked, the revision and the file are deleted.

Note Note: The versions of files are separate from the page history of the file description page.

Information about old revisions of files are stored in the oldimage table.

Data storage

Whenever an image is uploaded, several things are created:

  1. An article in the file namespace with the name of the file, e.g. File:MyPicture.png. This page is stored and can be edited like any other page.
  2. The file itself is stored in a folder on the file system.
  3. 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. These are stored in the thumb directory of the image directory, in a separate directory for each main file.

If $wgHashedUploadDirectory is enabled (by default), FORwiki 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 separate folder, set by $wgUploadPath.

Description of named image subfolders:

archive
This is the storage place for files that have been replaced by newer versions.
temp
used for image uploading.
thumb
Thumbnails (automatically generated) for the files. If these are deleted, they are automatically regenerated when needed.

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

math
Folder to store your rendered TeX input.


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 $wgHashedUploadDirectory = true.

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, 4KB for the thumb directory, 64 KB for the thumb: Total: 192 KB

File Access

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

Licensing

A feature of Foresight Wiki allows the Special:Upload Page to streamline licensing of images. Foresight Wiki's Upload Page has a Licensing drop down box below image summary.

Licenses expects a certain format in a wiki list.

*subst:license 1|license 2|License text
* Header 1:
** cc-by-sa-2.5|Attribution ShareAlike 2.5

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.

Foreign Repositories

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

  • ForeignAPIRepo accesses files from a remote MediaWiki installation
  • 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.

Personal tools