I’ve seen a few similar topics here, but no resolutions. I have a fresh Omeka S installation with CSV import and FileSideLoad. When In pull in a tiny CSV for testing I get an error of
Omeka\Mvc\Exception\RuntimeException: POST request exceeded maximum size in /home/<mysite>/public_html/application/src/Mvc/MvcListeners.php:368
My POST_SIZE_LIMIT is 1000M and the file size is a few k.
If I comment out the error and try again I get new errors indicating that $request->getPost() gets NULL.
I can use sideload to create individual files, I get this failure on batch ingest only.
What versions of Omeka S, CSV import, and Sideload are you using?
Omeka S 1.11
CSV Import version 1.1.0
File Sideload version 1.0.1
Can you post your System Information screen? Either a screenshot or copy-pasting the text? It’s accessible from the footer of every admin page.
We did fix an issue related to the POST maximum size error message in the latest release of Omeka S, but I’m not sure it’s the problem you’re having.
In debugging the call it seems the $_POST variable was not created or populated. Dumping the value returns an empty string.
An empty or nonexistent POST is what PHP does when it thinks you’ve exceeded the size limit… but could also just be caused by nothing actually being submitted. Updating to Omeka S 1.2.0 should eliminate this misleading error if it’s actually an empty POST being submitted.
Can you upload individual files normally (that is, not using File Sideload)?
There’s one more thing you could post as well that might help: the contents of your .htaccess file.
I have no issues with anything other than the batch jobs - files ingest properly, and FileSideLoad works well. The .htaccess is as follows -
# SetEnv requires mod_env which is not installed on the production server
# SetEnv APPLICATION_ENV "production"
RewriteEngine On
# The following rule tells Apache that if the requested filename
# exists, simply serve it.
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [L]
# Strip any trailing slashes from incoming requests
RewriteCond %{REQUEST_URI} ^(.+)/+$
RewriteRule .* %1 [R=307,L]
# The following rewrites all other queries to index.php. The
# condition ensures that if you are using Apache aliases to do
# mass virtual hosting, the base path will be prepended to
# allow proper resolution of the index.php file; it will work
# in non-aliased environments as well, providing a safe, one-size
# fits all solution.
RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
RewriteRule ^(.*) - [E=BASE:%1]
RewriteRule ^(.*)$ %{ENV:BASE}/index.php [L]
# Block access to all .ini files.
<FilesMatch "\.ini$">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order Allow,Deny
Deny from all
</IfModule>
</FilesMatch>
# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php71” package as the default “PHP” programming language.
<IfModule mime_module>
AddType application/x-httpd-ea-php71 .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit
# BEGIN cPanel-generated php ini directives, do not edit
# Manual editing of this file may result in unexpected behavior.
# To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor)
# For more information, read our documentation (https://go.cpanel.net/EA4ModifyINI)
<IfModule php7_module>
php_flag display_errors On
php_value max_execution_time 120
php_value max_input_time 120
php_value max_input_vars 1000
php_value memory_limit -1
php_value post_max_size 1000M
php_value session.gc_maxlifetime 1440
php_value session.save_path "/var/cpanel/php/sessions/ea-php70"
php_value upload_max_filesize 1000M
php_flag zlib.output_compression Off
</IfModule>
# END cPanel-generated php ini directives, do not edit
Hmmm… I recalled a previous issue that could hit users using an out-of-date version of the .htaccess file, but yours looks fine to me.
It may be worth updating to Omeka S 1.2.0 to see if that resolves your issue, as it does contain a variety of fixes. Plus it’s just generally a good idea.
From what you’ve described, it seems as if the POST data is simply being discarded somewhere before Omeka gets to it. Is the behavior the same if you use a different browser?
Different browser, different user, same results. We’ll update the Omeka as soon as possible.
Updated to the latest, still getting the POST exceeded message, just a different line number
Huh… if you’re still getting the error message about the size being exceeded then it really does sound like PHP on your server is throwing away the POST data for some reason.
Does your host have a PHP log configured? (Not the Omeka error log, but a log that will include all errors or warnings from PHP? When PHP tosses out a request like that it should log it along with the reason, as long as a log is configured. If you yourself have control over the php.ini, you can point the error_log directive at a writable file somewhere.
I do have the error log, and its not showing anything unusual. I have this problem on two different servers now (both CPanel driven). There are no missing PHP packages (I compared all installed packages on my dev box with the staging server). I’m at a loss.
Interestingly, one instance on the staging server was working until we upgraded PHP to 7.2 (from 5.6). It stopped working then, and still failed when we rolled back to the earlier configuration.
It took some doing, but it turned out in the end to be a CPanel problem. I was able to get it to work on all instances by pointing the php-cli path explicitly in the configs.
'cli' => [
'phpcli_path' => '/opt/cpanel/ea-php71/root/usr/bin/php',
],
Works perfectly now.
