file list in media manager not loaded if empty bitmap image exists

[o-joomla-issues]

Steps to reproduce the issue

Upload empty bitmap image (bmp,gif,jpg,jpeg,png)
(or on console: touch test.png)

Expected result

File list with all existing images

Actual result

Empty file list, no files are shown, not even non-zero files
URL changes to include folder name
Folder in left column folder is not highligted as "current"

System information (as much as possible)

Joomla! ‎5.0.3
PHP 8.3.4 as fpm-fcgi on nginx

Additional comments

Happens with empty bmp,gif,jpg,jpeg,png files but not with ico,pdf,svg
File list shows properly if you remove the empty images or rename them top non-image file extension

[dgrammatiko]

Happens with empty bmp,gif,jpg,jpeg,png files but not with ico,pdf,svg

It's expected (code wise). The mime of the image files are checked through PHP functions which will obviously fail for an empty image:

joomla-cms/libraries/src/Helper/MediaHelper.php

Lines 86 to 125 in 45adb61

	public static function getMimeType($file, $isImage = false)
	{
	// If we can't detect anything mime is false
	$mime = false;
	try {
	if ($isImage && \function_exists('exif_imagetype')) {
	$mime = image_type_to_mime_type(exif_imagetype($file));
	} elseif ($isImage && \function_exists('getimagesize')) {
	$imagesize = getimagesize($file);
	$mime = $imagesize['mime'] ?? false;
	} elseif (\function_exists('mime_content_type')) {
	// We have mime magic.
	$mime = mime_content_type($file);
	} elseif (\function_exists('finfo_open')) {
	// We have fileinfo
	$finfo = finfo_open(FILEINFO_MIME_TYPE);
	$mime = finfo_file($finfo, $file);
	finfo_close($finfo);
	}
	} catch (\Exception $e) {
	// If we have any kind of error here => false;
	return false;
	}
	// If we can't detect the mime try it again
	if ($mime === 'application/octet-stream' && $isImage === true) {
	$mime = static::getMimeType($file, false);
	}
	if (
	($mime === 'application/octet-stream' || $mime === 'image/svg' || $mime === 'image/svg+xml')
	&& !$isImage && strtolower(pathinfo($file, PATHINFO_EXTENSION)) === 'svg' && self::isValidSvg($file, false)
	) {
	return 'image/svg+xml';
	}
	// We have a mime here
	return $mime;
	}

FWIW I had proposed a safer, faster alternative some time ago...

[Kubik-Rubik]

Such broken image files should be appropriately caught and displayed with a corresponding icon:

Please try to set the error level to None in the global settings and load the Media Manager again.

[o-joomla-issues]

With error reporting set to none the folder contents is displayed as expected. I can see the above image.
With error reporting set to standard the initial issue shows up.

Additional info: browser console shows:
VM201:1 Uncaught SyntaxError: Unexpected token '<', "

"... is not valid JSON
at JSON.parse ()
at onSuccess (media-manager.min.js?3c55e4:1:84574)
at i.onreadystatechange (core.min.js?83f2c9:1:6174)
onSuccess @ media-manager.min.js?3c55e4:1
i.onreadystatechange @ core.min.js?83f2c9:1
XMLHttpRequest.send (async)
s @ core.min.js?83f2c9:1
r.request @ core.min.js?83f2c9:1
(anonymous) @ media-manager.min.js?3c55e4:1
getContents @ media-manager.min.js?3c55e4:1
getContents @ media-manager.min.js?3c55e4:5
(anonymous) @ media-manager.min.js?3c55e4:5
Store.dispatch @ media-manager.min.js?3c55e4:5
Store.dispatch @ media-manager.min.js?3c55e4:5
navigateTo @ media-manager.min.js?3c55e4:1
onItemClick @ media-manager.min.js?3c55e4:1
(anonymous) @ media-manager.min.js?3c55e4:1
(anonymous) @ media-manager.min.js?3c55e4:1
callWithErrorHandling @ media-manager.min.js?3c55e4:1
callWithAsyncErrorHandling @ media-manager.min.js?3c55e4:1
n @ media-manager.min.js?3c55e4:1

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43279.}

[o-joomla-issues]

With error reporting set to simple the folder contents is displayed as expected also.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/43279.}

[Kubik-Rubik]

Yes, this is expected behaviour in this case. If PHP writes errors, notices or warnings into the output, the JSON response is no longer valid, and the Media Manager cannot process the response correctly. So, this is the symptom of the issue but not the source.

We should ensure that built-in PHP calls to retrieve image information do not create such errors because a 0-byte image is processed like a valid one.

I solved it years ago in my extensions by checking for the file size first before running any further calls on the file. We could also apply the same logic to the local adapter for the Media Manager.

[richard67]

We could also apply the same logic to the local adapter for the Media Manager.

I think that should be done, and as it’s a bug fix it should be done for the 4.4-dev branch if the issue happens also with 4.4.x. It will later be merged up into 5.1-dev by release managers.