We have some TEI files that we'd like to associate with some of our items, and in lieu of a TEI plugin for Omeka 2.x, we're attempting to simply upload the xml files to the site and attach them via the item edit screen. I've changed the security settings to allow application/xml and text/xml MIME types, as well as xml under the whitelist of file extensions, but when I attempt to upload the xml file (or associate it via the Dropbox plugin), I get an error. I've uncommented the error line in my ht.access file, but don't get any error message below the generic one.
The issue seems to center around the file extension, as adding xml to the whitelist is where the problems start to occur. Is this possibly an file type validation issue? Any other ideas why I might be getting this error?
Thanks in advance,
Adam
I've changed the security settings to allow application/xml and text/xml MIME types, as well as xml under the whitelist of file extensions, but when I attempt to upload the xml file (or associate it via the Dropbox plugin), I get an error
Can you include the error message here in this thread?
The issue seems to center around the file extension, as adding xml to the whitelist is where the problems start to occur.
So, adding XML to the whitelist starts the problems you're having?
Curious how big your files are, since you might be running into a file upload limit issue. Wouldn't really know without knowing the text of the error message, though.
You can also turn off your file upload restrictions by checking the "Disable File Upload Validation" setting under your Security Settings, but note that this means anyone with access to add items could upload any file they want.
Jeremy,
We're not actually getting any error messages. Error reporting is enabled, but we simply get an "Omeka has encountered an error" message, without anything more specific. I've seen this happen on another Omeka 2.x installation we have, and I'm not sure why we're not getting the actual error text.
The file I just tried is 3kb, so i don't think that's the issue. I've also tried turning off file type validation. When xml is allowed as a MIME type but not on the list of accepted file extensions, we get the error we'd expect (that it's not an accepted file extension), but when we put xml on the whitelist or try to turn off validation, we get the generic error.
Is it possible that the xml file is failing to validate against the schema, or that Omeka can't find the schema document? Would this cause an error when attempting to upload or attach a file to an object?
Is it possible that the xml file is failing to validate against the schema, or that Omeka can't find the schema document? Would this cause an error when attempting to upload or attach a file to an object?
Unless something's changed I'm unaware of, Omeka shouldn't actually care what's in the contents of the XML file. It should load it just fine. I don't think a vanilla installation of Omeka will validate the XML. If, however, you've set something up with some custom code to do that, that might a possibility.
Agreed that file size wouldn't seem to be an issue.
You might get more luck with messages if you update some settings in application/config/config.ini, like setting the debug.exceptions setting to "true" and log.errors to true. With the latter, you'll need to make sure you have a application/logs/errors.log file that's writeable by the server.
I've had issues with the error log before, but got it to work this time. Here's what I found:
identify: Memory allocation failed `/tmp/18ae67f198048f391bf5209cd5bac64c.xml' @ svg.c/ReadSVGImage/2825.
2013-10-18T20:28:18+00:00 WARN (4): Omeka_Storage_Adapter_Filesystem: Tried to delete missing file 'original/18ae67f198048f391bf5209cd5bac64c.xml'.
2013-10-18T20:28:18+00:00 ERR (3): exception 'Omeka_File_Derivative_Exception' with message 'ImageMagick failed with status code 1. Error output:
convert: Memory allocation failed `/tmp/18ae67f198048f391bf5209cd5bac64c.xml' @ svg.c/ReadSVGImage/2825.
convert: missing an image filename `/tmp/fullsize_18ae67f198048f391bf5209cd5bac64c.jpg' @ convert.c/ConvertImageCommand/2800.
' in /home/newberry/webapps/makingmodernism/application/libraries/Omeka/File/Derivative/Image/Creator.php:172
It seems that perhaps there's an issue with how it's attempting to handle the xml -- I'm not sure why ImageMagick is trying to do something to the file, but that seems like that could be the issue. We're attempting to add this xml file to an item defined as text, and it already has a jpeg associated with it. Any ideas?
Thanks again for your help.
Yup, just replicated this on the stable-2.1 branch and master branch on Omeka. I just used a random XML file I had on my laptop. Seems like this might be a bug in Omeka. You should consider filing a bug on the Omeka issue tracker on github with details about this issue.
Hmm. So far I haven't been able to reproduce it -- could be a difference with ImageMagick.
Omeka tries to create a derivative image for any file, which is why ImageMagick is coming into play.
Patrickmj, for what it's worth, I have ImageMagick 6.8.6-3.
Well, that makes the ImageMagick guess seem less likely. I'm on 6.7.7-10.
It's very likely to be differences in ImageMagick.
It looks like it's attempting to interpret any .xml file as a possible SVG image. A 3kb file shouldn't really be causing "memory allocation failed" messages, but it could be some issue ImageMagick runs into when it tries to interpret a non-SVG XML file.
We don't have any explicit filetype whitelisting or blacklisting anymore, we just call ImageMagick and ask it to identify the file to see if it can read it.
For what it's worth, I tried this myself with a random XML file, and it worked fine. ImageMagick's identify just claimed it couldn't read the file, and Omeka allowed it to be uploaded. I'm using ImageMagick 6.8.6-8, and I do have read/write support for SVG.
John, do you think that an Imagemagick upgrade is likely to solve the problem?
I'm not sure, but it's certainly possible, and I'd definitely look into it if you're self-hosting or can otherwise easily swing an update to ImageMagick.
We may have to think about introducing a mime type and/or extension blacklist again, though. This particular error is odd because we specifically attempt to avoid these problems by calling identify before convert.
If you have shell access, can you post the results of running identify on a problematic XML file? For reference, what I get is: "identify: no decode delegate for this image format." This is basically what you would expect for a non-image.
I ran identify on the copy of the file I had sitting in our Dropbox plugin's file folder and I got this error:
Memory allocation failed `MMSTietjensBox4Folder237.xml' @ svg.c/ReadSVGImage/2825
As far as I can tell, an update to ImageMagick requires wiping the version currently on the server and doing a clean install. I don't know much about IM; is there a chance of fouling anything up when doing this replacement?
Thanks,
Adam
I have the same problem omeka-2.1.2
ImageMagick 6.8.7-7 Q16 x86_64 2013-11-27 http://www.imagemagick.org
ImageMagick failed with status code 1. Error output:
convert: must specify image size `/var/tmp/magick-15594Uyx3mTsDKNwA' @ error/mvg.c/ReadMVGImage/185.
convert: no images defined `/var/tmp/fullsize_91ae292b80b9dfe98513b81d5ac4f560.jpg' @ error/convert.c/ConvertImageCommand/3145.
I've never resolved the issue, and due to the fact that it's happening with various versions of ImageMagick, I'm not so certain that IM is at fault.