Extension talk:MultimediaViewer

About this board

Nicolas senechal (talkcontribs)

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?

Tacsipacsi (talkcontribs)

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.)

Nicolas senechal (talkcontribs)

Its work thanks you for the tips,

It's possible to document $wgMediaViewerExtensions?

Reply to "BMP format don't work?"
Revansx (talkcontribs)

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?

Reply to "Deep Linking videos"
Sm8ps (talkcontribs)

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.

Reply to "How to hide metadata bar"

Does MultimediaViewer work on private wiki?

Seanchen (talkcontribs)
Tgr (WMF) (talkcontribs)

It should work fine, If it doesn't, please file a bug with the details.

Seanchen (talkcontribs)

@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,


Tgr (WMF) (talkcontribs)

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?

Nelmonk (talkcontribs)

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 );

} );

Seanchen (talkcontribs)

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.



Subfader (talkcontribs)

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)

Tgr (WMF) (talkcontribs)

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.

Seanchen (talkcontribs) (talkcontribs)

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.

Jesperjoachims (talkcontribs)

Hi there,

Yes it also fixed my problem (MediaWiki-1.34.1). Thanks for that!

MyWikis-JeffreyWang (talkcontribs)
Reply to "Does MultimediaViewer work on private wiki?"
Maiden taiwan (talkcontribs)

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 (talkcontribs)

The apache error log shows no error message.

Maiden taiwan (talkcontribs)

Upgraded to MW 1.35.1. No change.

Is this extension still maintained? Is this the right place to get help?

Daniel K. Schneider (talkcontribs)

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

MyWikis-JeffreyWang (talkcontribs)

The log would be on the browser side, not the server side. Did you try checking the developer console log?

Reply to "Error: Unknown_operation"
Lordhelpus (talkcontribs)

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 )

Reply to "WebP Support"

missing /images/ tag in download links

Oierla1 (talkcontribs)

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?

Reply to "missing /images/ tag in download links"

Link to an image in subdirectory

Ievgen D (talkcontribs)

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?

Reply to "Link to an image in subdirectory"
Amire80 (talkcontribs)
Neil Shah-Quinn (WMF) (talkcontribs)

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.

Amire80 (talkcontribs)


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.

Neil Shah-Quinn (WMF) (talkcontribs)

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.

Amire80 (talkcontribs)

OK, that's a beginning :)


Neil Shah-Quinn (WMF) (talkcontribs)

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.

Reply to "Metrics"

Thumbnail guessing on REL1_31

Kghbln (talkcontribs)

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.

Reply to "Thumbnail guessing on REL1_31"
Return to "MultimediaViewer" page.