I have mucked about a little bit, and it seem like some work has been done on Github on this fork Github for Washington State
However, I had to reset the mime-type edit they had done for S3, otherwise I just saw the raw code of the files in the webbrowser.
Furthermore, I have looked on my server, and the uploaded files are uploaded correctly. When downloaded via FTP, they are uncorrupted. Something must be going on when it translates the file-name to the file in the upload directory.
I have also tested in uploading a variation of PDF-documents.
- Adobe illustrator PDF: Works
- Libreoffice PDF: Works
- NAP PDF (scanner software): Works
What doesn’t seem to work is PDFs created by my clients scanner/printer. Those are the only ones being corrupted when I upload them.
Will keep on posting if I find anything else.
-
This reply was modified 9 years, 4 months ago by
neocreo. Reason: forgot link text
Hmmmm. Apparantly not only PDFs.
I have managed to recreate this problem with other filetypes.
ODT – corrupt – from LibreOffice
PDF – works – from LibreOffice
DOC – works – from LibreOffice
DOCX – corrupt – from LibreOffice
It must be that the plugin has trouble handling certain filetypes. Guess I need to do some scouring here in the support forum again.
OK, so WOW! I think I solved it.
I was dabbling with the MIME-types and that didn’t work. So now I looked at WHEN the file is served.
Row 70 in wp-document-revisions.php
add_filter( 'template_include', array(&$this, 'serve_file'), 10, 1 );
It seems like the standard priority of 10 is not good enough in WP +4.5.3.
add_filter( 'template_include', array(&$this, 'serve_file'), 15, 1 );
As soon as I changed the priority to HIGHER than 10 it worked. Lower than 10 it caused corruption.
I hope this information might come in handy for all you other hackers of this dead plugin.