Errors uploading media files on pre-existing items

Omeka S Installing
1

I am trying to install Omeka S on Hostinger’s shared host platform. While the installation mostly seems to work, I am not able to upload media files on pre-existing items. As I am able to upload asset files and media files when I am first creating an item, and enabling logging does not provide any additional information, I am at a loss.

I had this same difficulty with a previous version (Omeka S 4.1.1?) and updating it to Omeka S 4.2.0 did not resolve the issue. Furthermore, I have also tried again on a different account with a fresh installation of Omeka S but also had the same issue.

I would appreciate suggestions on next steps for debugging. Thanks.

Steps to Reproduce:

  1. Create a new subdomain and database in Hostinger’s hPanel.
  2. Download Omeka S (on host shell using wget).
  3. Expand the ZIP archive.
  4. Copy the contents (including .htaccess) to the public_html directory for the subdomain.
  5. Complete setup.
  6. Create an item.
  7. Upload a media using either file upload or URL.
  8. Activate Save button.

What Happens:

  • The media file is not uploaded.
  • White page with the content “Forbidden”.
  • Browser console reports a 403 response to the POST request (e.g. /admin/item/1/edit).

What is Expected:

  • Media file is uploaded and attached to the item.

Notes:

  1. Uploading asset files works.
  2. Uploading a media file when initially creating an item works.
  3. I seem to have met the installation requirements. (Listed below)
  4. Changing the thumbnailer to Omeka\File\Thumbnailer\Gd or Omeka\File\Thumbnailer\NoThumbnail does not resolve the issue. (While the imagick PHP extension seems to be installed, it appears that ImageMagick is not. In any case, Gd and NoThumbnail seem to work as expected when uploading the media file while initially creating the item, so this would not seem to be an issue.)
  5. Disabling mod_security according to Hostinger’s directions does not resolve the issue. (Adding SecFilterEngine Off and SecFilterScanPOST Off to .htaccess. Could they, since writing that article, have changed how they configured mod_security?)
  6. setting APPLICATION_ENV or enabling application logging does not provide additional information.
  7. Disable file validation does not resolve the issue.
Requirement From System information
Linux OS Version: Linux 4.18.0-553.62.1.lve.el8.x86_64 x86_64
Apache (with AllowOverride set to “All” and mod_rewrite enabled) (The supplied .htaccess contains rewrite rules, and renaming it disables routing entirely. Restoring it restores Omeka S functionality.)
MySQL, minimum version 5.7.9 (or MariaDB, minimum version 10.2.6) Server Version: 11.8.3-MariaDB-log
PHP, minimum version 8.1, with PDO, pdo_mysql, and xml extensions installed. Version: 8.3.24
Extensions: bcmath, bz2, calendar, Core, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, igbinary, imagick, imap, intl, json, libxml, litespeed, mbstring, memcached, msgpack, mysqli, mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, random, readline, redis, Reflection, session, shmop, SimpleXML, soap, sockets, SPL, sqlite3, standard, sysvmsg, sysvsem, sysvshm, tidy, timezonedb, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend OPcache, zip, zlib
Disabled Functions: apache_child_terminate, chgrp, dl, exec, ini_alter, leak, link, mb_send_mail, mysql_list_dbs, passthru, popen, shell_exec, symlink, system, virtual
ImageMagick version 6.7.5 or greater, the PHP imagick extension, or the PHP gd extension gd extension is installed
2

A white “Forbidden” screen does suggest something like mod_security or something similar from the host heuristically blocking the request. You might be able to check Apache logs for a clue, if you have access to them.