I am working on uploading files to an item. I will admit that there are many files associated with this item, such as 1,000 (seriously). I am up to 967 files and now when I try to add the next file, Omeka refreshes to the Dublin Core page for the item and has the following error: " There was an error on the form. Please try again."
So, just to see what would happen, I went into php.ini and increased upload_max_filesize and max_file_uploads to extremely high limits. I also increased upload.maxFileSize in config.ini. Finally, just for extra measure, I gave file/ all read/write permissions. Despite these extreme adjustments, I continue to get the error.
What would be preventing me from adding additional files to an item? Does Omeka have a default file limit? Any help is appreciated.
There is probably a technical setting which is the issue here, but there’s also the fact that 1000 files isn’t really practical from a usability standpoint. Unless you have a very devoted user base, they’re not likely to want to sort through that many files. Is this something you can convert to a PDF, or split into multiple items combined into an item set?
Regarding the crazy volume of files: we have our Omeka set up a bit differently, where we are using the pagination plugin that allows users to browse individual pages (files) of an item. We also transcribe every page, so when a user searches for a name, it will take him or her to the exact page the name appears. Usually documents average 150 pages per item, but this one is our county’s naturalization records which happened to be closer to 1,000.
On a technical level, there are a handful of relevant PHP settings you might need to change here.
upload.maxFileSize in your omeka configuration can only lower the upload limit below what’s allowed by PHP itself. For most users, simply always leaving this setting unset or commented out is the best option.
upload_max_filesize and max_file_uploads only come into play for how many files you can add in a single request. If you’re mostly adding files one by one or in smaller batches, those settings aren’t really relevant. One thing to note, if you are adding many at once, you need to look at post_max_size as well: upload_max_filesize is the maximum size of any one file, but post_max_size is the total amount of data that can be sent at once. At a minimum, post_max_size needs to be as big as upload_max_filesize and possibly significantly bigger if you want to allow uploading lots of big files at once.
With all that being said, there’s a completely different setting that probably is more likely what you’re encountering: max_input_vars. This setting just sets how many total pieces of data can be sent in a single request. The default maximum is 1000. Each file that’s already loaded on an item ends up being one piece of data being sent back whenever the form is saved, to allow them to be reordered by the user. That data is very small, but up at 967 files, you’re pretty much guaranteed to be running into issues with the max_input_vars limit. My guess would be that increasing that PHP setting is what will fix this problem for you.
Thanks for the tips. I’ll play with the max_input_vars and see what happens. I will report back what I find for others. If this doesn’t work, I have a plan b, which is simply breaking the item into smaller parts – a bit kludgy, but gets the job done.
Following guidance from jflatnes, I increased max_input_vars in the php.ini file and that resolved the issue. I just wanted to post a follow-up so others may benefit.