InstantCommons/zh



即时共享资源是MediaWiki的一个特性，允许在全世界任何一个MediaWiki实体能够使用维基共享资源的任何已上传的媒体文件. 启用即时共享资源特性的wiki站点，可以在第一次请求该文件后自动缓存在本地，并且之后会使用该本地复本来显示.

原理
截至2017年7月，由维基媒体基金会主持的中央媒体资料库维基共享资源包含超过4千万个文件. 这些文件中的每一个都可以在自由内容许可下或公共域中获得，除使用官方徽章或商标之外，没有其他限制使用. 限制商业用途的许可证被视为非自由.

随着对维基共享资源的认识不断提高，外部各方也希望使用其中包含的内容，并提供新材料. 目前技术上可以在任何网页的上下文中直接从维基媒体的服务器加载图像. 允许这样的热链接，但由于多种原因它存在问题： 即时共享资源旨在通过提供一种从维基媒体服务器缓存加载图像和元数据的简单方法来解决所有这些问题. 即时共享资源的第一个实现将在MediaWiki中，允许所有MediaWiki图像操作（缩略图、字幕、图库等）透明地执行. 但是，其他wiki引擎可以使用下面描述的API操作实现类似即时共享资源的功能.
 * 它不尊重图像的许可条款，也不允许可靠地传输其他元数据
 * 除了没有恰当地归功于媒体文件的作者，它也没有给予维基媒体信任
 * 它会在每个网页浏览中消耗维基媒体带宽（除非图像已在客户端或通过代理缓存）
 * 它不利于缩略图生成和字幕等有用的图像操作，并且难以在Wiki的上下文中使用，特别是对于标准布局操作
 * 它与URL绑定为资源标识符，这使镜像变得复杂
 * 它创建了一个无法跟踪的外部使用网站，维基媒体方面的任何变化都必然会影响这些外部用户
 * 它不允许离线查看，这在仅具有间歇性网络访问的国家中是至关重要的.

基本功能设置
在安装过程中，站点管理员可以选择是否启用即时共享资源. 但是，理想情况下，默认情况下应启用该功能（如果指定了可写上载目录），以允许尽可能多的用户使用维基共享资源内容.

如果启用该功能，则wiki的行为类似于维基媒体项目，即，如果引用存在于维基共享资源上的图像或其他媒体文件，则可以通过指定其名称将其包含在类似本地上载文件的Wiki页面中. 本地文件名优先于维基共享资源文件名.

此功能依赖于php curl扩展. 如果您没有安装此扩展程序，则可能无法使用即时共享资源.

配置
要在MediaWiki 1.16或更高版本中启用即时共享资源，只需将此行添加到LocalSettings.php即可（有关详细信息，请参阅）：

要在MediaWiki版本1.13-1.15中启用，请参阅这里.

此功能应立即生效. 如果不是，请检查Web服务器中是否禁用了PHP函数.

HTTPS
从2015年6月开始，只能使用HTTPS访问维基共享资源. 某些安装可能缺少其根证书存储，这会阻止MediaWiki通过HTTPS与维基共享资源联系. 如果即时共享资源停止工作，请尝试：


 * 安装php curl扩展（它通常更可靠，并且更有可能已安装适当的证书）在debian/ubuntu上：
 * 确认您拥有最新的证书存储区. 如果您安装了php curl扩展，请按照说明here.

SElinux
如果您的服务器操作系统实现了SElinux，请查看SElinux设置页面上的专用部分，并确保HTTPD脚本和模块可以成功访问网络. 如果SElinux阻止HTTPD脚本和模块连接到维基共享资源存储库，则即时共享资源功能将无法正常工作.

防火墙后面
如果运行wiki的服务器位于防火墙后面，则必须向wons服务器授予对commons.wikimedia.org和upload.wikimedia.org的传出http/https请求，以便即时共享资源工作. IP地址范围可在IP addresses中找到.

通过即时共享资源使用文件
启用即时共享资源后，您可以从维基共享中选择任何图像（例如），单击“使用此文件”按钮（旁边带有wiki图标的按钮）并将标记粘贴到您的wiki中. In our example, pasting

will render the thumbnail (as can be seen on the right side of this page).

Note that when using files in this way you will still need to respect any licensing and other file use legal requirements - see Commons:Reusing content outside Wikimedia.

Scalability considerations
Because the InstantCommons feature allows a wiki user to download resources from the Wikimedia servers, it is crucial that there is no possibility of a Denial of Service attack against either the using wiki, or the Wikimedia Commons, for example, by pasting 30K of links to the largest files on Wikimedia Commons into a wiki page and pressing "preview". Therefore, every successful InstantCommons request will have to be logged by the InstantCommons-enabled wiki together with the originating user or IP address and the time of the request. If an individual user overrides a generous internal bandwidth limitation (could be as high as 1 GB by default, but should be user-configurable), future images will not be downloaded within a 24 hour period. This limitation should not exist for wiki administrators (if a wiki admin wants to conduct a denial of service attack against his own wiki, they do not need to be stopped from doing so; if they want to conduct an attack against Wikimedia, they cannot be stopped from doing so except on Wikimedia's end). In addition to the per-user bandwidth limit, there could be a limit on the size of files which should be downloaded transparently. This would primarily be because files above a certain size would delay pageviews significantly and might even cause the page request to time out. It might be desirable to use an external application for the purpose of downloading these files, so that it can be done in the background without causing the page request to continue. Finally, there could be a total maximum size for the InstantCommons cache; if this size is exceeded, no further files would be downloaded.

While it is unlikely that individual wikis using the InstantCommons feature would cause a significant increase in cost for the Wikimedia Foundation (since every file only has to be downloaded once, and there are per-user bandwidth limitations), it would nevertheless be fair and reasonable for projects using the feature to include a notice on InstantCommons description pages such as: "This file comes from Wikimedia Commons, a media archive hosted by the Wikimedia Foundation. If you would like to support the Wikimedia Foundation, you can donate here ..."

Future potential
In the future, it may be desirable to offer a publisher/subscribe model of changes, which will require wiki-to-wiki authentication and a database of images which are used in subscribing wikis. This would also open up the threat of cross-wiki vandalism, which could be addressed using a delay phase of 24 hours or more for changes to take effect. Two-way functionality is another possibility, that is, to allow uploading free media directly to Commons from any wiki installation. However, this will require federated authentication as a minimum. It may also necessitate cross-wiki communication facilities to notify users from other wikis about Commons policies, which could be part of a larger project like LiquidThreads.

参见

 * - for the same functionality as InstantCommons but with other wikis
 * PhotoCommons: Wordpress plug-in to provide the same functionality
 * Examples of sites which are using InstantCommons