Media Manager AJAX search is case-sensitive (fails on multilingual setups)

[kreossino]

I'm running the latest e107 Git repository on a LAMP server with Apache and PHP 8.4.
I noticed an issue with the Media Manager search (used via TinyMCE or the AJAX dialog). The search is strictly case-sensitive. For example, if I search for "orchidea" but the image title is "Orchidea", it returns "No results found". This is particularly problematic in multilingual setups.
I resolved the issue locally by modifying e107_admin/image.php. The problem is that the filtering logic uses strpos() instead of stripos().
For example, in imageTab2(), iconTab(), and similar functions, the code does:

if(strpos($v['title'], $option['search'])!==false)

I simply changed it to:
if(stripos($v['title'], $option['search'])!==false)

This makes the search case-insensitive and fixes the problem perfectly.
Could you please update the core to use stripos() for these search filters? It would be a great improvement for multilingual sites.
Thanks!

[cookesan]

Confirmed. The dialog carousel filtering in e107_admin/image.php is doing a case-sensitive PHP string check after building the media items.

I see strpos($v['title'], $option['search']) !== false in iconTab() and imageTab2(), and the same pattern with $parm['search'] in the audio/video/media tab filters. That means orchidea will not match a title of Orchidea at that final PHP filter step.

Changing those title filters to stripos() is the right direction for case-insensitive search. I would touch all of the equivalent dialog filters in that file, not only imageTab2(), so image/icon/audio/video search behavior stays consistent.

One small caveat: imageTab2() also passes the search term into e107::getMedia()->getImages(...), which builds a database LIKE search over media fields before the carousel filter runs. Depending on the database collation, that first pass may already be case-insensitive; the final strpos() pass can still remove otherwise valid matches. Replacing the final PHP-side checks with stripos() would fix the mismatch you are seeing.

[kreossino]

I have shared a proposed modification for this specific path issue. Could you please check if this fix can be integrated into the main repository branch?

[Deltik]

I think I'd accept a pull request that switches the check to use mb_stripos() instead so that UTF-8 strings would be supported as well.