User Details
- User Since
- Jun 9 2016, 7:55 PM (420 w, 2 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Hopefully Acceptable Username [ Global Accounts ]
May 17 2019
I'm happy for the tag to go and to clarify the description. If this can be "fixed" with a MediaWiki-level warning I'd be even happier.
However I must report that the wiki site I run has been happily running misconfigured with no reports of malfunction for months. It's a simple but not trivial site, we have around 15 extensions. Clicking on embedded images is a seldom used functionality and we had not noticed other issues before I saw that one. And it sounds like someone else had the same issue before me... (Thanks for solving that by the way!)
May 16 2019
Thank you guys, this solved my problem as well. However, this is probably a common issue these days, as website managers move from http to https. Wouldn't it be nice if MV/MW could give a warning pointing to this specific issue? Is an "http" $wgServer ever sensible, once MediaViewer knows that it is being served on https?
Jul 31 2016
No, <poem> works as intended if I don't use templates. See my test cases.
https://www.mediawiki.org/wiki/User:Hopefully_Acceptable_Username#Poem_testing
I guess mine would be "maintenance templates". I need to be able to change the presentation of hundreds of pages with a single change, if I wanted to change from <poem> to something else tomorrow. Also there is other formatting going on, like table, etc.
Jun 17 2016
Hi there, is this still a problem?
I'm getting this error when trying to register (or password-recover) an account "Jane Jönsson" (note umlaut). No problem without umlaut, or indeed any other user I've successfully created with the same pattern (Name Surname), but without "funny" characters.
I'm using
Jun 10 2016
Cool thanks.
So am I right in thinking that:
- It's confirmed to be a bug
- There is a work-around for PDFs (install PDFHandler)
- There is no work-around for other files, namely MP3
I should add that doc, docx, and rtf files do not have that problem.
<div class="fullImageLink" id="file">
<a href="/wiki/images/8/89/MyFilename.PDF">
<img alt="" src="/wiki/resources/assets/file-type-icons/fileicon-pdf.png"
width="120" height="120" data-file-width="0" data-file-height="0" />
</a>
</div>Jun 9 2016
In fact, could this be? The file actually starts with a lowercase "f", that's why the viewer cannot find it
I think what's happening is that the "Open in Media Viewer" button does not refer to the PDF, but to the image of the PDF icon (Fileicon-pdf.png), which explains why the extension is valid and that test passes.
It's still a mystery why the viewer then fails to find the icon (hence the error), but the root cause here is that the icon makes that "Open" button appear.
mw.config.values.wgMultimediaViewer does not have an extensions... are you sure?
$ cat extensions/MultimediaViewer/version MultimediaViewer: a312b66de94cb2f1c1f1b33ee3bd3af1f41ef06c
Yep, that's what I have done, I still have the tarball in my extensions directory:
I have just downloaded and installed MultimediaViewer (0.3.0).
I did add some extensions at the bottom of my LocalSettings.php so I could upload the files. Here's the custom (bottom) part of LocalSettings.php: