Jump to content

Extension talk:MultimediaViewer/Flow export

Add topic
From mediawiki.org


Error in hooks file

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Appear this error: atal error: Class 'BetaFeatures' not found in /home2/.../MultimediaViewer/MultimediaViewerHooks.php on line 29 Regiosfera (talk) 00:53, 31 December 2013 (UTC)Reply

Same for me, and I cannot yet install betaFeatures because I ran 1.22. Found any workarounds? Wess (talk) 17:57, 29 September 2014 (UTC)Reply
Here is what worked for me (mediawiki 1.22) - replace lines 28-35 in MultimediaViewerHooks.php with this:
	static function getModules( &$out, &$skin ) {
			if	( count( $out->getFileSearchOptions() ) > 0 ) {
			$out->addModules( array( 'ext.multimediaViewer' ) );
		}
		return true;
	}
Wess (talk) 18:20, 29 September 2014 (UTC)Reply
The fix for this was gerrit change Gerrit change 92030. What version of MediaViewer are you using? I can do a backport. Tgr (WMF) (talk) 20:56, 29 September 2014 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Setting up context for metadata

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


The example link provided, which is pointing to marktraceur.info is gone. It will be nice to get an updated link. Cheers [[kgh]] (talk) 08:24, 22 April 2014 (UTC)Reply

I've removed that part of the page - it's outdated.
Instead, use the export file we provide along with Special:Import to set up a good environment. MarkTraceur (talk) 15:15, 22 April 2014 (UTC)Reply
Thanks a ton! I guess I will give it a shot soon. Cheers [[kgh]] (talk) 17:42, 22 April 2014 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

SVG support

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


This extention don't work with SVG. MW 1.23. Please add suppor for SVG or disable handling it. Unikum (talk) 16:01, 17 May 2014 (UTC)Reply

bugzilla:58663 kind of implies that it does so steps to reproduce would be welcome. If there is no ticket yet, please feel free to file an enhancement request: https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&component=MultimediaViewer AKlapper (WMF) (talk) 09:02, 20 May 2014 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Tagging for extension distributor

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I am not sure if this extension is already ready for the MW 1.23 LTS release since it was not tagged for it so far. I think we should get as many cool changes to this extension's 1.23 version as possible. [[kgh]] (talk) 19:52, 16 June 2014 (UTC)Reply

Apparently there is a general problem with tagging as per this thread. However, I guess an individual tag for REL1_23 may still be a good idea for this extension as well as heaps of backports for this LTS release. [[kgh]] (talk) 12:35, 16 July 2014 (UTC)Reply
According to the last comment in bug 64157, the issue with the missing branches are fixed. MediaViewer does have a REL1_23 branch which looks reasonably recent; is there any further tagging needed? Tgr (WMF) (talk) 17:18, 16 July 2014 (UTC)Reply
Yeah, this is sort-of fixed. :) At the time I opened this thread we were still hit by bug 65852. So no worries.
However this particular extension is currently still under very heavy development. Thus as many backports to the 1.23 branch will be appreciated. :) Besides, I really like this extension and the features it provides. [[kgh]] (talk) 17:59, 16 July 2014 (UTC)Reply
The current version has been backported. Tgr (WMF) (talk) 18:38, 23 July 2014 (UTC)Reply
That's great news! Cool and thanks a ton! I believe that I will not be the only one happy about this. Keep up the good work on this useful extension. Cheers [[kgh]] (talk) 08:19, 24 July 2014 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Retrieving Metadata from locally uploaded files

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


The CommonsMetadata extension allows to fetch the data from commons which is great. What does one have to do to fetch data from a locally uploaded file. Is there some guide around which I did not find so far? A pointer or some advice will be greatly appreciated. I guess that some specific templates will have to be set up for this to work.

Cheers [[kgh]] (talk) 12:38, 16 July 2014 (UTC)Reply

Oh my gosh. Senior moments I suppose. Probably this is the way to do it. I will try to figure out if it is working. [[kgh]] (talk) 12:48, 16 July 2014 (UTC)Reply
Install CommonsMetadata locally and use the right HTML code in templates; see Extension:CommonsMetadata#Returned_data and Multimedia/Media_Viewer/Template_compatibility.
Extension:MultimediaViewer/Exported test wiki is a small set of Commons templates (stripped from most logic so they don't make an average MediaWiki box explode and don't need a dozen template logic extensions installed), for testing purposes. Tgr (WMF) (talk) 17:12, 16 July 2014 (UTC)Reply
Hey, cool. Thank you very much for your information. This brings light into my dark. I did not find the template compatibility page before. Great since this gives me something to work on. [[kgh]] (talk) 18:04, 16 July 2014 (UTC)Reply
Something is going wrong. What I have done is to add the following to the template called "Datei":
<div class="fileinfotpl" style="display:none">
<span class="fileinfotpl_desc">{{{Beschreibung|}}}</span>
<span class="fileinfotpl_date">{{{Datum|}}}</span>
<span class="fileinfotpl_aut">{{{Schöpfer|}}}</span>
</div>
After that I added the template to the file's page, purged it again, edited it a second time to really meet the suggestion of the Q&A section on the help page. However, nothing happens.
Before that I accidentally added the license information to that very template too, but this broke everything. The only thing this proved is that the extension CommonsMetadata is actually trying to fetch something. Because of this I am puzzled that it is not working even though everything was done as instructed.
I am working with MW 1.23.1, MultimediaViewer of 2014-04-22 (e0d3c9e) and CommonsMetadata of 2014-06-03 (6b330e1). [[kgh]] (talk) 19:53, 16 July 2014 (UTC)Reply
CommonsMetadata follows the prescriptions of commons:COM:MRD very strictly: tables have to be tables, <td>s have to be <td>s, ids have to be ids and not classes.
That was probably not a good idea, but that's how it is.
If you just want to test whether your system works at all, you can grab the information template from the export, that one is guranateed to work. Tgr (WMF) (talk) 21:14, 16 July 2014 (UTC)Reply
I was kinda hoping that just providing the correct class names and wrapping the necessary stuff with them will do the trick. Yesterday was not one of my best days, too. Now the situation is clear and it is not even hard to set all up to make it work. Thanks again for bearing with me. Works perfect! [[kgh]] (talk) 14:24, 17 July 2014 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Performance

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Is there a chance to tune the performance of this extension somehow on a server that neither allows for APC nor for memcached. What I have done is to activate $wgUseFileCache but his one has basically a different scope so this did not help much if at all. Probably the best recommendation will be to upload just files in webquality as jpeg or gif (100 - 250 KB) rather than in full quality (1 MB+)? [[kgh]] (talk) 08:47, 8 August 2014 (UTC)Reply

$wgUseFileCache is about page caching. You probably want $wgMainCacheType = CACHE_DB; although this depends on what exactly is slow (maybe you could profile it?). FWIW image transformations are cached by storing the thumbnails, so that should not be affected by lack of memcached/APC.
(Personally, I would just switch hosts. Running a site without an opcode cache is a bit masochistic.) Tgr (WMF) (talk) 20:01, 11 August 2014 (UTC)Reply
Thanks a bunch for your help and suggestion. Yeah, you are right with your assessment about the host and I totally agree, but reality prevents changes in this respect. So ...
I set the main cache type to CACHE_ANYTHING which is basically the same as CACHE_DB in this case.
A performance issue was Vector's JavaScript, but there was actually a much bigger worry: browser caching and content compression were not enabled. :( I believe thing should be much better now. [[kgh]] (talk) 13:57, 23 August 2014 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

How to add description

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


How add description and license? I have set uped, but still appear "no description" in file. Edmundopg (talk) 23:40, 6 September 2014 (UTC)Reply

Does Multimedia/Media Viewer/Template compatibility help? Nemo 07:23, 7 September 2014 (UTC)Reply
Not at all, for example, I imported Template:Information to my wiki, first, this make an error script, but template show it anyway, I copy a code to use it in a description and it's not working. Edmundopg (talk) 08:00, 7 September 2014 (UTC)Reply
You need to install Extension:CommonsMetadata. Also, importing complex templates from Commons is easy to do properly; there are some simple test templates in Extension:MultimediaViewer/Exported_test_wiki which can help decide whether the problem is with your templates or your MediaWiki setup. Tgr (WMF) (talk) 09:18, 7 September 2014 (UTC)Reply
I have gone through this process (see this thread) and it is easy to achieve. As a matter of fact MultimediaViewer is not only displaying the description provided on the file's page but also the one provided on the page where the file was inserted, at least it used to do this in the past. [[kgh]] (talk) 17:31, 7 September 2014 (UTC)Reply
It not work for me, I did it, but not work, show template in file page, but not detect images and extension either Edmundopg (talk) 22:24, 7 September 2014 (UTC)Reply
Which extension does not show up on your "Special:Version" page? However, both MultimediaViewer and CommonsMetadata must indeed properly be installed for this to work. [[kgh]] (talk) 08:27, 9 September 2014 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Further backports to MW 1.23 branch

[edit]

Since the last backport to this branch at the end of June a lot of changes have been done to this extension. Perhaps it will be possible to backport all or some of them to the recent LTS branch. [[kgh]] (talk) 19:55, 3 November 2014 (UTC)Reply

I opened phab:T85193 to track this, but there were several breaking changes in OOJS and core so this will probably be more trouble than what it's worth. Tgr (WMF) (talk) 02:28, 23 December 2014 (UTC)Reply
If it was not a LTS version I would not have asked. However breaking changes seem to be the limit. Thank you for considering it. [[kgh]] (talk) 11:26, 24 December 2014 (UTC)Reply

Black site on close MultimediaViewer

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Shows images in MultimediaViewer works ok, but when I'm closing it I have black site in browser and I have to refresh page. Any ideas why this is happening?

I have mediawiki on Windows Server 2012 R2 & I use Firefox. Monic abc (talk) 13:47, 17 December 2014 (UTC)Reply

Can you check the browser's developer console for errors? That would give us a clue as to why it's not closing.
Also, is the image on your wiki, or on Commons? Did you install Extension:CommonsMetadata? Any other information we should know? MarkTraceur (talk) 14:19, 17 December 2014 (UTC)Reply
There is such error in the console when I'm closing viewer:
TypeError: this.data(...) is undefined in load.php:10 file:line.
Aaand when I click on load.php:10 it shows in Debugger script, which path is: myhost/mywiki/load.php?debug=false&lang=pl&modules=jquery.color,colorUtil,fullscreen,tipsy|mmv|mmv.ThumbnailWidthCalulator,ligskin=vector&version=20141219T101025Z&*
I don't know where it's Commons? ;> I've just uploaded images with normal option in toolbox, so they are in "images" folder.
I didn't install this extension, because it is not necessary, is it?
Other informations:
In my LocalSettings.php file I have this:
require_once "$IP/extensions/MultimediaViewer/MultimediaViewer.php";
require_once "$IP/extensions/BetaFeatures/BetaFeatures.php";
$wgMediaViewerIsInBeta = true;
$wgEnableMediaViewerForLoggedInUsersOnly = true; Monic abc (talk) 10:06, 19 December 2014 (UTC)Reply
What MediaWiki and MultimediaViewer versions are you using?
Can you add ?debug=1 to the URL of the page where you see this error, reproduce the error and check the error console again? Tgr (WMF) (talk) 18:38, 19 December 2014 (UTC)Reply
I use:
MediaWiki 1.23.0
PHP 5.3.28 (cgi-fcgi)
MySQL 5.5.40
MultimediaViewer 0.3.0 (the last downloaded version from GitHub is from 2014-12-17)
I add this ?debug=1 and nothing has changed.
On the other hand when I checked debugger option 'stop on exceptions' and close viewer, then debugger stopped at line: "return this.data('tipsy') [options]();" which is from there:
$.fn.tipsy = function (options) {
if (options === true) {
return this.data('tipsy');
} else if (typeof options == 'string') {
return this.data('tipsy') [options]();
} Monic abc (talk) 11:58, 22 December 2014 (UTC)Reply
You should always use the same version of MediaWiki and extensions. You can use the "Download snapshot" link in the infobox on the extension page to get it. Tgr (WMF) (talk) 02:17, 23 December 2014 (UTC)Reply
It works! Stupid me >.< I have no idea, that it could make such a big problem.
Thanks a lot! ;) Monic abc (talk) 08:07, 23 December 2014 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

causes errors in version 1.24 with wikiEditor and other extensions

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Hi

In Version 1.24 when I install this extension the WikiEditor stops working. The following error shows up:

Uncaught Error: Unknown dependency: mediawiki.ui.icon Christharp (talk) 01:41, 23 December 2014 (UTC)Reply

mediawiki.ui.icon is added in MediaWiki 1.25. You should always use the same version of MediaWiki and extensions. You can use the "Download snapshot" link in the infobox on the extension page to get it. Tgr (WMF) (talk) 02:17, 23 December 2014 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

mod_pagespeed rewrites

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Hi The Viewer has been only working about 50% of the time on photos I upload. I noticed this is the problem:

File:Example1.jpg is the name of file

I go to open in the viewer and the viewer is referencing:

File:Example2.jpg.pagespeed.ic.LMRUmMck7S.jpg (or something like this)

After going to Google I found out pagespeed is:

mod_pagespeed rewrites the image URL to an optimized name and embeds the size, as well as the fingerprint of the content into the filename.

But then the Multimedia viewer says the file doesn't exist.

Thoughts on fixing this? thanks Christharp (talk) 18:51, 29 January 2015 (UTC)Reply

Not use mod_pagespeed? (Or the filter that messes with the HTML source, anyway.)
Changing filenames is a fairly bad idea which will break all but the most static of web applications. Tgr (WMF) (talk) 21:36, 29 January 2015 (UTC)Reply
I was afraid that you were going to say that -- the server company I use has it enabled it by default. Since Google is behind this push to use mod_pagespeed I assume this problem will only grow, but meanwhile I'll see if I can get rid of it. Christharp (talk) 22:01, 29 January 2015 (UTC)Reply
Sounds like not the right company to be with :) IMO you should complain or leave - a hosting provider should not use any kind of HTML rewriting functionality without the consent of their users.
Anyway if you can give exact examples of requests that are broken and when they are fired, I will see if there is an easy workaround. Tgr (WMF) (talk) 22:11, 29 January 2015 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

CORS bug

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I installed MediaViewer (and CommonsMetadata) in the wiki at http://www.auslandssemester-bali.de, and it works fine for the most part, but when I omit the 'www', I get the following error:

<pre style="white-space:pre-wrap;">Error: Could not load thumbnail data. could not load image from http://www.auslandssemester-bali.de/images/thumb/a/a3/Apartment-Nala-Seminyak-Bali-14.jpg/320px-Apartment-Nala-Seminyak-Bali-14.jpg</pre>

Also the console throws this error:

<pre style="white-space:pre-wrap;">XMLHttpRequest cannot load http://www.auslandssemester-bali.de/images/thumb/a/a3/Apartment-Nala-Seminyak-Bali-14.jpg/320px-Apartment-Nala-Seminyak-Bali-14.jpg. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://auslandssemester-bali.de' is therefore not allowed access.</pre>

My images/.htaccess file has the required line:

Header add Access-Control-Allow-Origin "*"

I tried setting and modifying the relevant headers at runtime in all the entry points, but no luck. I also tried adding the following to LocalSettings.php:

$wgCrossSiteAJAXdomains = array( 'auslandssemester-bali.de' );

Yet nothing. Maybe it's something in my server setup, but it may also be a MediaViewer bug. Anyone knows what may be wrong or how to fix it? Thanks! LFS (talk) 17:16, 22 April 2015 (UTC)Reply

That .htaccess rule does not seem to be working:
$ curl -vso /dev/null 'http://www.auslandssemester-bali.de/images/thumb/a/a3/Apartment-Nala-Seminyak-Bali-14.jpg/320px-Apartment-Nala-Seminyak-Bali-14.jpg'
* Hostname was NOT found in DNS cache
*   Trying 216.70.97.136...
* Connected to www.auslandssemester-bali.de (216.70.97.136) port 80 (#0)
> GET /images/thumb/a/a3/Apartment-Nala-Seminyak-Bali-14.jpg/320px-Apartment-Nala-Seminyak-Bali-14.jpg HTTP/1.1
> User-Agent: curl/7.35.0
> Host: www.auslandssemester-bali.de
> Accept: */*
> 
< HTTP/1.1 200 OK
* Server nginx is not blacklisted
< Server: nginx
< Date: Wed, 22 Apr 2015 18:27:23 GMT
< Content-Type: image/jpeg
< Content-Length: 48804
< Last-Modified: Wed, 22 Apr 2015 16:51:43 GMT
< Connection: keep-alive
< ETag: "5537d19f-bea4"
< X-Powered-By: PleskLin
< Accept-Ranges: bytes
< 
{ [data not shown]
* Connection #0 to host www.auslandssemester-bali.de left intact
Also, the server claims to be nginx, not apache. Tgr (WMF) (talk) 18:32, 22 April 2015 (UTC)Reply
< HTTP/1.1 200 OK
< Server: nginx
< Date: Wed, 22 Apr 2015 18:35:32 GMT
< Content-Type: image/jpeg
< Content-Length: 35123
< Last-Modified: Thu, 04 Sep 2014 10:21:33 GMT
< Connection: keep-alive
< ETag: "54083d2d-8933"
< X-Powered-By: PleskLin
< Accept-Ranges: bytes
So as you can see your image does not have the header. But it does need one. So whatever you need to do to convince your webserver to add that header to those requests... You probably want to read: http://wiki.nginx.org/LikeApache-htaccess however
$wgCrossSiteAJAXdomains is only relevant for api requests. —TheDJ (Not WMF) (talkcontribs) 18:50, 22 April 2015 (UTC)Reply
Thanks both for your help. Today I woke up smart and realised that the best solution for my case is to force the URL to always have the 'www', by adding the following lines to my .htaccess file:
RewriteCond %{HTTP_HOST} ^auslandssemester-bali.de$
RewriteRule ^(.*) http://www.auslandssemester-bali.de/$1 [R=301]
Problem fixed! LFS (talk) 12:47, 1 May 2015 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

MultimediaViewer simply not working

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I checked on Special:Version but other than that, it doesn't work. 68.203.83.230 01:51, 9 May 2015 (UTC)Reply

Works fine for me. You'll have to be a little more specific than that. Tgr (WMF) (talk) 08:53, 9 May 2015 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Please look at this

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


If the button to commons really has disappeared, that's a major license infraction. Without the real file page, there is no valid licensing information, as well as no valid author information. If this is right, the MV should be shut off asap.

F*** Flow, here's the clickable link.

Edith says:
Another thing: I can't use Phabricator, because I was too outspoken about some useless stuff the devs didn't want to talk about and thus banned me there. So someone else should do this. Grüße vom Sänger ♫(Reden) 15:32, 2 September 2015 (UTC)Reply

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

File description as caption

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Thanks for this great extension! However, I'd like to change two things:

- Right now, the "more details" button leads to the file description page on pool.domain.com (my file repository) instead of bringing me to the local file description page on en.domain.com.

- I'd like use the file description of the local file description page as a caption in the lightbox, no matter what. Right now, it uses the caption of the thumbnail or (if the caption is missing) the file name. I really want the output of { { File:Name.jpg } } as a caption, but I don't know which files of the extension I need to alter. Till Kraemer (talk) 17:27, 14 November 2015 (UTC)Reply

The first is phab:T66491; you'd have to poke at includes/api/ApiQueryImageInfo.php. For the second, see setTitle in resources/mmv/ui/mmv.ui.metadataPanel.js (also the setter in resources/mmv/ui/mmv.ui.description.js for consistency). Tgr (WMF) (talk) 19:13, 14 November 2015 (UTC)Reply
@Tgr (WMF), thanks for your help! I already played around with image.caption in resources/mmv/ui/mmv.ui.metadataPanel.js, but somehow imageData.description doesn't seem to get through. When I remove image.caption and image.filePageTitle.getNameText() no caption shows up. The code on the page looks like this: "<p class="mw-mmv-title-para mw-mmv-ttf-container empty"><span class="mw-mmv-title" original-title=""></span><span class="mw-mmv-ttf-ellipsis" style="display: none;" original-title="">…</span></p>".
I don't really get it, because I'm using Extension:CommonsMetadata and the templates here and my code of the file description page looks like this: "<td id="fileinfotpl_desc" class="fileinfo-paramfield">Description<span class="summary fn" style="display:none">Till Kraemer.jpg</span></td><td class="description"><div class="description mw-content-ltr en" dir="ltr" lang="en" style=""><span class="language en">English: Till Kraemer, 2007</span></div><div class="description mw-content-ltr de" dir="ltr" lang="de" style=""><span class="language de">Deutsch: Till Kraemer, 2007</span></div></td>", so pretty much like the code here. However, I don't have usePageDescriptions in the <script></script> section. Could that be a problem? And do you have any idea how to fix this? Till Kraemer (talk) 22:17, 14 November 2015 (UTC)Reply
You should debug CommonsMetadata and MediaViewer separately. If the description page is right and the extension is working, api.php?action=query&titles=<title>&prop=imageinfo&iiprop=extmetadata&format=jsonfm&iiextmetadatafilter=Description should show you the description. If that does not work, the information never reaches the JS code. Tgr (WMF) (talk) 23:36, 14 November 2015 (UTC)Reply
Thanks for that hint! The output of pool.domain.com for File:Till Kraemer.jpg looks like this:
{
"warnings": {
"query": {
"*": "Formatting of continuation data will be changing soon. To continue using the current formatting, use the 'rawcontinue' parameter. To begin using the new format, pass an empty string for 'continue' in the initial query."
}
},
"query-continue": {
"imageinfo": {
"iistart": "2008-08-24T19:25:38Z"
}
},
"query": {
"normalized": [
{
"from": "File:Till_Kraemer.jpg",
"to": "File:Till Kraemer.jpg"
}
],
"pages": {
"2": {
"pageid": 2,
"ns": 6,
"title": "File:Till Kraemer.jpg",
"imagerepository": "local",
"imageinfo": [
{
"extmetadata": []
}
]
}
}
}
}
...and the output for en.domain.com looks like this:
{
"warnings": {
"query": {
"*": "Formatting of continuation data will be changing soon. To continue using the current formatting, use the 'rawcontinue' parameter. To begin using the new format, pass an empty string for 'continue' in the initial query."
}
},
"query-continue": {
"imageinfo": {
"iistart": "2008-08-24T19:25:38Z"
}
},
"query": {
"normalized": [
{
"from": "File:Till_Kraemer.jpg",
"to": "File:Till Kraemer.jpg"
}
],
"pages": {
"79": {
"pageid": 79,
"ns": 6,
"title": "File:Till Kraemer.jpg",
"imagerepository": "shared",
"imageinfo": [
{
"extmetadata": []
}
]
}
}
}
}
The description on both file description pages is "Till Kraemer, 2007", so it seems like there is some problem.
Somehow, out of the sudden the description appears in the lightbox of pool.domain.com but still not on en.domain.com :( I also can't retrieve file descriptions from pool.domain.com on en.domain.com when I deactivate the Multimedia Viewer. Till Kraemer (talk) 04:07, 15 November 2015 (UTC)Reply
@Tgr (WMF), to fix my first problem, I checked "includes/api/ApiQueryImageInfo.php" as you suggested. I changed "$vals['descriptionurl'] = wfExpandUrl( $file->getDescriptionUrl(), PROTO_CURRENT );" to "$vals['descriptionurl'] = 'http://en.domain.com/wiki/File:' . ($file->getName());". Now, the "more details" button leads to the local file description page. Yay! :) Thanks! Till Kraemer (talk) 15:04, 15 November 2015 (UTC)Reply
If I use "&iiextmetadatafilter=ImageDescription" instead of "&iiextmetadatafilter=Description", I get the following on pool.domain.com:
{
"warnings": {
"query": {
"*": "Formatting of continuation data will be changing soon. To continue using the current formatting, use the 'rawcontinue' parameter. To begin using the new format, pass an empty string for 'continue' in the initial query."
}
},
"query-continue": {
"imageinfo": {
"iistart": "2008-08-24T19:25:38Z"
}
},
"query": {
"normalized": [
{
"from": "File:Till_Kraemer.jpg",
"to": "File:Till Kraemer.jpg"
}
],
"pages": {
"2": {
"pageid": 2,
"ns": 6,
"title": "File:Till Kraemer.jpg",
"imagerepository": "local",
"imageinfo": [
{
"extmetadata": {
"ImageDescription": {
"value": "Till Kraemer, 2007",
"source": "commons-desc-page"
}
}
}
]
}
}
}
}
...but en.domain.com looks still like this:
{
"warnings": {
"query": {
"*": "Formatting of continuation data will be changing soon. To continue using the current formatting, use the 'rawcontinue' parameter. To begin using the new format, pass an empty string for 'continue' in the initial query."
}
},
"query-continue": {
"imageinfo": {
"iistart": "2008-08-24T19:25:38Z"
}
},
"query": {
"normalized": [
{
"from": "File:Till_Kraemer.jpg",
"to": "File:Till Kraemer.jpg"
}
],
"pages": {
"79": {
"pageid": 79,
"ns": 6,
"title": "File:Till Kraemer.jpg",
"imagerepository": "poolwiki",
"imageinfo": [
{
"extmetadata": []
}
]
}
}
}
} Till Kraemer (talk) 15:57, 15 November 2015 (UTC)Reply
Yeah, sorry, it should have been ImageDescription. Are you using the same CommonsMetadata version on both sites? Theoretically, en should just reuse the data it gets from pool without any processing. Or is pool a ForeignDBRepo? Tgr (WMF) (talk) 02:37, 28 November 2015 (UTC)Reply
@Tgr (WMF), yes, according to the API query result, all sites use CommonsMetadata 1.2.
The pool uses a different database (poolwiki) but the same database user and the LocalSettings.php of the language wikis look like this:
$wgUseSharedUploads = true;
$wgSharedUploadPath = 'https://pool.domain.com/w/images';
$wgSharedUploadDirectory = '/path/to/pool/w/images/';
$wgHashedSharedUploadDirectory = true;
$wgFetchCommonsDescriptions = true;
$wgSharedUploadDBname = 'poolwiki';
$wgRepositoryBaseUrl = "https://pool.domain.com/wiki/Image:";
Thanks and cheers! Till Kraemer (talk) 12:55, 8 December 2015 (UTC)Reply
What version of MediaWiki and CommonsMetadata are you using? Do you see the poolwiki file description page when you visit the page with the same name on en?
If you want to take a shot at debugging, the problem is probably within DataCollector::getDescriptionText(). Tgr (WMF) (talk) 07:09, 9 December 2015 (UTC)Reply
@Tgr (WMF), now I'm using MediaWiki 1.26.2, but I also had these problems with older versions. According to the API query result, I use CommonsMetadata 1.2. On Special:Version it shows just a dash ("–") in the version column. The contents of the version file in the extension directory are:
CommonsMetadata: REL1_26
2015-11-17T01:03:37
160f837
I don't see any text from the original file description page on en :( My debugging settings in LocalSettings.php look like this:
$wgDebugLogFile = "/path/to/mediawiki/debug-{$wgDBname}.log";&lt;/pre&gt;
I have no DataCollector entries in my log file :( Should I use [[Manual:Structured_logging|structured logging]] for this? Thanks and cheers! [[User:Till Kraemer|Till Kraemer]] ([[User talk:Till Kraemer|talk]]) 18:50, 16 January 2016 (UTC)
:That or something like xdebug. Although if you don't see description pages at all, this is probably not a CommonsMetadata-specific issue.
:Do you have fetchDescription enabled in your [https://www.mediawiki.org/wiki/Manual:$wgForeignFileRepos foreign repo configuration]? [[User:Tgr (WMF)|Tgr (WMF)]] ([[User talk:Tgr (WMF)|talk]]) 00:42, 17 January 2016 (UTC)
:{{FlowMention|Tgr (WMF)}}, thanks, fetchDescription is enabled in all language wikis (and I don't I have to do that for the pool, right?).  I installed MediaWiki 1.27.0 and the problem is still the same. I don't really get it. Shouldn't all local file description pages appear as captions even without fetchDescription enabled? If I understand it correctly, I shouldn't even need the CommonsMetadata extension for this to work. All I want from the pool is the file (which works). Now I just need the MultimediaViewer to get the file description from the local file description page of the language wikis. On the pool, everything works fine: I use the [https://commons.wikimedia.org/w/index.php?title=Template:Information&action=edit information template] and the values appear in the caption. On the language wikis, I also have the information template but the values don't appear in the caption, all I have is the file :( [[User:Till Kraemer|Till Kraemer]] ([[User talk:Till Kraemer|talk]]) 19:45, 2 July 2016 (UTC)
:P.S.: Okay, sorry, the CommonsMetadata extension seems to be necessary but I'm still not sure about fetchDescription. fetchDescription pulls the data from the pool description page, right? Not from the local file description page of the language wiki. [[User:Till Kraemer|Till Kraemer]] ([[User talk:Till Kraemer|talk]]) 15:54, 3 July 2016 (UTC)
:CommonsMetadata parses the description page to extract the image description (and author name, license etc), on both local and remote files. It is necessary for MediaViewer to show those things, but if your description page does not exist at all, your problem is at a lower level. The flow of information is like this (assuming all caches are cold):
:# MediaViewer calls the imageinfo API to get file metadata
:# the API calls CommonsMetadata via a hook
:# CommonsMetadata calls File::getDescriptionPageText
:# (assuming your file is a ForeignDBFile) getDescriptionPageText makes a HTTP request to the pool wiki's description page
:# the pool wiki parses its description page text, loads template definition etc, returns description page HTML
:# CommonsMetadata parses the HTML and extracts various DOM nodes
:If you do not have a ForeignDB repo configured, this will fail at step 3. Specifically, just setting $wgUseSharedUploads is not a reliable way to share images (although if you have all the required tables shared as well, it should work, via LocalFile::getDescriptionPageText which does completely different things to get the description). [[User:Tgr (WMF)|Tgr (WMF)]] ([[User talk:Tgr (WMF)|talk]]) 07:28, 4 July 2016 (UTC)
:{{FlowMention|Tgr (WMF)}}, thank you so much for all the information! I really appreciate your help!
:I took your suggestion and switched from $wgUseSharedUploads to $wgForeignFileRepos.
:Files work but I still no file descriptions show up:
:<syntaxhighlight lang='text'>$wgForeignFileRepos[] = array(
'class' => 'ForeignDBRepo',
'name' => 'pool',
'url' => "<nowiki>https://pool.domain.com/w/images</nowiki>",
'directory' => '/path/to/pool/images/',
'hashLevels' => 2, 
'dbType' => $wgDBtype,
'dbServer' => $wgDBserver,
'dbUser' => $wgDBuser,
'dbPassword' => $wgDBpassword,
'dbFlags' => DBO_DEFAULT,
'dbName' => 'poolwiki',
<nowiki>#</nowiki>   'tablePrefix' => 'mw_',
'hasSharedCache' => false,
'descBaseUrl' => '<nowiki>https://pool.domain.com/wiki/Image:'</nowiki>,
'fetchDescription' => true,
'descriptionCacheExpiry'  => 0,
'apiThumbCacheExpiry'     => 0,
);
I also tried to use ForeignAPIRepo since it worked perfectly a while ago but now it doesn't work at all (no files show up, let alone file descriptions):
$wgForeignFileRepos[] = array(
'class'                   => 'ForeignAPIRepo',
'name'                    => 'pool',
'apibase'                 => '<nowiki>https://pool.domain.com/w/api.php'</nowiki>,
'fetchDescription'        => true, 
'descriptionCacheExpiry'  => 43200,
'apiThumbCacheExpiry'     => 0, 
);
Out of curiosity, I also tried to pull data from Wikimedia. The following configuration doesn't work for me at all (no files, no file descriptions):
$wgForeignFileRepos[] = array(
'class'                   => 'ForeignAPIRepo',
'name'                    => 'commonswiki',
'apibase'                 => '<nowiki>https://commons.wikimedia.org/w/api.php'</nowiki>,
'hashLevels'              => 2,
'fetchDescription'        => true,
'descriptionCacheExpiry'  => 0,
'apiThumbCacheExpiry'     => 0,
);
However, this configuration here works perfectly (files and image descriptions show up oh so beautifully :)
$wgForeignFileRepos[] = array(
'class'                   => 'ForeignAPIRepo',
'name'                    => 'enwiki',
'apibase'                 => '<nowiki>https://en.wikipedia.org/w/api.php'</nowiki>,
'hashLevels'              => 2,
'fetchDescription'        => true,
'descriptionCacheExpiry'  => 0,
'apiThumbCacheExpiry'     => 0,
);
I so don't get it. The file is from Commons but someone I can't pull it directly from Commons but I can get it through the English Wikipedia? What the hell? It's so weird and I just want the MultimediaViewer so badly I could cry. Till Kraemer (talk) 17:06, 4 July 2016 (UTC)Reply
That's very weird. Check what's logged to the http channel while you are making a request to the file description page (you can use $wgDebugLogGroups to split it into its own file). Tgr (WMF) (talk) 19:13, 4 July 2016 (UTC)Reply
@Tgr (WMF), unfortunately, I didn't find any http related stuff in the log file :( On the cswiki, I visited the file description page, performed a null edit and viewed the file with MultimediaViewer. My whole logfile of the cswiki looks like this ("123..." values are changed by me):
Start command line script /path/to/cs/w/maintenance/runJobs.php
[caches] cluster: MemcachedPhpBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: MemcachedPhpBagOStuff, parser: MemcachedPhpBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[authentication] Overriding AuthManager primary authn because $wgAuth is CentralAuthPlugin
Unstubbing $wgParser on call of $wgParser::setHook from wfBlogger
Parser: using preprocessor: Preprocessor_DOM
Fully initialised
IP: 127.0.0.1
[connect] Connected to database 0 at ::1
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
[runJobs] refreshLinksPrioritized Soubor:Till_Kraemer.jpg rootJobTimestamp=12345678901234 useRecursiveLinksUpdate= triggeringUser={"userId":123,"userName":"Til
l Kraemer"} triggeringRevisionId=123 requestId=1234567890 (id=2,timestamp=12345678901234) STARTING
Revision::loadText: got id 123 from cache
[ContentHandler] Created handler for wikitext: WikitextContentHandler
Title::getRestrictionTypes: applicable restrictions to [[Soubor:Till Kraemer.jpg]] are {edit,move,upload}
[MessageCache] MessageCache::load: Loading cs... local cache is empty, got from global cache
Revision::loadText: got id 1234 from cache
Revision::loadText: got id 12345 from cache
[Preprocessor] Loaded preprocessor output from cache (key: cswiki:preprocess-xml:1234567890:1)
Unstubbing $wgLang on call of $wgLang::unstub from Wikibase\Client\Hooks\ParserLimitHookHandlers::newFromGlobalState
MWCryptRand::realGenerate: Generating cryptographic random bytes for MediaWiki\Session\SessionManager->generateSessionId/MWCryptRand::generateHex/MWCryptRand
->realGenerateHex/MWCryptRand::generate/MWCryptRand->realGenerate
MWCryptRand::realGenerate: mcrypt_create_iv generated 20 bytes of randomness.
MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer.
[session] SessionBackend "123456789012345" is unsaved, marking dirty in constructor
[session] SessionBackend "123456789012345" save: dataDirty=1 metaDirty=1 forcePersist=0
[MessageCache] MessageCache::load: Loading en... local cache is empty, got from global cache
LoadBalancer::openForeignConnection: opened new connection for 0/datawiki
LoadBalancer::reuseConnection: freed connection 0/datawiki
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
I can't detect any problematic things in the logfile. I really don't get why values like the complete file history are fetched but not the file description. Should I install Xdebug?
Thanks and cheers! Till Kraemer (talk) 23:05, 5 July 2016 (UTC)Reply
I installed the server's OS on a local computer, downloaded the MediaWiki files from the server and imported all databases. The result: no file descriptions from the pool. However, when I deactivated the CentralAuth extension, I was able to fetch file descriptions from the pool. Isn't that weird?
Thanks and cheers! Till Kraemer (talk) 16:16, 15 September 2016 (UTC)Reply
@Tgr (WMF), sorry, looks like it wasn't CentralAuth. On the local installation it seems to have something to do with the chroot jail in which php_fpm runs, because when I copy /etc/hosts into the jail, file descriptions are fetched from the pool. But I can't reproduce this behavior on the server. I'll keep digging. Till Kraemer (talk) 18:10, 17 September 2016 (UTC)Reply
The log file looks like this:
Without hosts file in chroot jail:
Fetching shared description from <nowiki>http://pool.localdomain.com/w/index.php?title=File:Till_Kraemer.jpg&amp;amp;action=render&amp;amp;uselang=de</nowiki>
HTTP: GET: <nowiki>http://pool.localdomain.com/w/index.php?title=File:Till_Kraemer.jpg&amp;amp;action=render&amp;amp;uselang=de</nowiki>
[http] PhpHttpRequest: error opening connection: {errstr1}
[MessageCache] MessageCache::load: Loading en... local cache is empty, got from global cache
LocalisationCache::isExpired(en): cache for en expired due to GlobalDependency
LocalisationCache::recache: got localisation for en from source
[http] HTTP request failed due to unknown error.
With hosts file in chroot jail:
Fetching shared description from <nowiki>http://pool.localdomain.com/w/index.php?title=File:Till_Kraemer.jpg&amp;amp;action=render&amp;amp;uselang=de</nowiki>
HTTP: GET: <nowiki>http://pool.localdomain.com/w/index.php?title=File:Till_Kraemer.jpg&amp;amp;action=render&amp;amp;uselang=de</nowiki>
[MessageCache] MessageCache::load: Loading en... local cache is empty, got from global cache
Article::view using parser cache: yes
Parser cache options found.
ParserOutput cache found.
Article::view: showing parser cache contents
[queries] dewiki: SELECT /* WatchedItemStore::loadWatchedItem Till Kraemer */  wl_notificationtimestamp  FROM `watchlist`   WHERE wl_user = '1' AND wl_namespace = '6' AND wl_title = 'Till_Kraemer.jpg'  LIMIT 1
LoadBalancer::reuseConnection: this connection was not opened as a foreign connection
File::transform: Doing stat for mwstore://pool-backend/pool-thumb/e/e7/Till_Kraemer.jpg/120px-Till_Kraemer.jpg
FileBackendStore::getFileStat: File mwstore://pool-backend/pool-thumb/e/e7/Till_Kraemer.jpg/120px-Till_Kraemer.jpg does not exist.
TransformationalImageHandler::doTransform: creating 120x80 thumbnail at /tmp//transform_1234567.jpg using scaler client
[queries] dewiki: SELECT /* LocalRepo::findBySha1 Till Kraemer */  img_name,img_size,img_width,img_height,img_metadata,img_bits,img_media_type,img_major_mime,img_minor_mime,img_description,img_user,img_user_text,img_timestamp,img_sha1  FROM `image`   WHERE img_sha1 = '123456789'  ORDER BY img_name
[queries] dewiki: SELECT /* Title::getRedirectsHere Till Kraemer */  page_namespace,page_title  FROM `redirect`,`page`   WHERE rd_namespace = '6' AND rd_title = 'Till_Kraemer.jpg' AND (rd_from = page_id) AND (rd_interwiki = <nowiki>''</nowiki> OR rd_interwiki IS NULL) AND page_namespace = '6'
[queries] dewiki: SELECT /* ImagePage::queryImageLinks Till Kraemer */  page_namespace,page_title,il_to  FROM `imagelinks`,`page`   WHERE il_to = 'Till_Kraemer.jpg' AND (il_from = page_id)  ORDER BY il_from LIMIT 102
[queries] dewiki: SELECT /* GenderCache::doQuery/MediaWikiTitleCodec::getNamespaceName Till Kraemer */  user_name,up_value  FROM `user` LEFT JOIN `user_properties` ON ((user_id = up_user) AND up_property = 'gender')  WHERE user_name = 'Till Kraemer'
MediaWiki::preOutputCommit: all transactions committed
MediaWiki::preOutputCommit: pre-send deferred updates completed
Till Kraemer (talk) 18:30, 17 September 2016 (UTC)Reply
Well, [http] PhpHttpRequest: error opening connection: {errstr1} suggests there is a network issue. No idea why the error message is missing. Can you dump PhpHttpRequest::$fopenErrors in PhpHttpRequest::execute(), just after if ( $this->fopenErrors ) {? Tgr (WMF) (talk) 21:48, 17 September 2016 (UTC)Reply
@Tgr (WMF), thanks for your help! You mean changing HttpFunctions.php like this, right?
if ( $this->fopenErrors ) {
PhpHttpRequest::$fopenErrors
LoggerFactory::getInstance( 'http' )->warning( __CLASS__
. ': error opening connection: {errstr1}', $this->fopenErrors );
}
...but wait a minute, I somehow got an error message now (without changing HttpFunctions.php):
Fetching shared description from http://pool.localdomain.com/wiki/File:Till_Kraemer.jpg?action=render&amp;uselang=de
HTTP: GET: http://pool.localdomain.com/wiki/File:Till_Kraemer.jpg?action=render&amp;uselang=de
[MessageCache] MessageCache::load: Loading en... local cache is empty, got from global cache
LocalisationCache::isExpired(en): cache for en expired due to GlobalDependency
LocalisationCache::recache: got localisation for en from source
[http] Error fetching URL: Couldn&amp;#39;t resolve host &amp;#39;pool.localdomain.com&amp;#39;
But shouldn't it just connect to the database since I'm using ForeignDBRepo? ForeignAPIRepo doesn't work for me. And if I want to make database connections, I have to use 127.0.0.1 as the database server, everything else fails.
Is it somehow possible to fetch the file descriptions via 127.0.0.1 instead of connecting to pool.localdomain.com? Till Kraemer (talk) 10:05, 18 September 2016 (UTC)Reply
It's definitely the chroot jail! As soon as I run php_fpm without chroot, everything works perfectly and file descriptions are fetched from the pool. So the problem has nothing to do with MediaWiki.
I'm gonna find out what options I have to get DNS going inside the chroot. Linux users seem to be able to use nscd for DNS caching; on OpenBSD maybe I can use unbound for that.
Anyway, sorry for all the noise I made and thanks again for your help @Tgr (WMF)! Till Kraemer (talk) 14:53, 18 September 2016 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Extension does not work, although installed

[edit]

Hello,

the extension does not work on our MediaWiki (1.26). On the Special:Version it shows that the Extension is installed and running. But if I click on an image, MultimediaViewer does not show up!

Webserver: IIS 7

PHP: 5.4.45

Do I need a newer PHP version? FlugSnug (talk) 06:25, 9 March 2016 (UTC)Reply

Okay, Problem was my cache directory was not writable... Sorry for the inconvenience. FlugSnug (talk) 08:38, 9 March 2016 (UTC)Reply

[Solved]Not enabled by default

[edit]

I recently upgraded to MediaWiki 1.27.0-wmf.17, and now Media Viewer is not enabled by default for registered users.

It works with anonymous users, and I have enabled $wgMediaViewerEnableByDefault

Is this a bug or am I missing something?

Thanks. John Cena 12321 (talk) 22:41, 21 March 2016 (UTC)Reply

Probably a bug. Tgr (WMF) (talk) 23:20, 21 March 2016 (UTC)Reply
It's because return (bool)$user->getOption( 'multimediaviewer-enable' ); UksusoFF (talk) 14:51, 19 July 2016 (UTC)Reply
So how to fix this error? Deletedaccount4567435 (talk) 04:34, 18 October 2016 (UTC)Reply
All right, I know how to fix it now.
Add $wgDefaultUserOptions['multimediaviewer-enable'] = 1; to Localsettings.php for temporary fix. and I submit a bug report to phabricator. Hope it fix soon. Deletedaccount4567435 (talk) 04:38, 18 October 2016 (UTC)Reply
Thanks, this solved my issue for MW 1.27 Soumya.sadanandan (talk) 03:39, 16 March 2017 (UTC)Reply

Force it on inline images?

[edit]

How can I force it for inline images? It only seems to work for thumbs and floating images. Here it doesn't work:

Subfader (talk) 10:49, 8 May 2016 (UTC)Reply

Hide progess bar?

[edit]

How can I hide the blue progress bar on opening a new lightbox?

It's flashing. Flashing is bad. #uxMatters Subfader (talk) 22:26, 8 May 2016 (UTC)Reply

What do you mean by flashing? Tgr (WMF) (talk) 15:22, 9 May 2016 (UTC)Reply
It appears after the page is rendered and disappears again after a few milli seconds. That's annoying. Subfader (talk) 09:32, 16 May 2016 (UTC)Reply
That sounds wrong. Could you file a bug with specifics (which page/file, did you view other files on the page before viewing)?
In any case you can hide it with .mw-mmv-progress { display: none; } Tgr (WMF) (talk) 10:25, 16 May 2016 (UTC)Reply

Does MultimediaViewer work on private wiki?

[edit]

Could we using MultimediaViewer on a private wiki?

I looks like the viewer could not access uploaded files if we set up img_auth.php by following this manual. Manual:Preventing access#Restrict access to uploaded files.

Even user logged in, the viewer still could not view those files. Seanchen (talk) 18:35, 20 May 2016 (UTC)Reply

It should work fine, If it doesn't, please file a bug with the details. Tgr (WMF) (talk) 19:40, 20 May 2016 (UTC)Reply
@Tgr thanks for the quick reply!
Here are some more details about this issue, could you help take a look to see if you have any clue.
I am working on the MediaWiki version 1.26.2 and download MultimediaViewer at version 0.3.0.
I did set up the img_auth.php to protect the access to media files. As long as user logged in, user could view the media file without problem. For example: http://dev.example.com/wiki/img_auth.php/6/69/Denmark.png. But when logged in user try to view the same image on MultimediaViewer, we got this massage:
There seems to be a technical issue. You can retry or report the issue if it persists. Error: could not load image from http://dev.example.com/wiki/img_auth.php/6/69/Denmark.png
And I could see failed to load resource error on Chrome console:
Failed to load resource: the server responded with a status of 403 (Forbidden)
It might have something to do with my Ngnix's configuration. I will double check...
Is there any configuration on MultimediaViewer related to this?
If you still think it is a issue, I will file a bug for it.
thanks a lot,
Sean Seanchen (talk) 14:03, 24 May 2016 (UTC)Reply
Disabling $wgMediaViewerUseThumbnailGuessing might help, but it should not be necessary, and it's the default anyway.
Might be a problem with how MediaViewer uses CORS. Could you try to edit resources/mmv/provider/mmv.provider.Image.js to change imagePreloadingSupported to always return false, and see if that fixes it? Tgr (WMF) (talk) 14:52, 24 May 2016 (UTC)Reply
I had the same issue as @Seanchen, and set to false as follows (which solved the problem):
if ( !this.cache[ cacheKey ] ) {
if ( this.imagePreloadingSupported() ) {
rawGet = provider.rawGet.bind( provider, url, false );
this.cache[ cacheKey ] = this.performance.record( 'image', url, extraStatsDeferred ).then( rawGet, rawGet );
} else {
start = ( new Date() ).getTime();
this.cache[ cacheKey ] = this.rawGet( url );
this.cache[ cacheKey ].always( function () {
provider.performance.recordEntry( 'image', ( new Date() ).getTime() - start, url, undefined, extraStatsDeferred );
} ); Nelmonk (talk) 15:33, 20 June 2020 (UTC)Reply
I needed to use this workaround on my v1.39.1 setup with AWS and s3 and proxying through cloudflare. CORS headers are set up in s3 and returned in most cases but in a few rare cases they weren't causing the "Technical issue" error mainly in Chrome. Tiggleshorts (talk) 21:02, 8 February 2023 (UTC)Reply
disabling $wgMediaViewerUseThumbnailGuessing does help.
set imagePreloadingSupported to false fixed it!
Also I did test on Firefox. Everything is working on Firefox without any code change.
it seems like Chrome and Firefox handle CORS slightly different!
let me know if you want me file a bug for this.
thanks,
Sean Seanchen (talk) 15:57, 24 May 2016 (UTC)Reply
Thanks. Had the same problem. Incorrect CORS error on working 404 handler (images are on subdomain).
Returning imagePreloadingSupported false fixed it. $wgMediaViewerUseThumbnailGuessing could stay true.
MW 1.25 --Subfader (talk) 11:39, 4 November 2017 (UTC)Reply
Please do. The bug would probably affect Firefox too, if your images were on a separate domain. MV sets cors="anonymous" on the images for various hacky reasons, for private wikis that should probably be cors="use-credentials" instead. Tgr (WMF) (talk) 19:51, 24 May 2016 (UTC)Reply
Create ticket here: https://phabricator.wikimedia.org/T136207 Seanchen (talk) 15:37, 25 May 2016 (UTC)Reply
This is still a relevant help for the latest LTS-MediaWiki (1.31.2).
Thanks for this workaround. Setting <pre>imagePreloadungSupported</pre> to <pre>false</pre> helped a lot and fixed my problem. 80.128.155.247 (talk) 11:43, 15 July 2019 (UTC)Reply
Hi there,
Yes it also fixed my problem (MediaWiki-1.34.1). Thanks for that! Jesperjoachims (talk) 16:20, 15 July 2020 (UTC)Reply
The workaround is nice, but it would be best to add an option to send an XHR object without withCredentials. I've added my thoughts on https://phabricator.wikimedia.org/T64469 Jeffrey Wang 20:49, 27 April 2021 (UTC)Reply
This is for the newer version of MultilmediaViewer in 1.40, as the above code suggestions no longer work due to the recode:
1. Go to line 65 of extensions/MultimediaViewer/resources/mmv/provider/mmv.provider.Image.js
2. Change line to remove the preload call in function, so that it reads:
this.cache[ cacheKey ] = this.rawGet( url ); Joe Beaudoin Jr. Redux (talk) 06:46, 24 September 2023 (UTC)Reply
Update: This is still an issue in 1.41. Joe Beaudoin Jr. Redux (talk) 20:17, 26 August 2024 (UTC)Reply
I can confirm this error persists in 1.41.
Firefox works fine, but Chrome complains about it.
Example:
https://en.prolewiki.org/wiki/Shanghai#/media/File:Shanghai_Skyview.jpeg Marx.FelipeForte (talk) 23:15, 14 September 2024 (UTC)Reply
This is still an issue... please see my latest workaround here: Extension talk:MultimediaViewer Joe Beaudoin Jr. Redux (talk) 00:57, 3 March 2025 (UTC)Reply

MultimediaViewer for MediaWiki 1.22

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Hello! I have mediawiki 1.23 and would like to know if it possible to have this extension for such Mediawiki version, unfortunately I cannot upgrade my wiki. Or are there alike extension that shows images according to screen resolution? Thank you Fokebox (talk) 14:56, 27 June 2016 (UTC)Reply

Yes, it is possible. I have it running on one of my wikis. Just go to the Extension Distributor and select the version for the MW 1.23 branch. Note however that a lot of work has been put into the extension, so do not expect the same behaviour as well as look and feel as you see it e.g. on wikis like Wikipedia etc. [[kgh]] (talk) 16:27, 27 June 2016 (UTC)Reply
Thank you for a reply! I did install the extension and afterwards I have a message when site is opened:
Fatal error: Call to undefined method ThumbnailImage::getFile() in /var/www/admin/www/mywikisite.ru/extensions/MultimediaViewer/MultimediaViewerHooks.php on line 258
How can I fix it and avoid the error Fokebox (talk) 06:02, 28 June 2016 (UTC)Reply
I am sorry but I have to pass on this one. For me the version for MW 1.23 works. In case you did not accidentally pick the wrong download ... [[kgh]] (talk) 09:02, 28 June 2016 (UTC)Reply
What is exact version of your wiki? Now I have 1.22.13 Fokebox (talk) 09:13, 28 June 2016 (UTC)Reply
The wiki is also on MW 1.23.13. This extensions version is labelled version 0.3 but this still could be anything. [[kgh]] (talk) 11:53, 28 June 2016 (UTC)Reply
I have defenately downloaded the version for 1.23. And has version 0.3.0
You wiki has 1.23.12 but mine is 1.22.13 )
Anyway I have this error if the article has some images in it. Probably the extension doesn't really support MediaWiki with version less than 1.23 Fokebox (talk) 14:03, 28 June 2016 (UTC)Reply
Ah now I see the issue. In your very first post you stated that you are running MW 1.23. Never mind. As a matter of fact this extension was created when MW 1.22 was around. For some reason the Extension distributor does not offer the download for MW 1.22 but there is a mirror at GitHub what allows to download the version for that branch. So just use this link. Keeping fingers crossed that it will work now. [[kgh]] (talk) 22:11, 28 June 2016 (UTC)Reply
Thank you for reply. Tried to install the extension and have such error displayed:
Fatal error: Class 'BetaFeatures' not found in /var/www/admin/www/mywikisite.ru/extensions/MultimediaViewer/MultimediaViewerHooks.php on line 29
P.S. Pardon the title was really wrong. Now it is ok Fokebox (talk) 06:12, 29 June 2016 (UTC)Reply
It looks like that this extension was dependant on the BetaFeatures extension at that time. So you would like to install the version for MW 1.22 of that extension too. [[kgh]] (talk) 07:32, 29 June 2016 (UTC)Reply
Thank you! I try, but betafeatures also requres MW >1.23 ))) Anyway I think to have FancyBox extension that works almost equaly in comparison with MediaViewer Fokebox (talk) 07:49, 29 June 2016 (UTC)Reply
The extension pages document only the version on master. In most cases earlier versions are supported too but you will have to dig for them. That's BetaFeatures for MW 1.22.
As a sidenote: You should upgrade your wiki. MW 1.22 is no longer supported and will probably stop working sooner or later anyway. [[kgh]] (talk) 09:09, 29 June 2016 (UTC)Reply
Well, I tried but there are still errors ( anyway I will update my wiki or will use other extension like FancyBox ) Thank you for help Fokebox (talk) 09:43, 29 June 2016 (UTC)Reply
Sorry that it does not work out. Worth a try though... [[kgh]] (talk) 11:38, 29 June 2016 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Closing the Viewer makes the page go black

[edit]

Whenever I click on an image, the MultimediaViewer pops up just fine. I can switch between images in a page, there's all the stuff, everything's fine. However, when I click the X to close out of the viewer, the page goes black. Tried in Firefox and Chrome, both as logged in and logged out user, and it still went black.

Test it out here

What could be causing this? 71.15.112.25 (talk) 06:01, 1 July 2016 (UTC)Reply

Probably a version mismatch between MultimediaViewer and OOUI. You should use the same branch for MediaWiki core and extensions. Tgr (WMF) (talk) 10:37, 1 July 2016 (UTC)Reply
Um, what exactly do you mean by that? I mean, could you tell me how I would go about doing that? I'm not at all versed in the lingo you're using.
Thank you in advance 71.15.112.25 (talk) 17:17, 1 July 2016 (UTC)Reply
Ask the operator of the wiki to use matching versions of MediaWiki core and extensions. They are not guaranteed to work otherwise. Tgr (WMF) (talk) 18:16, 1 July 2016 (UTC)Reply
Hi
My Media wiki version is 1.25 and there is no equ version of Multimediaviewer. I just try using the other version but for each case i have the same problem. Black screen on closure.
Any fixes or any 1.25 compatible version or any clues?
Thanks 217.108.75.1 (talk) 08:07, 24 August 2016 (UTC)Reply
Ok i found out the problem.
Then the matching version is the 1.26 (as i expected).
Use the require_once include line to plug the extention like the doc says (even if with version 1.26 wfLoadExtension is inplemented with MW its not with MV)
And ... that's all it's working fine. 217.108.75.1 (talk) 09:15, 24 August 2016 (UTC)Reply

Some MultimediaViewer bug at MW 1.27.0

[edit]

Hello all. I have updated my wiki from 1.22.13 to 1.27 and installed MultimediaViwer. I have noticed the following If the page is opened using "www" in URL - all images are opened in mediaviewer with error saying that the Image cannot be opened. If the same page is opened without "www" in URL - all images are opened fine without any errors Is possible to fix it somehow? Fokebox (talk) 14:37, 4 July 2016 (UTC)Reply

Please check what HTTP requests are made and how they deviate from the actual thumbnail URLs. Tgr (WMF) (talk) 19:14, 4 July 2016 (UTC)Reply
I don't really understand what and how to check all this?
And actually this problem can be solved using .htaccess where I can set to open all pages without "www" Fokebox (talk) 06:45, 5 July 2016 (UTC)Reply
Using some browser's developer console is the easiest way, e.g. [1]. Tgr (WMF) (talk) 10:42, 5 July 2016 (UTC)Reply

Expand to full screen collapses scaled MMV image back to thumb size (MW REL 1.26)

[edit]

Hi,

I'm using MMV release of Mediawiki 1.26. It works fine so far except on images if the original file size is not as large as to fill the full screen image. Steps I tested

  1. clicking on a small thumbnail image scales it up via MMV. OK so far.
  2. changing MMV to full screen mode causes the MMV-scaled-image to flip back to the smaller thumb size of its thumb version embedded in the wiki page

I would expect that the image size stays at least that size when switching to full screen mode.

Is there anything I can correct it? Any configuration variables that cover this?

Thank you Regards, Andreas Andreas P. 12:05, 2 September 2016 (UTC)Reply

I can't immediately think of anything that would cause this. Is your wiki public? Tgr (WMF) (talk) 23:30, 2 September 2016 (UTC)Reply
Yes: http://offene-naturfuehrer.de/web/Benutzer:Andreas_Plank/Bilder_Test the first one File:Pheteroneura-wing.PNG (tested on my laptop (1366 × 768) FireFox 46.0) pops back to thumb when switching to full screen mode. Andreas P. 09:16, 3 September 2016 (UTC)Reply
I also noticed, that on the repository wiki, the image is stored in, it works as expected and does not flip back, it maximizes even the size. Also when using an image from commons it works as expected. But on (child) wikis that read from our image repository, the images do flip to the smaller thumb size. Our media repository is configured via ForeignDBViaLBRepo. Can it have an effect on which url is being loaded? At the moment it is
$wgForeignFileRepos[] = array(
'class' => 'ForeignDBViaLBRepo',
'wiki' => 'openmedia',
'name' => 'openmedia',
'directory' => '/var/www/v-species/o/media',
'url' => 'https://species-id.net/o/media',
'thumbUrl' => 'https://species-id.net/o/media/thumb',
'thumbScriptUrl' => 'https://species-id.net/o/thumb.php',
'scriptDirUrl' => 'https://species-id.net/o',
'hashLevels' => 2,
'fetchDescription' => true,
);
Any ideas on that? Andreas P. 21:35, 5 September 2016 (UTC)Reply
You have enabled $wgMediaViewerUseThumbnailGuessing (or rather, it was probably still on by default in 1.26) which does not work correctly if you are not using a 404 handler for thumbnails. Tgr (WMF) (talk) 22:40, 5 September 2016 (UTC)Reply
With $wgMediaViewerUseThumbnailGuessing=false; it is working as expected. Thank you :-) Andreas P. 09:28, 6 September 2016 (UTC)Reply

Blacklist

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Hi, is it possible to add images to a blacklist so that they don't show up in the MultimediaViewer when I click through a gallery? For PageImages I can use MediaWiki:Pageimages-blacklist; would be cool if something like that is possible with MultimediaViewer too. Thanks and cheers! Till Kraemer (talk) 13:26, 19 September 2016 (UTC)Reply

Not possible currently; you can use [[File:Foo.png|class=noviewer]] or <div class="noviewer">(...)[[File:Foo.png]](...)</div>in the wikitext, but I don't think either of those can be done for a part of a gallery. Tgr (WMF) (talk) 22:59, 19 September 2016 (UTC)Reply
@Tgr (WMF), that's even better for me because I just have to add class=noviewer to a template (the images I don't want to appear in the MultimediaViewer are little zodiac sign icons in an infobox). In normal galleries everything is perfect the way it is. Thanks a lot for your help! Cheers! Till Kraemer (talk) 13:07, 20 September 2016 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Not working on thumbnails

[edit]

I can't get the viewer to open on images on pages. Whenever clicking on a image it takes me to there image page, from there I can click a button under the image to open the viewer. It's clearly activated but as said above it does not open images directly on pages. 62.119.183.61 (talk) 04:02, 26 September 2016 (UTC)Reply

Ceck for javascript errors. Tgr (WMF) (talk) 17:20, 27 September 2016 (UTC)Reply
Same problem. No apparent Javascript errors on F12 when loading the page..
Example page http://granblue.iiwebi.me/wiki/Category:Weapons on http://granblue.iiwebi.me/wiki/Special:Version Toriayl (talk) 12:13, 4 October 2016 (UTC)Reply
@Toriayl works fine for me. Can you give exact reproduction steps? Tgr (WMF) (talk) 21:54, 4 October 2016 (UTC)Reply
@Tgr (WMF) Does it open a thumbnail when you click on the image on the first page I linked?! It's never worked for me, same issue as the original poster's; clicking on an image brings me to image page instead of the lightbox effect; once on the image page, clicking on Open in Media Viewer opens up fine.
I'm using Chrome Version 53.0.2785.116 m and have the same issue on Microsoft Edge 38.14393.0.0.
I have asked a few other people and gotten the below results:
Chrome: Not working
Chrome: Not working
Firefox and Chrome: Working
So I guess it's too hard to reproduce... not sure when it would work. D: Toriayl (talk) 09:50, 6 October 2016 (UTC)Reply
You might miss the errors because the browser console is cleared when the browser navigates to the new page. There is usually an option to persist error messages which avoids that. Tgr (WMF) (talk) 16:47, 6 October 2016 (UTC)Reply

Display summary of image

[edit]

Hello,

I installed this very nice extension and also CommonsMetadata.

Problem is I want to display under the image the contents of the summary field. Right now it displays the file name.

Can you please explain like for dummies how can I change this?

Thank you very much,

Cristian 86.124.80.209 (talk) 20:00, 11 October 2016 (UTC)Reply

The fallback chain for the main text is image caption -> file description page summary -> file name. If both caption and summary exist, the summary will be displayed below the main text.
If you see the file name, either CommonsMetadata is not working or it does not recognize the template. Test the API directly. Tgr (WMF) (talk) 00:35, 12 October 2016 (UTC)Reply
Hello,
Thank you for your feedback! Indeed if I disable CommonsMetadata I get the same result.
Now I begin to understand a little bit (at least I hope). CommonsMetadata is designed to parse information on media files using the template which is used in Wikimedia Commons.
The problem I have my wiki is a simple, basic installation and the image files I uploaded have a simple text in the summary field.
I have no clue how to make a template for that, where the templates are installed (?) or what it means to test the API directly.
Thank you very much,
Cristian 86.124.80.209 (talk) 12:48, 13 October 2016 (UTC)Reply
Aha
Somehow I understood (hopefully) how to test the API directly. This is what I get for an image
{
"batchcomplete": "",
"query": {
"normalized": [
{
"from": "File:MICRO_FEINMECHANIK_00078_3_ebay_silvanadebego.JPG",
"to": "File:MICRO FEINMECHANIK 00078 3 ebay silvanadebego.JPG"
}
],
"pages": {
"410": {
"pageid": 410,
"ns": 6,
"title": "File:MICRO FEINMECHANIK 00078 3 ebay silvanadebego.JPG",
"imagerepository": "local",
"imageinfo": [
{
"timestamp": "2016-10-02T12:40:43Z",
"user": "Cristian.buru@gmail.com"
}
]
}
}
}
}
Still, no trace of the summary field information... 86.124.80.209 (talk) 14:28, 13 October 2016 (UTC)Reply
You can use something like https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=imageinfo&titles=File%3AMICRO_FEINMECHANIK_00078_3_ebay_silvanadebego.JPG&iiprop=extmetadata for testing. I made an example template here: Extension:CommonsMetadata/info template for 3rd-party wikis (not tested). Tgr (WMF) (talk) 19:47, 13 October 2016 (UTC)Reply
Hello,
Yes it worked! Thank you very much for your help! In the end I simplified to something like this:
| style="background-color:#FFC000;font-size:11pt;font-weight:bold;width: 10%" align="right" id="fileinfotpl_desc" class="fileinfo-paramfield" |DESCRIPTION
| class="description" |
|- style="vertical-align: top"
| style="background-color:#FFC000;font-size:11pt;font-weight:bold;width: 10%" align="right" id="fileinfotpl_src" class="fileinfo-paramfield" |SOURCE
|
|- style="vertical-align: top"
| style="background-color:#FFC000;font-size:11pt;font-weight:bold;width: 10%" align="right" id="fileinfotpl_aut" class="fileinfo-paramfield" |AUTHOR
|
|} 86.124.80.209 (talk) 22:41, 13 October 2016 (UTC)Reply

How to hide the bottom white bar?

[edit]

The bar contain title, uploader, more detail button, and copyright foot notice are not needed in my wiki. I'd like it only show the photo. How can I archive this goal?

I knew FancyBoxThumbs extension have exactly the GUI I want, but that extension only load the original file which create unacceptable huge amount of bandwidth cost. Deletedaccount4567435 (talk) 14:13, 18 November 2016 (UTC)Reply

img tags and multimediaviewer

[edit]

Forgive me if the question is noob but I don't understand how to make mediaviewer with a widget+script (that changes image based on select), since you can't use image markup, I'm wondering if it's possible at all... . 118.212.156.250 (talk) 17:46, 24 May 2017 (UTC)Reply

using attr seems to change a preexisting image, but still displays the link and preview of the older image dispite the href tag already change in <a class=image> 106.4.161.98 (talk) 10:29, 25 May 2017 (UTC)Reply

Clicking an image makes the screen go black

[edit]

Using Media Wiki 1.28.1 and MultimediaViewer ver (b426dc3) .

I'm using an internal WAMP server. Mutlimedia viewer is enabled in Preferences.

When I click on a image the screen simply goes completely black.

There are no javascript errors. I've tried changing the value of $wgMediaViewerUseThumbnailGuessing to both true and false and it made no difference.

Is this a known issue? What are some things I could check? Smason3346 (talk) 20:59, 15 June 2017 (UTC)Reply

Clicking on the X button leads to a black page.

[edit]

Just installed MultimediaViewer: it works great but if I click on X button, if I press Esc or even if I go back one page, the browser just shows an empty black page.

I fired up Chrome's Developer tool and I get the Console error reported below. I should mention I am using MediaWiki 1.26 and I tried the snapshot for both 1.27 and 1.30, as there isn't one specific for 1.26.

I also tried the require_once() loading modus rather than using wfLoadExtension() but it doesn't seem to make a difference.

I'm not into php enough to understand what's going on. Is there an incompatibility with the SimpleTooltip extension?

-----

Uncaught Error: Invalid callback. Function or method name expected.

    at validateMethod (load.php?debug=false&lang=en&modules=ext.SimpleTooltip|ext.echo.init|ext.uls.pt|jquery.byteLength%2CcheckboxShiftClick%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions|mediawiki.Title%2CsearchSuggest|mediawiki.action.view.postEdit|mediawiki.api.watch|mediawiki.page.ready|mediawiki.page.watch.ajax|mediawiki.ui.button%2Cicon|mmv.bootstrap|mmv.bootstrap.autostart|oojs%2Csite&skin=vector&version=b3e6ba0b8e8f:118)

    at CanvasButtons.oo.EventEmitter.off (load.php?debug=false&lang=en&modules=ext.SimpleTooltip|ext.echo.init|ext.uls.pt|jquery.byteLength%2CcheckboxShiftClick%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions|mediawiki.Title%2CsearchSuggest|mediawiki.action.view.postEdit|mediawiki.api.watch|mediawiki.page.ready|mediawiki.page.watch.ajax|mediawiki.ui.button%2Cicon|mmv.bootstrap|mmv.bootstrap.autostart|oojs%2Csite&skin=vector&version=b3e6ba0b8e8f:119)

    at CanvasButtons.oo.EventEmitter.disconnect (load.php?debug=false&lang=en&modules=ext.SimpleTooltip|ext.echo.init|ext.uls.pt|jquery.byteLength%2CcheckboxShiftClick%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions|mediawiki.Title%2CsearchSuggest|mediawiki.action.view.postEdit|mediawiki.api.watch|mediawiki.page.ready|mediawiki.page.watch.ajax|mediawiki.ui.button%2Cicon|mmv.bootstrap|mmv.bootstrap.autostart|oojs%2Csite&skin=vector&version=b3e6ba0b8e8f:120)

    at LightboxInterface.LIP.unattach (load.php?debug=false&lang=en&modules=jquery.color%2CcolorUtil%2Cfullscreen%2Chidpi|mmv&skin=vector&version=9d0baaccfde7:99)

    at HTMLDivElement.<anonymous> (load.php?debug=false&lang=en&modules=jquery.color%2CcolorUtil%2Cfullscreen%2Chidpi|mmv&skin=vector&version=9d0baaccfde7:99)

    at HTMLDivElement.dispatch (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=BNnJutks:65)

    at HTMLDivElement.elemData.handle (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=BNnJutks:60)

validateMethod @ load.php?debug=false&lang=en&modules=ext.SimpleTooltip|ext.echo.init|ext.uls.pt|jquery.byteLength%2CcheckboxShiftClick%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions|mediawiki.Title%2CsearchSuggest|mediawiki.action.view.postEdit|mediawiki.api.watch|mediawiki.page.ready|mediawiki.page.watch.ajax|mediawiki.ui.button%2Cicon|mmv.bootstrap|mmv.bootstrap.autostart|oojs%2Csite&skin=vector&version=b3e6ba0b8e8f:118

oo.EventEmitter.off @ load.php?debug=false&lang=en&modules=ext.SimpleTooltip|ext.echo.init|ext.uls.pt|jquery.byteLength%2CcheckboxShiftClick%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions|mediawiki.Title%2CsearchSuggest|mediawiki.action.view.postEdit|mediawiki.api.watch|mediawiki.page.ready|mediawiki.page.watch.ajax|mediawiki.ui.button%2Cicon|mmv.bootstrap|mmv.bootstrap.autostart|oojs%2Csite&skin=vector&version=b3e6ba0b8e8f:119

oo.EventEmitter.disconnect @ load.php?debug=false&lang=en&modules=ext.SimpleTooltip|ext.echo.init|ext.uls.pt|jquery.byteLength%2CcheckboxShiftClick%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions|mediawiki.Title%2CsearchSuggest|mediawiki.action.view.postEdit|mediawiki.api.watch|mediawiki.page.ready|mediawiki.page.watch.ajax|mediawiki.ui.button%2Cicon|mmv.bootstrap|mmv.bootstrap.autostart|oojs%2Csite&skin=vector&version=b3e6ba0b8e8f:120

LIP.unattach @ load.php?debug=false&lang=en&modules=jquery.color%2CcolorUtil%2Cfullscreen%2Chidpi|mmv&skin=vector&version=9d0baaccfde7:99

(anonymous) @ load.php?debug=false&lang=en&modules=jquery.color%2CcolorUtil%2Cfullscreen%2Chidpi|mmv&skin=vector&version=9d0baaccfde7:99

dispatch @ load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=BNnJutks:65

elemData.handle @ load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=BNnJutks:60 2A02:1203:ECB7:D2C0:3DA6:7EE5:29C5:591F (talk) 21:57, 10 June 2018 (UTC)Reply

By the way, I'm the author of this entry, I just couldn't login earlier. manu3d (talk) 22:02, 10 June 2018 (UTC)Reply
Appending ?debug=true to the URL (or &debug=true if there’s already a ? in it) is always good for debugging. (You need to place it right before the # sign if there is one.) It makes URLs simpler and line numbers easier to find. Tacsipacsi (talk) 08:01, 12 June 2018 (UTC)Reply

How is the description in MediaViewer extracted from file descriptions?

[edit]

Compare the descriptions of File:Skulptur_Hand_und_Traube_548_bei_A-2170_Wetzelsdorf.jpg & File:Ingeborg Strobl - Mahnmal für verlorengegangene Artenvielfalt 1997 (1).jpg. While the first file shows the description: Skulptur "Hand und Traube" bei Wetzelsdorf, Gemeinde Poysdorf, Niederösterreich, Österreich, the second shows Dieses Foto zeigt das im digitalen Kulturgüterverzeichnis des Landes Niederösterreich (Österreich) unter der Nummer. (lang German selected). (you can use https://de.wikipedia.org/wiki/Liste_der_Kunstwerke_im_%C3%B6ffentlichen_Raum_in_Nieder%C3%B6sterreich/Weinviertel to run the mediaviewer)

I would expect that all the language specific parts of the description are shown (multiples possible) and that all non-language specific parts are shown too. Furthermore I would expect that templates are transcluded correctly (which means that that number in the second case must be visible).

It looks like that only the last matching paragraph is shown as the description in mediaviewer. If only one paragraph is shown, than the first one should be preferred. ISO 3166 Bot (talk) 14:41, 24 June 2018 (UTC)Reply

Sorry, used my bot account, but it's me --Herzi Pinki (talk) 14:43, 24 June 2018 (UTC)Reply
The template part is because c:Template:Public Art Austria/layout marks only the text with <div class="description language">. It’s really suboptimal, though. Tacsipacsi (talk) 22:38, 24 June 2018 (UTC)Reply
Thanks for the hint, helped a lot. (for the template part only) Herzi Pinki (talk) 08:35, 25 June 2018 (UTC)Reply

3D view: bug and wishes

[edit]

Dear all – I'm writing on behalf of the WikiProject Dinosaurs in the English Wikipedia. We were intrigued to find out the Media Player now supports stl 3D files. For our topic (dinosaurs), we are describing complex bone morphologies on a regular basis. 3D models would be a very significant improvement to our articles, making it much easier for readers to comprehend what the article text tries to describe. We encountered one problem with the starting position though, and furthermore would like to file a wish.

1) The starting position in which the model is shown (both in the thumbnail and in the 3D window) is very different from that of external viewers (tested with MeshLab). Because of this, we are unable to rotate the objects into their proper orientation (e.g., side view). When I change orientation using MeshLab and re-upload the file, the orientation shown by MediaViewer changes as well, but just in a different, and seemingly arbitrary direction.

2) It would be of even more value to be able to upload models with vertex colors or, better, textures, which are possible when using the format PLY. Without color, it is very difficult for readers to recognize the bones shown. PLY would require two files for one model: A mesh file and a texture file (usually .jpg). While .stl files are the standard format for, e.g., CT data, PLY is commonly used for photogrammetry models, which are based on photos and thus naturally will include texture. Photogrammetry is an easy and cheap method that (in contrast to CT data) can be easily employed by Wikipedia authors themselves to build models for Wikipedia, provided they have access to the objects. I myself already have a bunch of self-made models, all including texture files, that would be of great use for our articles. For these reasons, we think that the support of textured PLY files would be an addition well worth the effort.

Files tested:

File:Massospondylus_skull_BP-1-5241_3D_scan.stl File:Aquilops cranium scan.stl Jens Lallensack (talk) 19:18, 2 July 2018 (UTC)Reply

A problem about https

[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I am changing my site to https protocol.Then MediaViewer crashed,and display “could not load image from http://foo.bar”.

That’s strange.Can somebody teach me how to solve this?($wgServer has been modified) 机智的小鱼君 (talk) 18:48, 27 November 2018 (UTC)Reply

For example https://wjghj.cn/index.php/博客:机智的小鱼君/2018年/11月/28日/每周临摹#/media/File:每周临摹_20181128.jpeg 机智的小鱼君 (talk) 18:50, 27 November 2018 (UTC)Reply
Sorry! That’s Cache !! All things right !!! 机智的小鱼君 (talk) 18:55, 27 November 2018 (UTC)Reply
The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

ImageMap

[edit]

Is it possible to use this extension alongside the ImageMap extension? I would love if you could click on the thumbnail to bring up MultimediaViewer and still have the option of clicking on different parts of the image which have been mapped to link to different pages. If this isn't possible at all does anyone know of any other extensions which could do something similar? Mjb294 (talk) 04:34, 12 December 2018 (UTC)Reply

There's no real need to use an extension for this, since you can embed absolute-positioned divs or spans along with the image itself inside a relative-positioned div to define linked areas. Specifically using normal link syntax with the positioned structures inside them where you'd normally have the link text. DSquirrelGM𝓣𝓟𝓒 04:49, 12 December 2018 (UTC)Reply
This solution has two problems. First, absolute positioning is awkward and far less flexible than imagemaps (imagemaps can have links of virtually any shape, while absolute positioning is even more awkward if you want to use any shape other than rectangles, if possible at all). Second, they don’t work with MultimediaViewer, either. Tacsipacsi (talk) 16:42, 12 December 2018 (UTC)Reply

Thumbnail guessing on REL1_31

[edit]

After upgading from REL1_27 to REL1_31 I realized that $wgMediaViewerUseThumbnailGuessing = true; does no longer work. The other setup especially for the 404 handler did not change. Either the smallest resolution is picked for up-scaling of the image resulting in a very pixeled view or alternatively the image is not being scaled at all resulting in a tiny thumb in the view. After changing the setting back to the default false everything works again. This happened for several wikis. On REL1_27 everything was cool. [[kgh]] (talk) 14:02, 11 September 2019 (UTC)Reply

Metrics

[edit]

If a user opens a file page, it's counted as a pageview and appears in the pageviews tool.

If a user opens an image in MultimediaViewer, is it counted as a pageview?

Pinging some people who might know: @Neil Shah-Quinn (WMF), @JAllemandou (WMF), @Mforns (WMF). Amir E. Aharoni {{🌎🌍🌏}} 08:28, 12 December 2019 (UTC)Reply

Hey @Amire80, good question! When a user opens an image in MultimediaViewer, the browser makes a request to upload.wikimedia.org for a larger image and some requests to the Action API for image metadata. According to the pageview definition, none of those requests count as pageviews. In particular, they fail the test of their URLs containing "a 'content' directory (mainly /wiki/, but also /zh-hant/ or another language variant directory)".
On the other hand, the request to upload.wikimedia.org would be counted in the Mediacounts dataset. That dataset has been available internally for some time, and the Analytics team has just started doing public releases. Neil Shah-Quinn (WMF) (talk) 11:13, 12 December 2019 (UTC)Reply
Thanks!
The reason I'm asking is that a GLAM institution asked me how can they check how many of the images they upload are actually viewed, and they are interested in both file description page views and Multimedia Viewer views, which makes a lot of sense.
Do you have an idea where can they get it? The mediacounts page, to which you linked l, doesn't make it entirely clear where can one get it publicly, but maybe I'm missing something.
I'd actually say that it should be included in the same dataset as the usual pageviews, perhaps with some properties that indicate a different medium, because most people who upload images and want to know how often are they used, probably want to get info about all pageviews. Amir E. Aharoni {{🌎🌍🌏}} 16:02, 12 December 2019 (UTC)Reply
Does the availability section of the mediacounts page answer your question? It says the dataset is publicly available as daily TSV dumps, and privately available in Hive. Unfortunately, that means it will be very hard for that institution to get an answer to their question; I think Analytics is working on a public API which will make it possible to build something similar to the pageviews analysis tool, but I don't know when it will arrive. Neil Shah-Quinn (WMF) (talk) 17:00, 12 December 2019 (UTC)Reply
OK, that's a beginning :)
Thanks! Amir E. Aharoni {{🌎🌍🌏}} 19:40, 12 December 2019 (UTC)Reply
You're welcome!
And if you're just concerned about giving this institution a one-time answer, you could fairly easily run a Hive query and give them the results; let me know if you need any advice about that. But if you're more concerned about the general issue of GLAMs having access to media view data, of course that wouldn't scale. Neil Shah-Quinn (WMF) (talk) 04:25, 13 December 2019 (UTC)Reply
[edit]

How are file links passed to MultimediaViewer?

I'm going to use private wiki as photo library. Pictures can be taken from different cameras, so file names across the whole library may be not unique. Storing them in different directories is the only acceptable solution. Renaming is not considered due to amount of files. Also my pictures and pictures shared with me by others should be in different directories. So my decision is to copy files to images/Photo/XXXX/ subdirectory, where XXXX is a sequence number, then to run modified maintenance/importImages.php script to create corresponding DB records. Also I had to modify some scripts to replace '/' with '%2F' for correct processing in links. Now everything works fine except MultimediaViewer. The latter also works fine from a file page via 'Open in MultimediaViewer' button, but not from a standard article page. Button on a file page generates link e.g. wiki/index.php/File:Photo/00003/DSC_3201.JPG#/media/File:Photo%2F00003%2FDSC_3201.JPG, which is correct. When I click on thumbnail on article page the link generated gets wrong: wiki/index.php/Photo/00003/3201#/media/File:DSC_3201.JPG, missing 'Photo%2F00003%2F' part of subfolder and causing file not found (404) error.

I can't find out how this link is generated. I tried to review source code of both page types but with no result. I can't see neither 'Open in MultimediaViewer' button in the source of a file page nor incorrect links or '#/media' keyword in the source of an article page. Also I tried to search '#/media' substring in contents of all files in wiki/ subdirectories, found 3 files but without explicit correlation with the url passed (or generated).

Could you please help? Ievgen D (talk) 21:41, 15 April 2020 (UTC)Reply

[edit]

Recently added this in .htaccess file so that all the visits would go to https instead of http

RewriteBase /

RewriteCond %{SERVER_PORT} 80

RewriteRule ^(.*)$ https ://www.webname.com/$1 [R,L]


Since then the download and full size links in MultimediaViewer are messed up. I keep getting these links:

http: //www.webname.com/images/f/f8/filename.jpg?download

and the system changes those links to these, with the /images/ tag missing, so nothing shows up

https: //www.webname.com/f/f8/filename.jpg?download

Any way to solve this please? Oierla1 (talk) 11:39, 22 April 2020 (UTC)Reply

Error: Unknown_operation

[edit]
Does MultimediaViewer log detailed error information anywhere? I am trying to debug a problem where MultimediaViewer can't display any images. It displays a black error screen,

"Sorry, the file cannot be displayed. There seems to be a technical issue. You can retry if it persists. Error: Unknown_operation."

When this error is displayed, the usual buttons for "Download this file" and "Share and embed this file" link to https://name-of-wiki.com/w/null.

When MultimediaViewer is disabled, images display perfectly as File:NameOfImage and Media:NameOfImage.

This is MediaWiki 1.35.0. Thanks for any insights. Maiden taiwan (talk) 02:23, 16 December 2020 (UTC)Reply

The apache error log shows no error message. Maiden taiwan (talk) 02:23, 16 December 2020 (UTC)Reply
Upgraded to MW 1.35.1. No change.
Is this extension still maintained? Is this the right place to get help? Maiden taiwan (talk) 17:50, 4 January 2021 (UTC)Reply
Hi I also got an error message (and no error message in Apache) that is slighly different. "Sorry the file cannot be displayed. There seems to a technical issue. You can retry if it persists. Error could not load image from htt:// .......
MW 1.35.1 Daniel K. Schneider (talk) 10:36, 23 April 2021 (UTC)Reply
The log would be on the browser side, not the server side. Did you try checking the developer console log? Jeffrey Wang 20:46, 27 April 2021 (UTC)Reply

WebP Support

[edit]

Does MultimediaViewer support WebP images? If so, what is the process to enable support? In my current implementation of MultimediaViewer WebP images are not displayed, and are skipped in the "Show Next Image"/"Show Previous Image" interface as seen in this example ( blazblue.wiki/index.php?search=Alternative+Dark+War+Icon&title=Special%3ASearch&profile=images&fulltext=1 ) Lordhelpus (talk) 18:33, 19 January 2021 (UTC)Reply

It does now:
github.com/wikimedia/
mediawiki-extensions-MultimediaViewer
commit 00ae50ea496438d7fe3b1ec8c68b1108100d07ed 189.122.96.244 (talk) 22:12, 12 February 2023 (UTC)Reply

How to hide metadata bar

[edit]
The height of the area of the metadata bar which is visible without scrolling is defined in the file 'resources/mmv/mmv.variables.less'. Changing the corresponding entry to
@metadatabar-above-fold-height: 0px;
makes the metadata bar disappear at first sight. Its content remains available via scrolling, though.

This is the perfect solution for people who do like MultimediaViewer for the functionality it provides but dislike the visual design that features font sizes that attack one's eyes with a yell. Sm8ps (talk) 21:20, 15 July 2021 (UTC)Reply

If you really want to hide it for all (or a group), just put
.mw-mmv-image-metadata
{
display: none !important;
}
in your Mediawiki:Common.css page (or an other css page for a group). Nanash (talk) 17:38, 30 October 2022 (UTC)Reply

Deep Linking videos

[edit]

This extension is great. The ability to stream mp4 videos from mediawiki in a player is an essential part of what we use MediaWiki for.

That said, we would like to be able to "Deep Link" key moments in the video so that people can click the link and go right to a specific time index of the video.

Is this possible? Revansx (talk) 12:50, 10 August 2021 (UTC)Reply

BMP format don't work?

[edit]

I have a stupid question, but I don't find the answer sorry...

Which format can support this extension?

Because I notice that with jpeg it work very well but with bmp he dones't work (in my wiki) so maybe it's in the configuration? Nicolas senechal (talk) 17:13, 23 February 2022 (UTC)Reply

There’s an undocumented parameter named $wgMediaViewerExtensions, with the default value of
[
	'jpg' => 'default',
	'jpeg' => 'default',
	'gif' => 'default',
	'svg' => 'default',
	'png' => 'default',
	'tiff' => 'default',
	'tif' => 'default'
]
So I think you can just set
$wgMediaViewerExtensions['bmp'] = 'default';
in your LocalSettings.php—and hope that the extension doesn’t make any assumptions that aren’t true for BMP. (I should also add that I don’t have MultimediaViewer installed on my own wiki, so everything I wrote is based on reading the source code, I haven’t actually tried out anything.) Tacsipacsi (talk) 22:04, 24 February 2022 (UTC)Reply
Its work thanks you for the tips,
It's possible to document $wgMediaViewerExtensions? Nicolas senechal (talk) 08:37, 25 February 2022 (UTC)Reply
Commenting here because Google took me here and others might be in the same situation..
The solution above didn't work for me, but I got around it by adding the following to my LocalSettings.php so it uses ImageMagick (built-in) instead of PHP to handle images:
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert"; Derf Jagged (talk) 18:58, 31 December 2023 (UTC)Reply

In private mediawiki, issue in opening image with mediaViewer

[edit]

I have disabled $wgMediaViewerUseThumbnailGuessing and edited resources/mmv/provider/mmv.provider.Image.js and changed to imagePreloadingSupported to always return false. But still facing issue in opening image with Private namespace.

Media wiki version - 1.35.3,

MultimediaViewer version - MultimediaViewer-REL1_35-0e0e0f7.tar.gz Boopalag (talk) 12:06, 26 August 2022 (UTC)Reply

Extension / gadget API

[edit]

Does MMV have a JavaScript interface to configure a thumbnail (created after the MMV bootstrap is finished) and open it? Possibly without a URI hash change (since that won't really work if bootstrap can't catch it)? Alex44019 (talk) 13:12, 25 December 2022 (UTC)Reply

How to mitigate CORS policy issue?

[edit]

After the image flashing very briefly it get the error that the file cannot be loaded. I am getting the following error in my browser console:

Access to image at '.../w/images/6/6f/MyFile.jpg' from origin '...' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

The first ... stands for https: // repo . example . org, the second ... for https: // en . example . org

.../w/images/6/6f/MyFile.jpg:1          Failed to load resource: net::ERR_FAILED

Here ... stands for repo . example . org

Tried to add the following to .htaccess but it did not work:

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "..."
</IfModule>

Here ... stands for https: // en . example . org

Still the CORS policy violation prevents the thumb from being loaded.

Does anybody have a clue? 2003:F1:C70E:6600:630D:4D5:7627:FA99 (talk) 23:33, 24 February 2023 (UTC)Reply

Also tried to add header("Access-Control-Allow-Origin: *"); to LocalSettings.php without success. 2003:F1:C70E:6600:463:E9E6:59CC:4DF2 (talk) 09:50, 25 February 2023 (UTC)Reply
LocalSettings.php won’t help, as images are served directly, without involving PHP (as far as I know). For the .htaccess solution, without digging much into the details, I see that there’s an IfModule guard. Do you have the headers Apache module enabled? (Do you use Apache at all? If you use other web server software, e.g. nginx or lighttpd, .htaccess will be of no use. Consult the server software documentation for how to enable CORS.) If you administer your server yourself, and it runs Debian or a derivative (e.g. Ubuntu), you can enable the module using sudo a2enmod headers. Tacsipacsi (talk) 13:32, 25 February 2023 (UTC)Reply
Thank your for your comments. This may explain things. So changing the setting for the headers module will indeed be the solution here?!
The managed hosting runs Apache, i. e. I can put stuff into my .htacces, however, it appears that I cannot modify settings related to the headers module. I can do stuff via command line however handling of the webserver is not part of it. This does explain why my setting to headers was ignored (to be verified with the provider) 2003:F1:C70E:6600:463:E9E6:59CC:4DF2 (talk) 20:37, 25 February 2023 (UTC)Reply
I’m not very experienced in administering Apache servers (I have a development server on my own computer that I administer, but that’s all), so I can’t say for sure that enabling the headers module will fix the problem, but I’m quite sure that it is necessary to fix it. Yes, if you have a hosting provider, you’ll probably have to either ask them, or use the self-service administration interface they provide (if they provide one). Tacsipacsi (talk) 09:38, 27 February 2023 (UTC)Reply

Not working on iPad

[edit]

I see in the help section, that the Viewer does not work on mobile platforms. Is this still the case in 2023? When i try to use it on my iPad Pro, it is coming up, but it says, "Could not load image". When disabled, the images loads perfectly in the standard viewer.

On PC everything works fine. If it is still not working on mobile, is there a way to disable it just for mobile? 2A02:8109:C40:E44:409A:173A:1395:98DD (talk) 19:53, 26 April 2023 (UTC)Reply

Update: It is working on my iPhone, but not on my iPad 2A02:8109:C40:E44:409A:173A:1395:98DD (talk) 20:22, 26 April 2023 (UTC)Reply
Which iOS/iPadOS versions do you have? If the iPad has older software than the iPhone, it can explain the difference. Tacsipacsi (talk) 17:00, 27 April 2023 (UTC)Reply
It is iPadOS 16.2 and iOS 16.3.1 which both are afaik the latetest releases
Will check on some other iPads tomorrow. 2A02:8109:C40:E44:303C:D139:AC54:B5F6 (talk) 18:55, 27 April 2023 (UTC)Reply
And both are the same major release, so version difference isn’t likely explain things. I don’t have Apple devices, so I can’t investigate this further, but hopefully someone else will. Tacsipacsi (talk) 23:52, 27 April 2023 (UTC)Reply

Cannot exit when zooming into image

[edit]

I'm having two issues with the viewer:

1. When I click into an image on the page, the screen goes into the Multimedia Viewer, and I can press the escape key or the cross button to get back out. However, if I'm in the Viewer and I click to zoom into the image, neither of those exit features work and I cannot exit the viewer unless I hit the back button in my browser. Is this normal? If not, is there a way for me to fix this?

2. When I have multiple copies of the same image on the page but with different captions (specified in wikitext), I found that the caption of the top-most image on the page is used for ALL the following image copies in the viewer. The captions are still correct for thumbnails, but they all revert to the caption of the top-most image when opened in the viewer. Again, is this normal? If not, is there a way for me to fix this? Blyatman9000 (talk) 01:31, 15 July 2023 (UTC)Reply

disabling MultimediaViewer for Ubuntu

[edit]

Adding

$wgDefaultUserOptions[ 'multimediaviewer-enable' ] = 0;

to "LocalSettings.php" doesn't work on Ubuntu Debian Linux for any browser (tested on Mozilla Firefox, Google Chromium, Google Chrome, Microsoft Edge, and Opera). Images open with MultimediaViewer on Ubuntu Debian Linux but not on Microsoft Windows.

Nicole Sharp (talk) 22:28, 1 September 2023 (UTC)Reply

This appears to be a bug. Using
$wgMediaViewerEnableByDefault = false;
instead of
$wgDefaultUserOptions[ 'multimediaviewer-enable' ] = 0;
works for Ubuntu Debian Linux.
Nicole Sharp (talk) 22:44, 1 September 2023 (UTC)Reply

Handle non-image files

[edit]

On my self hosted mediawiki I upload some documents (like ODT, DOC, XLS, ecc) and add one or more categories on it.

When I go on the category special page (eg Category:coverLetters) on the bottom I see the all documents related, BUT with a withe page thumbnail.

If I click on the thumb, Multimediawiki say "Oh sorry, the file cannot be viewed.[...] File does not exist: File:Fileicon.png".

I belive that MMV has to check if a file ends with .jpg, or png or image related extensions, and not to work with others.

Is it possibile to do? Kaya8422 (talk) 15:55, 5 October 2023 (UTC)Reply

When closing the Viewer, I get scrolled to the top of the page

[edit]

On my wiki, when I close the Viewer, I am not simply back to where I was on the page, but I get scrolled up to the top of the page. Do you know what could cause this behavior ? Varlin (talk) 16:37, 3 January 2024 (UTC)Reply

Customization of white info field

[edit]

Is there a way to customize what is shown in the white info box at the bottom of an image shown in MultimediaViewer? E. g. adding or removing information there? Krabina (talk) 12:34, 18 June 2024 (UTC)Reply