I'm trying to upload different files to my MediaWiki site to test out if everything was gonna work or not. The uploads were successful, but when I got to each file page for the file I uploaded, it appears that it wasn't showing the thumbnail of the file. For some weird reason, whenever I tried uploading JPEGs or PNGs the thumbnails would show up, but when I tried to upload PDFs, TIFFs, MP4s, WEBMs, MOVs, etc the thumbnails wouldn't show up (or in the case for media files the media player didn't show up). I don't know if it is some sort of extension(s) I have to install or something else but for pdfs I was expecting to see something like this: https://en.wikipedia.org/w/index.php?title=File%3ABonaparte_-_Acte_de_M%C3%A9diation%2C_1803.pdf&page=1. As for any movie or audio files, just the standard Wikimedia Commons players. And for TIFF, just the way that is done with JPEG and PNG. If anyone could help with this I would be grateful, thanks
Topic on Project:Support desk
Thank you for the response! I downloaded each one (except for PDFHandler because it is already downloaded) and added their respective wfLoadExtension(); functions in LocalSettings.php. However when I tried doing the PDFHandler it wouldn't show the pdf like in the link I sent you (I even downloaded that pdf and uploaded it to my site but the problem remained). All that is added is a warning about PDFs. Then I tried the TIFF handler but the same problem happened. Finally I tried to do the TimeMediaHandler but now whenever I try to go to the pages specifically for those files my web browser gives me the error that the page is inaccessible. Thanks
These extensions require some additional programs installed on the server which might be the issue (although often they are already installed), check their docs for details. Other than that, are there any error messages? What does mediawiki say the dimensions of the file are.
Also if newly uploaded files work but old ones dont, you might need to purge the old pages.
For the page inaccessible thing - make sure that php error reporting is enabled. See How to debug for details.
No there isn't any error messages for the TIFF and PDF file formats both of which show 0 x 0 dimentions. However for the case of the media player (of which this problem I was about to post about in its respective Discussion page), my browser either tells me that the page is inaccessible or the page loads and gives me this error message: [YrucAQ2Mk-EubQoECBuYnwAAAM8] 2022-06-29 00:25:37: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
Before I didn't have ffmpeg but then I tried installing the 5.0.1 standard Linux version from this page (which was linked from the official website) https://johnvansickle.com/ffmpeg/, and extracted the files into a folder to which I linked to with the specific function ($wgFFmpegLocation), but the same problems happened.
"No there isn't any error messages for the TIFF and PDF file formats both of which show 0 x 0 dimentions."
I had this problem with PDFs on a shared server and couldn't get to the bottom of it, despite advice from here. When I set up a VPS from scratch it just started to work. That knowledge might or might not help you!
So 0x0 dimension usually means there is a problem extracting width and height. For pdfs, this usually means pdfinfo command is not installed. For tiff, i think this means identify is not installed. Sometimes these values get saved so after changing something you should upload a new file to test (or run refreshImageMetadata.php). It can also mean mediawiki cannot run external programs (check php error log. Also mediawiki debug log may have more info on precisely what command is run)
For the timedmediahandler error - most commonly that means you need to run update.php (or the web installer) . Also consider enabling $wgShowExceptionDetails=true; in LocalSettings.php
I'm sorry for not responding for months, but do you know exactly how to download xpdf and configure it for MediaWiki? What file(s) do I put it in, do I need to extract anything, run anything, etc? Thanks
It depends on your operating systems. On debian typically via apt get. Now a days people tend to use poppler-utils instead of xpdf.
I am using Bluehost which uses CentOS, unfortunately on a Shared Hosting account. Therefore I can't use yum, sudo, apt get, etc unfortunately. I did manage to download the tar zip file from xpdf and put it into the usr/bin/pdfinfo sub-directory and unzipped it. However whenever I try to use the command which gs convert pdfinfo pdftotextit only gives me the results of:
/usr/bin/gs
/usr/bin/convert
In the INSTALL file under the folder that is created from the zip file, it says that
There is no need to "install" anything from this package. You can
unpack the tar file and run the binaries directly from there.
However by "running the binaries directly from here" is what I don't exactly know what to do
If the folder you are installing it to is not in your $PATH it wont show up in which and you have to use the full path to ru it.
E.g. if it is in a subdirectory usr/bin /pdfinfo of the current directory you would run it as ./usr/bin/pdfinfo
You may have to use chmod command to set the execute bit (chmod u+x path/to/file) although it may have already been done for you if its from a tar file.
So, I think I know what you mean but I want to make sure and ask some questions. The bin folder that I put the xpdf files under is under a directory (lets just call it "site"), which is also under a directory called "home". so /home/site/bin/. However through my SSH I figured out where the other two files (convert and gs) were actually located, and they weren't in /home/site/bin/. Instead I figured out that there was a parent directory above home/ with no name (lets just call it parent). Under parent (which as I found out doesn't allow for the ls command and gives you an error), I figured out that the true usr directory was under parent, and that when you go to bin under that folder, thats where all the other "scripts" such as convert and gs are. so parent/home/site/bin and parent/usr/bin. The problem is however, is that usr is a read-only directory (because I'm on shared hosting), and so I can't put, delete, or modify anything under usr. Therefore I can't put pdfinfo nor pdftotext in there. I then tried modifying $wgPdfInfo and $wgPdftoText to the correct directories to which pdfinfo and pdftotext are located, but when I go to any pdf files (even ones I uploaded after modifying the variables), the 0 x 0 problem still shows. I'm not sure if the solutions you gave have to do with this, but I wanted to explain the full problem to better solve it. Again thank you for all your help.
For reference, what you are referring to as "parent" is usually called the root directory, or just /.
That all sounds like the normal setup for shared hosting. Most programs are in /usr/bin (or a few other more obscure directories), but only the system administrator can add things there.
Programs can normally be anywhere, but if they arent in the normal directory, you have to type out the full path name instead of just the program name.
The one extra thing is the program has to have the execute permissions in order to run as a program. You can change a program permission with the chmod command.
Some shared hosts dont let you run custom programs (perhaps via selinux rules or something), so that's a possibility that may or may not apply to you, although most hosts do allow it.
If you enable the mediawiki debug log (see How to debug) it should include what it tried to run and errors encountered which might help with debugging.
There are also many different types of linux. If you got precompiled binaries, its possible you have the wrong type. I would try running these commands with the full path ( so if binary is in the site directory, typing /home/site/pdfinfo ) from ssh to make sure the programs work.
So I was able to finally find a version of xpdf that supports glibc 2.12... through the wayback machine (I got 4.02 from mid-late 2020). I then replaced 4.04 with 4.02, and now the new pdftotext and pdfinfo work, except for a few problems. So the new paths that they are under is home/site/bin/xpdf-tools-linux-4.02/bin64/(pdfinfo/pdftotext). I then ran each one with the ./ command thing before home/site/etc and they worked, giving me a list of commands to run with pdfinfo or pdftotext. However, thats basically where it ends. I tried to link each filepath with the $wgPdftoText and $wgPdfInfovariables, each one with the filepath that I mentioned, but then I type in which pdfinfo pdftotext into my SSH, and nothing shows. I then tried your chmod u+x thing for each one and each command worked without errors, but then I went back again to the which command and still nothing. Each file has all permissions set to 777, and still nothing.
Nvm, this part I actually solved, since then I added the
$wgPdfProcessor = '/usr/bin/gs';
$wgPdfPostProcessor = $wgImageMagickConvertCommand;
to LocalSettings.php above the pdfinfo and pdftotext link variables (I don't know if this contributed to solving the problem, but just wanted to let future users know)
I then ran both the refreshImageMetadata.php and rebuildImages.php scripts, and then I went back to the pdf files, and they worked!!! :)
I tried the debugging this, but no errors pop up. I have both programs set their permissions as 0777 so they can do as they want. I then tried executing each program via the ./pdfinfo and .pdftotext (I was in bin) and they gave me this error: ./pdfinfo: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./pdfinfo/pdfinfo). I looked into it and found that I needed to download glibc 2.14 and found where I could download it from gnu. I couldn't find however where exactly to extract it for MediaWiki. Thanks
You probably dont want to just download your own libc. That gets really complicated. Its probably better to find a copy of pdfinfo that has been compiled for the version of glibc included with your OS or try compiling it yourself (also rather complex).
if you really want to try a custom libc, read up on LD_LIBRARY_PATH, but i really reccomend against it.
I also have a problem with tiff files. The extension seems to be working, but I have three different issues. This first two go with tiff files where their title with the extension ends with .tiff. First, some tiff files do give me a thumbnail but its with a grey background with the message saying: Error creating thumbnail: File with dimensions greater than 12.5 MP . The second type of files is when I go to them, at the top (I have debug available now lol) it gives me the following repeating error message:
Notice: Undefined index: first_page in /home/site/public_html/extensions/PagedTiffHandler/includes/PagedTiffHandler.php on line 518
Notice: Undefined index: last_page in /home/site/public_html/extensions/PagedTiffHandler/includes/PagedTiffHandler.php on line 531
At one point in the middle of it repeating (it repeats line 531 one more than 518), it puts the following:
Notice: Undefined index: page_count in /home/site/public_html/extensions/PagedTiffHandler/includes/PagedTiffHandler.php on line 505
The full page below with the rest of the page's content show a blank thumbnail at 0 x 0.
Then theres the tiff files where when I upload them, they get a .tif title instead of a .tiff. When I go to the page for them, even though the files do no have two pages on them (like a pdf file) it shows the dropdown to flip to other pages (like in pdfhandler). There are two pages, the first one just being one with a thumbnail displaying the same error message with the 12.5 MP thing from above, and the second one being the actual image file.
for the 12.5MP thing, adjust $wgMaxImageArea in LocalSettings.php
I tried increasing it to as much as $wgMaxImageArea = 10e7;, but in all cases they say instead of 12.5MP, same message but with 100MP. Btw these things are scanns of documents of around 3200 dpi and above. I know that Mediawiki (mine especially) is able to reduce the size of the image to fit on the page because as I mentioned with a bunch of the tiffs it gives me two pages (when theres only one) of the same thing, one with the image itself, and the other exactly the same size with the error message. Also even though for the images that are displayed, if I click on "open media viewer", it gives me the error that it couldn't be displayed, retry, etc. I have no idea what I'm supposed to try and do to fix all that
For the double paged one as well, even if I click on the one that shows the proper thumbnail, if I go into MediaViewer, it gives me an error message saying: There seems to be a technical issue. You can retry if it persists. Error: error in provider, thumb info not found
TimedMediaHandler breaks visualeditor? Can you please explain why this happens?
{ "error": { "code": "internal_api_error_TypeError", "info": "[f16b2d79985533c31ed7fe29] Exception caught: DOMElement::setAttribute(): Argument #2 ($value) must be of type string, null given", "errorclass": "TypeError", "trace": "TypeError at
Make sure you are using correct version of everything.