PHP Fatal error after file upload on V7 and V8 - SOLVED

📦 Install & Upgrade Help
,
1

Hi all, I am experiencing the same error with both SuiteCRM-7.12.4 and SuiteCRM-8.0.3 related to accessing uploaded files. The uploaded files are saved (e.g. for SuiteCRM V7 in …/suitecrm/uploads/), but they cannot be accessed after uploading. The simplest example is uploading a profile photo (800x944 JPG). After uploading, the image isn’t rendered in the profile page and there is a PHP Fatal error in httpd-error.log. I also uploaded a simple PDF using the Documents module with essentially the same PHP Fatal error. With the exception of these file upload issues, both V7 and V8 appear to be working correctly otherwise.

There are numerous topics in the forum reporting similar symptoms and reported solutions have been to either set file and directory permissions correctly (file not uploading at all), or to load the php fileinfo module (file mime type not recognised correctly). I set file ownership and permissions as per V7 (or V8) installation instructions (and even chmod -R 777 for testing), and fileinfo was already been enabled prior to installation (confirmed by phpinfo). I’m not proficient with MIME types and implications, but verified mime_module was enabled in httpd.conf, and also tried enabling mime_magic_module in httpd.conf with no effect.

I’m using Apache/2.4.52 with PHP 8.0.15 and MariaDb 10.5 but on FreeBSD 13.0 instead of Linux. However, the same server also hosts WordPress, Nextcloud, Mantis and WackoWiki, with no issues uploading files and accessing them afterwards.

I verifed by querying the database that the original filename for my profile picture was stored in my profile record in the database “users” table, but the filename of the stored file was renamed (“photo” field is “DaleS_Headshot-2021_tight-800x944.jpg” but file is “…/upload/1_photo”), and I haven’t been able to find an index table giving the relationship between the original filename and the stored filename.

Querying the database after uploading a PDF file using the “Documents” feature, I see the record in the “documents” table contains both the original filename (“document_name” field) and the stored filename (“document_revision_id” field).

Could my profile picture and uploaded PDF be seperate problems?

Fwiw, here is the PHP Fatal error that occurs after saving a profile picture (I presume when the page is rendered with the new image):

[Tue Mar 01 08:13:13.132076 2022] [php:error] [pid 49638] [client 174.0.43.39:45460] PHP Fatal error:  Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in /usr/local/www/SuiteCRM-7.12.4/download.php:267\nStack trace:\n#0 /usr/local/www/SuiteCRM-7.12.4/download.php(267): in_array()\n#1 /usr/local/www/SuiteCRM-7.12.4/include/MVC/Controller/SugarController.php(1017): require_once('...')\n#2 /usr/local/www/SuiteCRM-7.12.4/include/MVC/Controller/SugarController.php(465): SugarController->handleEntryPoint()\n#3 /usr/local/www/SuiteCRM-7.12.4/include/MVC/Controller/SugarController.php(361): SugarController->process()\n#4 /usr/local/www/SuiteCRM-7.12.4/include/MVC/SugarApplication.php(101): SugarController->execute()\n#5 /usr/local/www/SuiteCRM-7.12.4/index.php(52): SugarApplication->execute()\n#6 {main}\n  thrown in /usr/local/www/SuiteCRM-7.12.4/download.php on line 267, referer: https://suitecrm.dalescott.net/index.php?module=Users&action=DetailView&record=1
dale@whizzer:/usr/local/etc/php %

and this is the offending line 267 in download.php

if (in_array($row['file_ext'], $sugar_config['allowed_preview'], true)) {
    $showPreview = isset($_REQUEST['preview']) && $_REQUEST['preview'] === 'yes' && $mime_type !== 'text/html';
}

The PHP Fatal error accessing Documents after uploading PDF file:

[Tue Mar 01 11:29:51.595046 2022] [php:error] [pid 50591] [client 162.223.103.50:11593] PHP Fatal error:  Uncaught TypeError: in_array(): Argument #2 ($haystack) must be of type array, null given in /usr/local/www/SuiteCRM-7.12.4/modules/Documents/Document.php:269\nStack trace:\n#0 /usr/local/www/SuiteCRM-7.12.4/modules/Documents/Document.php(269): in_array()\n#1 /usr/local/www/SuiteCRM-7.12.4/modules/Documents/Document.php(227): Document->fill_in_additional_detail_fields()\n#2 /usr/local/www/SuiteCRM-7.12.4/data/SugarBean.php(6183): Document->fill_in_additional_list_fields()\n#3 /usr/local/www/SuiteCRM-7.12.4/include/ListView/ListViewData.php(435): SugarBean->loadFromRow()\n#4 /usr/local/www/SuiteCRM-7.12.4/include/ListView/ListViewDisplay.php(158): ListViewData->getListViewData()\n#5 /usr/local/www/SuiteCRM-7.12.4/include/MVC/View/views/view.list.php(283): ListViewDisplay->setup()\n#6 /usr/local/www/SuiteCRM-7.12.4/include/MVC/View/views/view.list.php(391): ViewList->listViewProcess()\n#7 /usr/local/www/SuiteCRM-7.12.4/include/MVC/View/SugarView.php(210): ViewList->display()\n#8 /usr/local/www/SuiteCRM-7.12.4/include/MVC/Controller/SugarController.php(432): SugarView->process()\n#9 /usr/local/www/SuiteCRM-7.12.4/include/MVC/Controller/SugarController.php(363): SugarController->processView()\n#10 /usr/local/www/SuiteCRM-7.12.4/include/MVC/SugarApplication.php(101): SugarController->execute()\n#11 /usr/local/www/SuiteCRM-7.12.4/index.php(52): SugarApplication->execute()\n#12 {main}\n  thrown in /usr/local/www/SuiteCRM-7.12.4/modules/Documents/Document.php on line 269, referer: https://suitecrm.dalescott.net/index.php?module=Users&action=EditView&record=1
dale@whizzer:~ %

And the offending line 269 from Document.php

if (in_array($row['file_ext'], $sugar_config['allowed_preview'])) {
    $this->show_preview = true;

Fwiw, the most relevent topics I found in the forum are:

Thanks in advance!

Cheers,
Dale

2

Hi Dale

This does look like it is potentially a new issue introduced in a recent release from what I can see, so I think it would be good to log this as a new issue on GitHub. But from reading the error you are getting a potential fix maybe to change line 267 in download.php to something like this

if (isset($row['file_ext'], $sugar_config['allowed_preview']) && in_array($row['file_ext'], $sugar_config['allowed_preview'], true)) {

1 Like
3

Thanks @Matt

I edited both …/downloads.php and …/Modules/Documents/Document.php for V7 using your suggestion ver batim and confirmed both reported symptoms were corrected (but did not test V8).

I also created an issue in the Github repo as you suggested: PHP Fatal error on V7 and V8 rendering page after file upload

How long would you expect an issue like this to take to be resolved and how? (for my own interest in understanding the SuiteCRM release cycle).

Cheers,
Dale

4

it looks like a pretty important issue on widely used functionality, which should be relevantly simple to fix , so i’d expect we will pick in up in out next maintenance release. It will likely be picked up by the internal team, as this look the origin or someone from the community may pick this up.

We like when possible so a maintenance release every month, but it can vary based on other releases. We just had an out of sequence security patch go out today and we are expecting Suite 8.1 to hit this month also, so could be busy one.

1 Like
5

Thanks! I will test your patch on V8 and if any issues comment to the issue report. Otherwise I’ll leave the patch in place and move on, and revert to a production release as soon as I see this issue is fixed.