Talk:InstantCommons/Archive 2
This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current talk page. |
- Background: see also m:Meta:Babel/Archives/2008-12#Proposal to disable hotlinking.
- /Archive 1 (2006-2008)
Caching
How long is a failure cached?
I tried using a file on RationalWiki, which uses InstantCommons. The file didn't exist (it was on en:wp, not Commons). I moved the file to Commons, but RationalWiki still thinks it doesn't exist in the foreign file repo. "?action=purge" does nothing. How long do I have to wait? RW is using 1.14.1. - David Gerard 12:48, 31 July 2010 (UTC)
- ... aaaand there it is. Never mind me - David Gerard 12:55, 31 July 2010 (UTC)
Scalability issues still present?
Have the issues related to scalability been solved? Or is there still a risk of DoS attacks? Has the "internal bandwidth limitation" been implemented? --Spangineer 13:25, 11 May 2011 (UTC)
Technical documentation would be helpful
This could benefit from some technical docs of how this works. Badon 02:30, 27 November 2011 (UTC)
Bug
Very useful, but doesn't work with djvu. Marc 01:30, 9 December 2011 (UTC)
- What error do you get? If you see a file name instead of the actual image, go to Manual:How to use DjVu with MediaWiki and fill in information in your LocalSettings.php under the section for your operating system and then retry. --Stefan2 00:18, 27 January 2012 (UTC)
.svg as an example
Maybe a .png file from commons would be better? Not everyone has .svg support on their wiki. Schalice (talk) 00:11, 16 February 2012 (UTC)
Doesn't work
It doesn't work...settings seem fine in localsettings.php What could be wrong?
Jobbe
For me neither, it is not working. I am under the impression I have set everything correctly:
- $wgUseInstantCommons = true; in LocalSettings.php
- SElinux has been set correctly so that I can upload local files to my Wiki following the SELinux configuration page.
- I even tried the deprecated:
$wgForeignFileRepos[] = array( 'class' => 'ForeignAPIRepo', 'name' => 'shared', 'apibase' => 'http://commons.wikimedia.org/w/api.php', 'fetchDescription' => true, // Optional 'descriptionCacheExpiry' => 43200, // 12 hours, optional (values are seconds) 'apiThumbCacheExpiry' => 43200, // 12 hours, optional, but required for local thumb caching );
When I follow the explanations on the InstantCommons Page, I end up with a red link on my page, meaning the file I am trying to link to was not found. I have tried that with several image extensions, namely .png, .jpg and .svg without any luck.
I am running:
- WikiMedia 1.19.1
- Fedora 16 (with SElinux)
- Php 5.3.15
- MySql Ver 14.14 Distrib 5.5.25a, for Linux (x86_64)
- I am running my MediaWiki website locally (at http://localhost/mediawiki/xxx)
Could anyone give me a hand with this? Any suggestion is most welcome.
Euloiix (talk) 15:32, 28 August 2012 (UTC)
- Since 1.16 it's only needed, that you set "$wgUseInstantCommons = true;" in your LocalSetting.php. The way with ForeignAPIRepo is for older ones. --Starwhooper (talk) 07:19, 16 October 2012 (UTC)
Doesn't work for IP-visitors
Hi everyone,
I'm working in a German FanWiki and we noticed sort of a bug in the Extension: If your aren't logged in and visit a page as an IP-user, Commons-pictures aren't shown. All you see is the set picture-size, for example "300px". This is shown as a working link to the Commons-Picture-Article, but the picture itself is not visibly.
I just wanted to report this as a "known bug", so that the developers can fix it soon... --Col. sheppard (talk) 12:04, 8 May 2012 (UTC)
Mirror the File: namespace
An option for getting the necessary metadata could be to mirror the File: namespace. One could download a dump of that namespace and then subscribe to get updates when there are changes to it. Leucosticte (talk) 05:22, 1 August 2012 (UTC)
Enable by default
What are the obstacles to enabling this by default? It would a very good way to make MediaWiki more useful by default and Commons more used. Maybe there are some prerequisites to check before, like special permissions on directories or cache/thumb configs? I've indeed seen wikis failing with such problems, but they're not mentioned in the docs anyway. --Nemo 06:34, 19 August 2012 (UTC)
- One issue is that when the server or network doesn't allow MediaWiki to connect to commons.wikimedia.org, every page load with a picture has to wait for curl to timeout. Also, I personally like that MediaWiki doesn't have any features that make outbound http connections by default. CSteipp (talk) 17:13, 30 May 2013 (UTC)
- Is there a way to make InstantCommons (or a similar config) smarter, so that it finds out whether that's the case or not? Or maybe, just include it as option in the installer? --Nemo 17:41, 30 May 2013 (UTC)
- There is no way we are going to enable instant commons by default in MediaWiki core. That should always be enabled specifically. One possibility would be to add a step in the installer to ask the user whether they want to rely on this, we could even test it out during the install process. As a default process, it must not be enabled, that will lead any company to potentially leak private information to the wikimedia servers. Antoine "hashar" Musso (talk) 13:49, 10 June 2013 (UTC)
If a Commons file is deleted
Hi - could someone clarify what will happen on the non-WMF wiki if a page is using a file which is deleted from Commons, please?
Will the locally cached image and its information remain on the local wiki? If not, which is the best way to 'lock in' an image and the licensing info? Thanks LunarLander (talk) 15:00, 9 April 2013 (UTC)
- The image just disappears and becomes a red link. This usually means that it was a copyright violation, so you don't want to keep such images. If you don't care about copyright violations and such, you should upload locally. bugzilla:46525 would help reducing deletions of used images. --Nemo 15:17, 9 April 2013 (UTC)
- Thanks for your reply, Nemo. I'm now clear on the InstantCommons feature.
- Perhaps this is straying into a question that should be asked elsewhere but the answer could be useful to projects considering using InstantCommons: I'm not very familiar with the Commons deletion policy and was concerned about images that are no longer used on a WMF project. Here's an example: Wikipedia:Simeon Alexiadis will soon be deleted for not meeting the notability guideline but - as someone who has represented Greece in rugby league - the subject is notable enough for inclusion on Rugby League Wiki. Would this image be safe from Commons:Commons:Deletion_policy#Out_of_scope?
- Thank you for the bugzilla link. That would be useful, if implemented. LunarLander (talk) 19:50, 9 April 2013 (UTC)
- Yes. On Commons we have a much more liberal idea of what might be educationally useful. Mattbuck (talk) 20:24, 9 April 2013 (UTC)
- Great, thank you. LunarLander (talk) 21:46, 9 April 2013 (UTC)
- Yes. On Commons we have a much more liberal idea of what might be educationally useful. Mattbuck (talk) 20:24, 9 April 2013 (UTC)
Doesn't work with wiki v 1.20.5 but works with 1.16
I have the following problem:
I'm about to upgrade my wiki from version 1.16 and move it to a new hosting (virtual server using OpenSUSE).
When I open a page on old version of my wiki (1.16, shared hosting) everything is ok - picutres are visible. But when I open a new (test) version of my wiki (1.20.5, virtual server using OpenSUSE) only blue links to the picture can be seen (its blue) but pictures themselves aren't visible. When I click on the link - the page with the picture opens and everything seems to be ok.
Below you can find links to the same article using new and old wiki. New - doesn't work. Old - works fine.
here you can find info concerning my new (test) wiki version and installed extensions
I presume I've made a mistake when configuring my wiki but I don't have an idea what mistake it is and where. I will be grateful for any hints what's wrong. Thanks in advance for your help! Pawel Niemczuk (talk) 13:28, 27 May 2013 (UTC)
- Are you sure it's not a problem with OpenSUSE rather than with 1.20.5? Check things like the path to imagemagick and the cache configuration, enable debug info. --Nemo 13:43, 27 May 2013 (UTC)
I haven't installed ImageMagic on my "new" wiki, nor have I on the "old" one. As far as I understand pictures transcluded from Commons are not rendered on the computer hosting my website but by the Commons-hosting one. I haven't installed ImageMagic for I don't want to upload svg files on my wiki now, I only want to embed files hosted on Commons. It works on the "old" wiki, doesn't on the "new" one. But, let me underline it once again, the Commons-hosted images display correctly when I click a link to such file. So, as far as I understand, the problem is not with rendering but with embedding / transcluding Commons-hosted images to my wiki.
Pls correct me if understand anything wrong. I'm stil a wiki-newbie (i.e. I'm an experienced and quite skilled user but not a sysadmin and server admin). Thanx in advance! Pawel Niemczuk (talk) 22:42, 27 May 2013 (UTC)
Future potential - publisher/subscriber model
It is suggested in the "Future potential" section that in a publisher/subscribe[r] model there would be a database of images used in subscribing wikis. The threat of cross-wiki vandalism is highlighted.
If there were a database of subscribing wikis, there would be no need to list every single image used on an outside wiki. It might however allow a procedure to notify a wiki if an image it uses is deleted or renamed (that wiki could then take whatever action it thinks fit):
- If a file is deleted from Commons or renamed, WikiMedia could check through all the subscribing wikis to see if that file is used in any of them, and if so then send an automated message (by e-mail or a note on an apporpriate page of that wiki) notifying that this has been done.
If the list of subscribing wikis were held in confidence, that eliminates the risk of cross-wiki spamming. (For the moment we have an open list, if an unscientific one, on Sites using InstantCommons.
If a Commons file is updated
Similar to the question above about If a Commons file is deleted, what happens when a file on Commons is updated via the "Upload a new version of this file" link on the file description page? From what I'm seeing, the copy of the file that is cached to a remote wiki is taken from http://upload.wikimedia.org so it is tied to a particular version of the image. Updates/new versions get a whole new URL on upload.wikimedia.org so a subsequent new request for the file using [[File:xxxxxx.xxx]] will get the updated version cached locally, but existing pages on the remote wiki will still point to the old version, and no amount of touching, purging, etc seems to fix this. AugurNZ ✐⌕ 22:31, 26 August 2013 (UTC)
- This I think is the point addressed in the suggestion about a possible publisher/subscriber model, on which I commented above. If a file is renamed on Commons, it vanishes from any wiki which uses it, as the wiki is pointing to a location that is no longer there. The various Wikipediae pick it up automatically but remote wikis will not.
- If there were a voluntary list of remote wikis using Commons pictures then they could be notified of a change of deletion of any picture they use, and be left to make their own arrangements. That would not be practical if every wiki were notified of every change (they would be overwhelmed) but if a bot on Commons could check the list and see which listed wikis use the file in question, it could notify them. Hogweard (talk) 08:40, 18 October 2013 (UTC)
InstantData?
If Wikipedia pages are going to use data from WikiData (aside from just interlanguage links), then I would imagine we're going to need an InstantData local repository for non-WMF wikis, so that they can still use Wikipedia content. Does this sound like a good idea, or is there an alternative? Leucosticte (talk) 19:24, 27 November 2013 (UTC)
Behind a firewall or load balancer
It should be noted that behind a firewall or load balancer, you should allow outgoing http and https requests to
- commons.wikimedia.org (IP 91.198.174.192 as of now)
- upload.wikimedia.org (IP 91.198.174.208 as of now)
- These IP addresses seem to be differnt now, 20 November 2014:
- * commons.wikimedia.org (IP 208.80.154.224 )
- * upload.wikimedia.org (IP 208.80.154.240 )
- It would have been nice if Wikimedia would inform about such changes. The wikis where we use instant commons, which are behind a a firewall, stopped working as of yesterday, until we understood the problem and updated the firewall rules. --Aloist (talk) 09:14, 20 November 2014 (UTC)
- Aloist, can't you just whitelist all Wikimedia Foundation IPs? Many ranges here are still correct: wikitech:IP addresses. Hardcoding specific IPs is not a practice that will ever be supported (with notifications as you ask, or anything). --Nemo 09:47, 20 November 2014 (UTC)
- Thanks, Nemo, I had not bee aware of the page with the ranges. I use iptables and I don't think my iptables rules would allow anything else than hardcoded IP. --Aloist (talk) 10:34, 20 November 2014 (UTC)
- Aloist, can't you just whitelist all Wikimedia Foundation IPs? Many ranges here are still correct: wikitech:IP addresses. Hardcoding specific IPs is not a practice that will ever be supported (with notifications as you ask, or anything). --Nemo 09:47, 20 November 2014 (UTC)
Why all the .jpg files from Commons cannot be displayed on my wiki?
Why all the .jpg files from Commons cannot be displayed on my wiki? for example, this file [1] from Commons cannot be shown on my wiki [2].
But, .svg files from Commons can be displayed. e.g. [3] ← [4].
What can I do to fix this problem? Thanks in advance! --Betoseha (talk) 05:16, 11 August 2014 (UTC)
Enabling by default
"Ideally, however, the feature should be enabled by default (provided a writable upload directory is specified) to allow the largest possible number of users to use Wikimedia Commons content." If this is true, then why don't we enable it by default? If it's not true, then we should remove this sentence from the article. Leucosticte (talk) 14:19, 29 September 2014 (UTC)
- I already proposed it in [5] and #Enable by default? and there are no objections in principle, so the sentence is true. The ideal world in question is one where MediaWiki can magically guess that it's not supposed to have access to the internet, among other things. --Nemo 17:22, 29 September 2014 (UTC)
New policy or a wide error?
I am using InstantCommons in many different wiki sites accross different platforms. In the last days all of those sited manifest the same issue, not showing the pictures and displayinh the broken file path category. This issue is probably due to some kind of policy change in wiki commons. How should I handle this? You can see the missing image in this page for example: http://edu.wiki.org.il
- Apparently it was somehow fixed and the sites are again displaying the images.
InstantCommons stopped working though CURL is available
I have a problem with InstantCommons on this site. Don't know what to do :( --Amakuha (talk) 11:30, 1 July 2015 (UTC)
- Yesterday evening it stopped working on Wikishire. (All the site's images, across close on 12,500 articles, are from Commons apart from the site's own logo.) Last time that happened we had to upload a whole new version of MediaWiki. Any help from anyone would be welcomed. Hogweard (talk) 16:06, 6 November 2015 (UTC)
- The same problem here on HurwenenWiki. --RenéV (talk) 17:15, 6 November 2015 (UTC)
- That's because of phabricator:T102566#1785750. InstantCommons#HTTPS might fix your issue. Nemo 19:14, 6 November 2015 (UTC)
- Not helpful at all. Already updated cURL and still broken. Acnetj (talk) 22:01, 6 November 2015 (UTC)
- How about [6]? --Nemo 22:05, 6 November 2015 (UTC)
- Don't think there's anything to do with it. I used console command "curl -vso /dev/null 'https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png' && echo success || echo failed" and showed success. Acnetj (talk) 22:20, 6 November 2015 (UTC)
- php-curl and command line curl are totally separate. Success on the command line means nothing as to whether its installed as a php extension (try making a test php file containing only
<?php phpinfo();
) Bawolff (talk) 04:29, 8 November 2015 (UTC)
- php-curl and command line curl are totally separate. Success on the command line means nothing as to whether its installed as a php extension (try making a test php file containing only
- Don't think there's anything to do with it. I used console command "curl -vso /dev/null 'https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png' && echo success || echo failed" and showed success. Acnetj (talk) 22:20, 6 November 2015 (UTC)
- How about [6]? --Nemo 22:05, 6 November 2015 (UTC)
- Not helpful at all. Already updated cURL and still broken. Acnetj (talk) 22:01, 6 November 2015 (UTC)
- That's because of phabricator:T102566#1785750. InstantCommons#HTTPS might fix your issue. Nemo 19:14, 6 November 2015 (UTC)
- The same problem here on HurwenenWiki. --RenéV (talk) 17:15, 6 November 2015 (UTC)
- RationalWiki just got hit by this too. I added this code fragment from the Phabricator ticket to LocalSettings.php and all is well now:
$wgUseInstantCommons = false; $wgForeignFileRepos[] = array( 'class' => 'ForeignAPIRepo', 'name' => 'wikimediacommons', 'apibase' => 'https://commons.wikimedia.org/w/api.php', 'hashLevels' => 2, 'fetchDescription' => true, 'descriptionCacheExpiry' => 43200, 'apiThumbCacheExpiry' => 86400, );
- - David Gerard (talk) 00:52, 7 November 2015 (UTC)
- Works fine, thanks. --RenéV (talk) 08:47, 7 November 2015 (UTC)
- Yup - it's got Wikishire working again too. Thank you. Hogweard (talk) 20:39, 7 November 2015 (UTC)
- Thanks, it worked. I also tried to add a debug log at a point where the repo should definitely have been added, and it wasn't. Probably a problem with the code that adds it. I'm running version 1.24, and Commons suddenly stopped working. --85.76.183.139 12:11, 10 November 2015 (UTC)
- Yup - it's got Wikishire working again too. Thank you. Hogweard (talk) 20:39, 7 November 2015 (UTC)
- Works fine, thanks. --RenéV (talk) 08:47, 7 November 2015 (UTC)
Stop working
Hello, I use Instant Commons very long, so the mechanic behind the code is known to me. But today, the script stops working without any reason. I don't changed anything on my server, so there is no real reason that the problem belongs to me. Is there any change at Wikimedia Commons that I need to update my code? I use this:
$wgForeignFileRepos[] = array( # Angepasstes Instant Commons // 'class' => 'ForeignAPIRepo', 'name' => 'commonswiki', 'apibase' => 'https://commons.wikimedia.org/w/api.php', 'fetchDescription' => true, // Optional Beschreibung verwenden -> Ja wegen Lizenz 'descriptionCacheExpiry' => 0, // 12 hours, optional (values are seconds) 43200 - Nein wegen Speicher 'apiThumbCacheExpiry' => 0, // 12 hours, optional, but required for local thumb caching - Nein wegen Speicher );
Best regards ChNPP (talk) 22:23, 13 October 2016 (UTC)
- We have a similar Problem in the german CityWiki http://www.tuepedia.de since approximately End of September 2016 - the instantcommons-pictures are only red links. We use MediaWiki 1.24. and the following code:
$wgUseInstantCommons = false; $wgForeignFileRepos[] = array( 'class' => 'ForeignAPIRepo', 'name' => 'wikimediacommons', 'apibase' => 'https://commons.wikimedia.org/w/api.php', 'hashLevels' => 2, 'fetchDescription' => true, 'descriptionCacheExpiry' => 43200, 'apiThumbCacheExpiry' => 86400, );
Is there any Help available? Thanks in advance and best Regards from Germany - --Abilus (talk) 16:03, 3 November 2016 (UTC)
Try see if your certs are up to date ...
$ curl 'https://commons.wikimedia.org/' curl: (60) SSL certificate problem: unable to get local issuer certificate or curl: (60) Peer certificate cannot be authenticated with known CA certificates
If that's your problem you can fetch
mkdir /opt/curl; cd /opt/curl wget 'https://curl.haxx.se/ca/cacert.pem'
test if that works?
$ curl --cacert /opt/curl/cacert.pem 'https://commons.wikimedia.org/'
and you can then point to it in your php.ini:
curl.cainfo = /opt/curl/cacert.pem
--Kim Bruning (talk) 17:53, 27 December 2016 (UTC)
Fine, now works for me. Thanks Kim. A little fix. If
wget 'https://curl.haxx.se/ca/cacert.pem'
ends with
ERROR: certificate common name “c.sni.fastly.net” doesn’t match requested host name “curl.haxx.se”
then
wget 'https://curl.haxx.se/ca/cacert.pem' --no-check-certificate
can work without error. Ency (talk) 22:02, 4 March 2019 (UTC)
Using InstantCommons
Am I correct, if I set $wgUseInstantCommons = true; it means that the images used at my wiki will be hosted at my Server? Thank you!— Preceding unsigned comment added by Fokebox (talk • contribs) 2018-03-16 15:30 (UTC)
- No, you upload image to your wiki are not transferred to Wikimedia Commons. -- 星耀晨曦 (talk) 12:20, 17 March 2018 (UTC)
Bounty for anyone who can enable this feature on my wiki.
I have been trying to enable this feature for a long time but haven't been able to figure out why it hasn't work yet. So I posted up this at upwork for anyone capable and interested. Thanks! --HausaDictionary (talk) 11:55, 24 May 2018 (UTC)
Question about how this feature actually works
I have set up a (private, not hosted by Wikimedia I should be clear) test wiki and enabled InstantCommons. When I use it to load an image, some wonderful and magical things happen, such as the proper licensing information and history being shown, and it makes me happy to know that this is the official sanctioned and "right way" to easily reuse images from Commons.
However, what I was surprised to see is that actually (when I look at the html of a page) this is hotlinking directly to upload.wikimedia.org. This surprised me because the claim is made on InstantCommons that "InstantCommons-enabled wikis cache Commons content so that it is only downloaded once, and subsequent pageviews load the locally existing copy.".
The amount of traffic to my little test wiki is next to zero right now and I expect it to stay that way for awhile, but I'm curious: does the InstantCommons feature work differently than this page claims, or is there something wrong with my installation?--Jimbo Wales (talk) 12:01, 11 February 2019 (UTC)
Renaming
How to rename an image included on my wiki though Instant Commons? Can I edit the local description? How to do that the proper way? — Preceding unsigned comment added by 87.91.51.235 (talk • contribs) 2019-06-04 05:38 (UTC)
Fails for REDIRECTs
In some cases, I prefer using a locally meaningful project image name, e.g. File:logo (project).svg which can be redirected to an arbitrary file of any type at any time in just one place. This works for my local files. It does not work if the redirect target is a file in commons. For these, I have to download a local copy, which kind of defeats the purpose of "instant".
Note that this could also address the previous question (#Renaming): create any name and redirect it to the actual name in commons.
My redirect wikitext for File:logo (project).svg would look like
#REDIRECT [[:File:name in commons but not locally.svg]]
While the above is processed OK, it is the uses of File:logo (project).svg that don't work.
InstantCommons or Instant Commons
Hi,
I've mostly found the name in CamelCase without space (InstantCommons) but sometimes we can find the name with a space (Instant Commons). For instance on the Mediawiki messages like translatewiki:MediaWiki:Config-instantcommons/en (and passim) or Special:WhatLinksHere/Instant_Commons. It would be easier for everyone if only one variant was in use everywhere.
Cheers, VIGNERON (talk) 15:28, 8 October 2019 (UTC)