Fatal Error On Processing Photos

We have started getting The following Fatal errors. when processing files that have been uploaded by ftp and then using the Upload photos > Select From FTP Upload. When we tell it to process the uploaded photos we get the warning screen to not move from the page and the process creates the directory but then errors out with the error shown below.

I have been unable to track down the issue though it is occurring in the handling of the .png files.

Example error thrown from the error log:

[07-Dec-2023 21:26:22 America/Chicago] PHP Fatal error:  Uncaught TypeError: imagesx(): Argument #1 ($image) must be of type GdImage, bool given in /home/degruyph/public_html/sy-admin/photo.process.functions.php:360
Stack trace:
#0 /home/degruyph/public_html/sy-admin/photo.process.functions.php(360): imagesx()
#1 /home/degruyph/public_html/sy-admin/photo.process.functions.php(589): ResizeImagePng()
#2 /home/degruyph/public_html/sy-admin/process-ftp-upload.php(241): processPhoto()
#3 {main}
  thrown in /home/degruyph/public_html/sy-admin/photo.process.functions.php on line 360

Site is using PHP 8.1
Photos are .png photos about 1 meg in size
Processing to S3 is standard but we have tried not processing to S3 with the same result
Makes the folder but does not upload photos to the folder and errors out
Photo files are standard 644 permissions
Directory permissions are standard 755
No site modifications or host modifications have been done.

For some reason they are failing to upload. Either 1) you are out of space on your hosting, or close to it or 2) The files are too large either file size or dimensions.

Check the available space (and file count) with your host and also try to upload a smaller version and see if it uploads.

I do not think it is the hosting, or filling up the site, and I don't think it is the file size or dimensions. The photos vary some in size but are usually around 1500 pixels in the long dimension and no more than about 1 meg in file size.

The FTP process to upload to the sy-upload directory works fine with all files to be uploaded getting uploaded to the directory without error.

All images reside on Amazon S3 after processing and not the site so very little is contained on the site as you can see.  Turning off the S3 upload and eliminating S3 from the equation does not resolve the issue.

This is the average the sytist site uses while uploading/processing files from the server:
Disk Usage 2.65 GB / 50 GB (5.3%)
File Usage 21,903 / 1,000,000 (2.19%)
Entry Processes 1 / 50 (2%)
Physical Memory Usage 71.22 MB / 4 GB (1.74%)
Number of Processes 3 / 200 (1.5%)
CPU Usage 1 / 100 (1%)
MySQL® Disk Usage 114.68 MB / 47.46 GB (0.24%)
PostgreSQL Disk Usage 0 bytes / 47.35 GB (0%)
Bandwidth 14.6 GB / ?
FTP no quota

This is what resides on Amazon S3 as to files.
Amazon S3
Total Storage 384.0 GB
Object Count 835.3 k
Average object size 482.1 KB

Amazon is not showing any errors.  

The error message as I read it is saying imagesx() has a type error due to an unexpected Bool value getting inserted in Argument #1 ($image) which errors out the gdimage processor as it is expecting a file to process.

PhilD
 

Have you tried rolling your PHP back to 8.0 or 7.4? Any spaces or special character in your image file name? Are you hosting on BlueHost?

We are hosting on MDD Hosting which I have used for many years for all our websites. All my websites I manage are on 8.1 or 8.2

The sytist website has been on 8.1 since install and we have uploaded over 170495 photos which reside on S3 since we started the site in August and generally have no issues with the website other than our misunderstanding at one point of how to upload and create galleries.

Once we figured it out, we have been using the FTP upload then process the upload method as it is actually faster for our workflow.

I asked (my wife the pro) about filenames and was told that it can occur on any file name and there was apparently no specific file name there that causes it. 

I was planning on asking the support contact at the hosting company if they could look into their logs and see if there was an issue with gdimage processing or something else they could see  in case the processing was spiking something I cannot see from my logs. 

not sure what version of sytist you are using. If on a slightly older version it does not work with PHP 8.1

We are currently running Sytist Version 4.6.1 and will be updating soon to the latest version of 4.7.3 I was waiting to see if any issues were reported from the latest version before applying the update.

According to the release notes Sytist has been compatible with 8.0 and up to 8.1 since

4.1.0 May 3, 2022

NOTICE!: If you are self-hosting Sytist this update makes it no longer compatible with PHP 5 (the programming language). You are most likely not using PHP 5 unless you are specifically using it for something else. You can check with your host about what PHP version you are using if you are not sure.

• Now compatible with PHP 8, up to 8.1. (This is the program language running on the server)

I might have discovered a configuration issue earlier today, but I will need to do some more uploads tomorrow to see if that takes care of the issue. I'm also going to check with the hosting service if they see any issues in their logs.

The Sytist error log currently shows no fatal errors and no errors in general for today as of a few minutes ago. The good news is uploads have been going along okay all day I am told.

If none of that resolves your issue, I can look into it next week to troubleshoot the server (Sytist is not causing this issue).

Also PHP needs to be 8.1, not 8.2.

Hi Tim. The PHP version is 8.1

 I should have plenty of room. Here are the values copied from the "View Server Configurations" link

Additional php values not shown above are:

Memory Limit 1G

max_execution_time  600 seconds

max_input_time  600 seconds

max_input_vars  1000 

I discovered the .htaccess file was (re?)setting the values to 30M and setting some short 20 second execution times and so I changed those to match what you see above. I have additional testing to do to see if that is the fix.

If you have a specific question on the setup, I can probably get the answer if I don't already know it.

I don't wish to have anyone think I am blaming Sytist for any of this, as I don't believe I could have upload over 175914 photos successfully if the code did not work. I made the post because I could not figure out why this issue was occurring (and apparently had been occurring for several months) and if it was a bug that was uncovered or something on the domain or hosting someone could point to that I could fix or have fixed. 

I have removed some files from public_html directory that I don't think should be there but were placed there automatically by c-panel during an edit of php values. The c-panel provides several ways to select version, edit or adjust php settings for a site and the various methods can create potentially conflicting php directives by possibly automatically generating and placing an htaccess file, and/or a user ini file, and/or a php ini file all containing the php adjustable settings in the public_html directory as well as allowing editing of the sites php extensions and options directly. If you use one method one time and a different method another time, then you apparently can end up with multiple directive files which potentially could have different value settings. Last one parsed gets to do the settings. These same files will also potentially give you different session path settings. I get why it is this way in c-panel, but not sure it eliminates any customer issues for the hosting service.

I don't know if removing the unneeded files is the solution all together but yesterday I set all the different directives in all 3 files I found in public_html to the same values and quit having fatal errors. I have today disabled the 'extra' files and I will see if the issue reoccurs.

Good news.

We uploaded over 5500 files yesterday with no errors recorded in the Sytist error log since December 7th the day before I made the changes below.

For others following or for reference this is what I did.

• Eliminated common possible causes such as file names, domain space limits, file/directory/ownership permissions, accidental program changes in image sizes
• I discovered multiple php settings files had been created in public_html. The 3 files had some same and some differing values between files when compared. This was caused by using different methods in c-panel to adjust the php settings. Always use the same method!
• Before deleting any of the above files, I renamed them and ran the site for a day to make sure there were no issues. 
• Deleted the files that were unneeded
• As the fatal error issue did not seem time based, or amount of files processed based, I think this may explain why things would work fine for awhile and randomly quit processing uploaded files and start throwing fatal errors.

I think the potential then exists when there are multiple settings files as all the settings files that were found are valid as far as php is concerned. If they contain different values it may lead to an issue. [Edit: The settings files also contained differing session paths which could have been the issue.]

Glad you got it working.

@Phil DeGruy Thank you for your follow up post(s). 

You are most welcome. I always hate when you never find out if someone ever fixed an issue or how they worked it out.