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
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
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)?
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.
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).
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
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?
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?
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.
Upgraded to MW 1.35.1. No change.
Is this extension still maintained? Is this the right place to get help?
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
The log would be on the browser side, not the server side. Did you try checking the developer console log?