There was an error on the form please try again when uploading jpg files

I am running Omkea 2.5 with WordPress 4.7.3 and PHP Version 5.5.38 The Scripto version 2.2 and Dropbox version 0.7.2 plugins are installed in Omeka.

Using the Dropbox plugin, about 900 jpg item files have been uploaded, and there are about another 100 that still need to be uploaded. The uploads are failing with this message:

There was an error on the form. Please try again.

The same error occurs every time I try again, regardless of which file is uploaded or how many files are uploaded. Please see below for information on how I tried to get error logs and for config.ini information. How can I troubleshoot this problem?

I followed the directions at this url to turn on error logging:
https://omeka.org/codex/Retrieving_Error_Messages

Neither method logged to this location - the error log is zero bytes:

/home/xxx/nsmlv.org/omeka/application/logs
-rwxrwxr-x 1 xxx pg8740520 0 Jan 30 17:13 errors.log

Here is the config.ini information:

/home/lan_t3rn/nsmlv.org/omeka/application/config

[bombur]$ cat config.ini
;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Site Configuration File ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Lower-level settings for Omeka are defined here.
;
; The default settings should be correct for most Omeka users, but some
; setups may require some changes. People who are developing for or
; debugging Omeka may also change some of these settings.

[site]

;;;;;;;;;;;;;;;;
; Localization ;
;;;;;;;;;;;;;;;;

; locale.name
; The locale identifier used for translating and displaying Omeka.
; default: none
;
; The locale controls what language Omeka will be displayed in, and
; also how dates and other locale-sensitive data will be displayed.
;
; The locale identifier should be a valid ISO 639 language code,
; and optionally a valid ISO 3166-1 locale code.
; (Examples: “es” for Spanish, “en_US” for US English.)
;
; To enable translations, the identifier must also have a
; corresponding .mo file in the application/languages directory.

locale.name = “”

;;;;;;;;;;;;;
; Debugging ;
;;;;;;;;;;;;;

; debug.exceptions
; Throw exceptions for bad URLs.
; default: false
;
; This should only be enabled when debugging or developing for Omeka.
debug.exceptions = false

; debug.request
; Dump data about each web request to the browser.
; default: false
;
; The request data shows what routes and variables Omeka has parsed from
; each request.
debug.request = false

; debug.profileDb
; Enable the query profiler.
; default: false
;
; This will show metadata about the queries that were executed during
; each request.
debug.profileDb = false

; debug.email
; Send all log messages to an email address.
; default: “”
;
; Anything that would be logged will also be emailed to this address.
; If left blank, this feature is disabled.
debug.email = “”

; debug.emailLogPriority
; Apply a priority filter to emailed log messages.
; default: Zend_Log::ERR
;
; If an address has been set for debug.email, this setting filters the
; messages to only those of the given priority or higher.
debug.emailLogPriority = Zend_Log::ERR

;;;;;;;;;;;
; Logging ;
;;;;;;;;;;;

; log.errors
; Log errors and other information.
; default: false
;
; Errors, exceptions, and other messages will be logged to
; application/logs/errors.log (this file must be writable by the web
; server if logging is enabled).
log.errors = true

; log.priority
; The minimum priority level of messages that should be logged.
; When developing/debugging, use Zend_Log::DEBUG for debug() to work. This will record everything.
; default: Zend_Log::WARN (Logs warnings and above)
log.priority = Zend_Log::WARN

; log.sql
; Log SQL statements.
; default: false
;
; All SQL statements executed by Omeka will be included in Omeka’s
; error log.
log.sql = false

;;;;;;;;;;;;
; Sessions ;
;;;;;;;;;;;;
;
; Omeka uses Zend Framework’s session handling. A full list of
; available session configuration options can be found here:
; http://framework.zend.com/manual/en/zend.session.global_session_management.html#zend.session.global_session_management.configuration_options
;
; Some options that are often useful for Omeka sites are included here.

; session.name
; Sets the name used for the Omeka session cookie.
; default: “”
;
; If left blank, Omeka will automatically select a unique session name.
session.name = “”

; session.saveHandler
; Determines how session data will be saved.
; default: no setting (uses the database for saving session data)
;
; Sessions are now stored in the database by default. To revert to the
; older method of storing session data in the filesystem, uncomment the
; following line.
; session.saveHandler = “”

;;;;;;;;;
; Theme ;
;;;;;;;;;

; theme.useInternalAssets
; Whether Omeka should use locally-stored asset files.
; default: false
;
; Omeka includes some asset files from external sources, such as Google by
; default. Set this to true if the Omeka installation does not have
; web access, and Omeka will instead serve local copies of these files.
theme.useInternalAssets = false

;;;;;;;;;;;;;;;;;;;;;;
; Background Scripts ;
;;;;;;;;;;;;;;;;;;;;;;

; background.php.path
; Path to PHP-CLI for running background processes.
; default: “”
;
; If left blank, Omeka will try to autodetect the right path. Set this
; to override the autodetected PHP path.
background.php.path = “”

; jobs.dispatcher
; How Omeka “jobs” will be executed.
; default: “Omeka_Job_Dispatcher_Adapter_Synchronous”
;
; Newer Omeka features and plugins use this setting to determine how
; long-running jobs will be run.
;
; The default setting should work for all installations, but may
; time out for longer jobs. On systems where the older PHP background
; processes worked, the BackgroundProcess adapter can be used instead
; of the Synchronous one.
jobs.dispatcher.default = "Omeka_Job_Dispatcher_Adapter_Synchronous"
jobs.dispatcher.longRunning = “Omeka_Job_Dispatcher_Adapter_BackgroundProcess”

;;;;;;;;
; Mail ;
;;;;;;;;
;
; For more info, see Zend Framework documentation on Zend_Mail:
; http://framework.zend.com/manual/en/zend.mail.html

; mail.transport.type
; The system Omeka will use to send email messages.
; default: “Sendmail”
;
; The default is to send mail using PHP’s built-in mail() function.
mail.transport.type = “Sendmail”

; Uncomment some of the following lines (and comment the above line)
; to switch to SMTP for sending mail through Omeka. Your configuration
; may not require all of the options listed.
;
; mail.transport.type = “Smtp”
; mail.transport.host = “”
; mail.transport.port = ### ; Port number, if applicable.
; mail.transport.name = “” ; Local client hostname, e.g. “localhost”
; mail.transport.auth = “login” ; For authentication, if required.
; mail.transport.username = “”
; mail.transport.password = “”
; mail.transport.ssl = “” ; For SSL support, set to “ssl” or “tls”

; Sample S3 cloud storage configuration
;
; The accessKeyId, secretAccessKey, and bucket options are all required.
; If the expiration option is set, files will be uploaded with “private”
; access, and Omeka will generate URLs that are only valid for a limited
; time. If the expiration option is missing or left commented out,
; uploaded files will always be publicly readable.
;
; storage.adapter = “Omeka_Storage_Adapter_ZendS3”
; storage.adapterOptions.accessKeyId =
; storage.adapterOptions.secretAccessKey =
; storage.adapterOptions.bucket =
; storage.adapterOptions.expiration = 10 ; URL expiration time (in minutes)
; storage.adapterOptions.endpoint = ; Custom S3 endpoint (optional)

;;;;;;;;;;;;
; Security ;
;;;;;;;;;;;;

; ssl
; Secure Socket Layer support for Omeka.
; default: none
;
; Ensure that your server is properly configured before enabling this
; setting. Choose one of the following:
;
; “logins”
; Force SSL for login forms and login form submissions.
;
; “sessions”
; Force SSL for all authenticated users to protect sessions. Includes
; login forms.
;
; “always”
; Force SSL on across the entire site.
;
; ssl = “always”

;;;;;;;;;;
; Upload ;
;;;;;;;;;;

; upload.maxFileSize
; Set the maximum file upload size.
; default: 10M
;
; Uncomment the following line to set the maximum file upload size. This
; configuration will not exceed the maximum beyond what is set in the
; ‘post_max_size’ or ‘upload_max_filesize’ core php.ini directives.
;
;upload.maxFileSize = “10M”

;;;;;;;;;;;;;;;;;;;;;
; Derivative Images ;
;;;;;;;;;;;;;;;;;;;;;

; fileDerivatives.strategy
; Controls what method Omeka uses to create derivative images.
; default: Omeka_File_Derivative_Strategy_ExternalImageMagick
;
; The built-in strategies are ExternalImageMagick (the old default), Imagick
; (requires PECL ext/imagick), and GD (generally installed by default with PHP,
; but handles fewer formats). Others can be added by plugins.
;
;fileDerivatives.strategy = “Omeka_File_Derivative_Strategy_ExternalImageMagick”

; fileDerivatives.strategyOptions
; Specific settings for the configured derivative strategy.
;
; Subkeys to this entry specify each option.
;
; fileDerivatives.strategyOptions.page = “0”
; fileDerivatives.strategyOptions.gravity = “center”
; fileDerivatives.strategyOptions.autoOrient = false

; fileDerivatives.typeWhitelist[]
; If set, Omeka will only attempt to create derivatives for files with the
; given MIME types.
;
; This entry can be specified multiple times, once for each type in the list.
;
;fileDerivatives.typeWhitelist[] = “image/jpeg”

; fileDerivatives.typeBlacklist[]
; If set, Omeka will not attempt to create derivatives for files with the
; given MIME types.
;
; Both this blacklist and the whitelist can be set at the same time, but the
; whitelist will control.
;
; This entry can be specified multiple times, once for each type in the list.
;
;fileDerivatives.typeBlacklist[] = “image/jpeg”

So it worked for the first 900, but now doesn’t?

Is this error happening in an item-specific page (the add or edit Item form), or in the Dropbox’s own pages (where you can have it create many items at once)?

Hi - it happens on the add or edit item page.

The error you’re getting sounds like one that can happen when Omeka’s CSRF protection detects a problem. Basically, Omeka embeds a random string in the item form and checks to see if the value is there and correct when you submit it (this prevents a certain class of security problem).

When we don’t find that value or it doesn’t match, you get that error message. I can’t think of a particular way this would match up with Dropbox, though. Do “regular” uploads from the files tab work? Do updates that don’t try to do anything with files at all work?

Hi - I recreated the item as 3 smaller items and now files will upload via the dropbox plugin or the “regular” upload method. Until this was done, neither method successfully added files. Having 3 smaller items is not an ideal solution from an organizational view, but it seems to work.

Thanks

Ah okay, I believe I know what’s happening.

You had all 900 files on one big item?

The usual situation where we sometimes see requests mysteriously fail like this is when the size (in bytes) of the request sent to the server is too big, exceeding the PHP post_max_size setting. This generally only comes up with big file uploads, and not with something like the Dropbox which isn’t actually “uploading.”

You’re hitting a different, less-often-seen problem, but a similar one. PHP also has a setting limiting how many variables can be submitted by one form all at once: max_input_vars. The default on this setting is 1000. Each file on an item adds one extra variable (to allow you to reorder them), so you probably got yourself right up against the limit and now anything new is just one too many and PHP starts truncating what gets sent with the form.

You can change that setting to something higher like 1500 or 2000, either in php.ini if you control it, or otherwise you can try setting it in your .htaccess:

php_value max_input_vars 2000

It might also just make sense to consider a structure where you don’t need so many files on a single Item, but I don’t know what your specific use case is.

Hi John -

Thank you for your help. That seems to fix the problem, but we will consider your comment regarding the the structure.

Thanks again!