Руководство:$wgAllowExternalImages
| Parser: $wgAllowExternalImages | |
|---|---|
| Determines whether or not MediaWiki will allow external images to be rendered inline with text. |
|
| Введено в версии: | Before 1.1.0 |
| Удалено в версии: | всё ещё используется |
| Допустимые значения: | (булевы значения) |
| Значение по умолчанию: | false (1.7+)true (pre-1.1 - 1.6) |
| Другие настройки: По алфавиту | По функциональности | |
Whether to allow inline images hosted on external websites, sometimes called inline linking.
Подробности
When set to true, users can bring in an inline image from an external URL. They do this simply by sticking the full URL into the wiki text (without any other surrounding markup being required) That is the direct URL to an image resource on another website.
When set to false, the full URL appears as a text link to the image.
Note that if you want to allow images from a single trusted source (e.g. from within your own domain) then set this to false, and use $wgAllowExternalImagesFrom.
Thumbnails of external images
Thumbnail images are generated from uploaded images using dimension information in MediaWiki's database. Since external images have no entries in the MediaWiki database, thumbnails cannot be created.
If those images have been uploaded in another MediaWiki or if they are somewhere in your site and you want to let MediaWiki make thumbnails of them you can set $wgUseSharedUploads to true and set $wgSharedUploadPath and $wgSharedUploadDBname instead of enabling external images.
Why allow external images?
Users who know how to get the direct URL of an image, may find this a very useful way of adding illustrations to wiki articles, using image resources available elsewhere on the web.
Without this feature, users are forced to upload any image which they want to embed directly on an article. Upload is (in many ways) more fiddly and time consuming. It also uses disk space and bandwidth on the wiki webserver of course. There are many legitimate uses of inline images.
Additionally, this allows the embedding of external images which change from time to time, or are generated on request, such as graphs from monitoring software such as Cacti--if the images can be identified as image files by their extension. If embedding is enabled, it is also possible to make embedded images links using the syntax [Link_URL Embedded_Image_URL], which will cause clicks on the image to link to the Link_URL.
(MediaWiki will only recognize image URLs with image file extensions; you may need to add a 'fake' parameter to the end of some URLs, like "&junk=junk.png" or "?.png" to force the parser to realize the Image_URL actually points to an image, so that it will embed it.)
Why disallow external images?
Inline external images are disallowed on across many Wikimedia projects, and MediaWiki has AllowExternalImages set to false by default since version 1.6.9. The reasons for this are:
To prevent malicious gathering of browser data. Every time your browser fetches an image (or a web page for that matter) it also submits various bits of data to the webserver in its request. This includes your IP address, the URL of the page you were looking at (the wiki site), and cookies (information about previous requests to that same webserver).
Now with external images enabled, a user can be fetching images from other webservers. A malicious (or devious) person could make wiki edits to set up an external image URL on your wiki, purely for the purpose of gathering this data about your visitors. No need to panic! They wouldn't get credit card numbers or anything, just the kind of data that is sent every time you visit a website. But this might allow them to build up a (rather fuzzy) picture about visitors to your site, which might be correlated with similar data from other sites, and could potentially give rise to privacy concerns. It's the kind of data that has a value to marketing companies, a list saying "The person on this IP address is interested in this kind of website"
An image URL added for this purpose, is an abuse of your wiki, which (unless you disallow it) you will need to look out for along with more conventional spam attacks. Note that the actual image could be a miniscule 1x1 pixel images, and so as with wiki spam, you won't necessarily see it on the page itself, but you will see the edit on your 'recent changes'. Conventional meta:Anti-spam features (such $wgSpamRegex) will counter these kinds of URL along with normal link spam.
To prevent (or reduce the impact of) certain types of vandalism. People can still upload offensive images to your wiki, but this option will prevent people inline linking to offensive images, which might make that kind of vandalism less prevalent. If you do allow external images, then removing abusive image links is always a matter of a simple wiki edit (followed by whatever conflict resolution/banning action you wish to take)
To prevent "bandwidth theft" from other sites. A wiki administrator might wish to avoid being accused of bandwidth theft due to inline linking.
This is only of concern in cases where your wiki is linking to a web server/host belonging to somebody else, and that person was not involved or consulted in setting up the link (a wiki edit) In that situation the person might object to such links. Of course removing the link is as simple as editing the wiki, but it should be noted that inline linking in this kind of situation is widely regarded as bad netiquette (even if you are very happy to remove on demand).
In many other situations, bandwidth theft is not a concern:
- There are some websites which explicitly encourage inline linking to images they host (note that sometimes terms & conditions are attached to inline linking e.g. they require a textual link/acknowledgement)
- A contributor might decide that images they are hosting on their own website could appear on a wiki page, and so they set up the inline link themselves.
- Often it might be useful to allow inline linking to images hosted on the very same webserver as the wiki (which are just not uploaded into the wiki), or images hosted as part of the same overall project/organisation. (You could use $wgAllowExternalImagesFrom to specify this as an exception instead)
To prevent "link rot". An image on another site may have been valid when a wiki article was originally created, but there is no guarantee that an independent external site will remain up, with the same content at the same URL, in the future. Any change in the design of the external site has the potential to break external links to individual files on that site. The same problem exists for textual hyperlinks of course, but for broken image references you will wind up with an ugly error box if the link is broken.
To ensure you are hosting all resources. You might wish to disallow inline linking in order to ensure that all images resources appearing on your wiki, are available from your wiki. If you have good hosting bandwidth, you might want to make full use of this and avoid any slowdown in browsing experience due to images being fetched from elsewhere. You might also want to ensure you are gathering all the image resources locally, in order to offer up all your content as a download.
For consistency in handling images. Uploaded images are added to a wiki page using a different wiki syntax. Having two different syntaxes and two different approaches to adding images, could cause confusion for some novice users. If you disallow external images, users must always follow the same upload procedure, and use the same syntax. Also it means images always have the same click behaviour (taking you to the image page)
Image caption
You cannot easily put an image caption for external images. One solution is by using a table.
{|
| <image url>
|-
| caption
|}
См. также
$wgAllowImageTag- Allow using html-style<img>tags. Useful to resize images, etc. Only available for MW 1.17-1.35.$wgAllowExternalImagesFrom- Only allow external images from a given source or sources.$wgEnableImageWhitelist- Enable an on-wiki page to define what external images are allowed.$wgUseInstantCommons- Enable using images from Wikimedia Commons.