Service provider is closing the support for PHP 7.4 by the end of this month. Omeka Classic is version 3.0.2 installed via Installatron.
When starting to use PHP 8.0 instead of 7.4 seems to be working fine except one big failure: when uploading a file (image) results in error (see picture). Tried with different file sizes and seems that error is caused when uploading has been finished and something is going to be done with it.
Backcround path info has been updated to point to the right version of PHP.
For a “white screen” 500 error, this usually means a fatal PHP error is occurring. If PHP is set up to log on your server (it usually is) then the PHP logs should contain the relevant error. Depending on your server setup, PHP’s logs might go to Apache’s error log, to a dedicated log file, or elsewhere.
As another option, you can enable error display which should replace the white screen with a listing of the error message.
You may be able to ask your host for help in finding PHP error logs on the server, if necessary.
Ok. This is the error output received when trying to save a record with a file (works well if no file uploaded).
Warning : is_readable(): open_basedir restriction in effect. File(/Ghost/Validate/Identical.php) is not within the allowed path(s): (/home/kinxuvyqpa/:/tmp/:/var/tmp/:/usr/local/php80/lib/:/usr/local/php54/lib/:/usr/local/php55/lib/:/usr/local/php56/lib/:/usr/local/php70/lib/:/usr/local/php71/lib/:/usr/local/php72/lib/:/usr/local/lib/php/) in /home/kinxuvyqpa/domains/punkmuseo.fi/public_html/arkisto/application/libraries/Zend/Loader.php on line 186
Warning : is_readable(): open_basedir restriction in effect. File(/Omeka/Validate/Identical.php) is not within the allowed path(s): (/home/kinxuvyqpa/:/tmp/:/var/tmp/:/usr/local/php80/lib/:/usr/local/php54/lib/:/usr/local/php55/lib/:/usr/local/php56/lib/:/usr/local/php70/lib/:/usr/local/php71/lib/:/usr/local/php72/lib/:/usr/local/lib/php/) in /home/kinxuvyqpa/domains/punkmuseo.fi/public_html/arkisto/application/libraries/Zend/Loader.php on line 186
Warning : is_readable(): open_basedir restriction in effect. File(/Ghost/Validate/NotEmpty.php) is not within the allowed path(s): (/home/kinxuvyqpa/:/tmp/:/var/tmp/:/usr/local/php80/lib/:/usr/local/php54/lib/:/usr/local/php55/lib/:/usr/local/php56/lib/:/usr/local/php70/lib/:/usr/local/php71/lib/:/usr/local/php72/lib/:/usr/local/lib/php/) in /home/kinxuvyqpa/domains/punkmuseo.fi/public_html/arkisto/application/libraries/Zend/Loader.php on line 186
Warning : is_readable(): open_basedir restriction in effect. File(/Omeka/Validate/NotEmpty.php) is not within the allowed path(s): (/home/kinxuvyqpa/:/tmp/:/var/tmp/:/usr/local/php80/lib/:/usr/local/php54/lib/:/usr/local/php55/lib/:/usr/local/php56/lib/:/usr/local/php70/lib/:/usr/local/php71/lib/:/usr/local/php72/lib/:/usr/local/lib/php/) in /home/kinxuvyqpa/domains/punkmuseo.fi/public_html/arkisto/application/libraries/Zend/Loader.php on line 186
The error here is that the function “escapeshellarg” is not defined. That’s a standard PHP function so I think you’re going to need to talk to your host about that. It’s possible they’ve disabled it purposely, but this isn’t quite the typical behavior when hosts disable functions.
We did install (via Installatron) Omeke on our service providers shared services (PHP 7.4)
We started to use this local installation, no problems
When we wanted to transfer data from omeka.net to our local installation (shared hosting), it did not work because escapeshellarg was disabled (I posted here about that in last June), and some other functions needed to transfer data via API
Our service provider provided us fresh machine, we being first one there and enabling all functions so we can transfer data via API
That went fine and then they disabled bunch of functions (and I expect that escapeshellarg too, cannot be sure about hat…)
And we continued to use Omeka normally…
And now when changing to PHP 8 things (=uploading files) does not work anymore…
So, escapeshellarg has been working with PHP 7.4 but not with 8. But not with API import. When thinking what we have done and how we have used Omeka, I’m wondering if service provider has really disabled this function for 7.4 at all (even this special arrangement with API transfer refers to that they have) but has done it now for 8.0.
OR, is it possible that there’s some changes with the utilities (imagick or some others) doing thumbnaisl etc. in PHP 8?
OR, is there any workarounds how to bypass this function, which is just adding single quotes… cannot it be done without that function?
Anyway, a bit confused here as everything is not logical, at least based on the information what we have…
Have asked about this from service provider too, lets see what kind of reply we’ll get from them…
OK, so I believe the change here is just that disabled_functions in PHP 8 acts differently, so it’s a “harsher” error than before. I’ll do some thinking about how to account for that, though our general guidance is to use hosting that doesn’t disable functions.
As for workarounds, you could try to comment out (put two slashes, // at the start of the line) the following lines:
line 311 of application/models/File.php
line 74 of application/libraries/Omeka/File/MimeType/Detect.php
Commenting those should remove the uses of escapeshellarg and similar functions from what’s run when uploading a file.
Thanks. We’ll try workarounds, if needed, when our service provider gets back to us about the situation as for the longer run, it is better to have as standard solution as possible. I’ll keep you updated too.
The Omeka Classic 3.1.1 release includes a fix to skip the specific calls here if the functions are disabled in PHP 8 and up. In the future it’s likely they’ll just be removed entirely.
Just upgraded Omeka to version 3.1. and turned into the same problem as mentioned at the start of this thread.
So, just checking, that should we comment out the same line numbers or have there been some changes in the code that line numbers to be commented out has changed? (Sorry, I could check that if doing roll-back but that takes too much time…).
Also, if looking to upgrade to 3.1.2., Installatron gives this warning:
REQUIREMENT
REQUIRED VALUE(S)
VALUE DETECTED
PHP functions
proc_open
Any workaround for that? (Installatron mentions that with 3.1.1. requirements are not filled but does not tell what requirements…).
The best way to fix the problem is just to update to version 3.1.1 or newer; if you’re on one of those versions, no changes or commenting out of lines is required. There’s no new or changed dependency on the proc_open function in 3.1.1 or higher, if Installatron is warning about that it represents just a change to Installatron and not Omeka. proc_open is used for running background jobs, and if you’re not using those having it disabled on your server isn’t an issue.
In answer to your question about the lines if you’re on exactly version 3.1 and not anything later, the lines to comment out are still the same in 3.1 as they were in 3.0.2.
Thanks!
Somehow Installatron won’t update to 3.1.1. but commenting out those two lines fixed this issue.
Ofcourse I realized that I haven’t saved all those other fixes/modifications (for sending emails etc.) but that’s the pain I have to pay for having too sort memory …
After upgrading to 3.1. (using fileDerivatives.strategy = “Omeka_File_Derivative_Strategy_GD”) we noticed that vertical mobile phone photos will be turned 90 degrees for all versions.
Setting fileDerivatives.strategyOptions.autoOrient = true (or commenting it out, as it was by default) does not affect the results.
Traditional scanned images works as should and previous version of Omeka (with GD) workded as should be with mobile phone images.
There’s no difference in 3.1’s GD thumbnailer vs. prior versions. It’s code that’s been the same for a very long time.
Could it be just that your newer photos are different? It’s not uncommon for photos from phones to be stored “landscape” even when the photo is taken vertically. Correcting for this is what the “auto-orient” option is for, but the GD strategy doesn’t support that option (and never has).
The example you gave looks fine to me. Is it an example of the problem, or an example from “before” the problem?
Strange, as this phone used to take those rotated pictures is old and source for few hundred pics archived into Omeka… we tried with one other phone, had no similar effect. Heh, the sample link I sent here was fixed by my colleague without notifying me so was not anymore good example…
Gotta try to evaluate this at some point but the phone used in this case won’t be a big problem so this is not critical in any way.
…