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.
@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
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?
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 );
} );
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.
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
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.
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.
Hi there,
Yes it also fixed my problem (MediaWiki-1.34.1). Thanks for that!
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
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 );
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
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?
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 ?
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?
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.)
Its work thanks you for the tips,
It's possible to document $wgMediaViewerExtensions?
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";
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?
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)
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)
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?
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?
Update: It is working on my iPhone, but not on my iPad
Which iOS/iPadOS versions do you have? If the iPad has older software than the iPhone, it can explain the difference.
It is iPadOS 16.2 and iOS 16.3.1 which both are afaik the latetest releases
Will check on some other iPads tomorrow.
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.
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?
Also tried to add header("Access-Control-Allow-Origin: *"); to LocalSettings.php without success.
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.
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)
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).
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 )
It does now:
github.com/wikimedia/
mediawiki-extensions-MultimediaViewer
commit 00ae50ea496438d7fe3b1ec8c68b1108100d07ed