Additional Images: Pregnant match, unknown modifier on Line 47

[Feznizzle]

[zc154, running Responsive Sheffield Blue template]

Hi,

I'm getting a huge number of log files complaining about a pregnant match:
[06-Apr-2017 10:35:37 America/New_York] PHP Warning: preg_match(): Unknown modifier 'T' in /public_html/includes/modules/responsive_sheffield_blue/additional_images.php on line 47

Here is the passage where the preg match occurs (I have bolded out line 47):

// Check for additional matching images
$file_extension = $products_image_extension;
$products_image_match_array = array();
if ($dir = @dir($products_image_directory)) {
while ($file = $dir->read()) {
if (!is_dir($products_image_directory . $file)) {
if (substr($file, strrpos($file, '.')) == $file_extension) {
if(preg_match('/\Q' . $products_image_base . '\E/i', $file) == 1) {
if ($file != $products_image) {
if ($products_image_base . str_replace($products_image_base, '', $file) == $file) {
// echo 'I AM A MATCH ' . $file . '<br>';
$images_array[] = $file;
} else {
// echo 'I AM NOT A MATCH ' . $file . '<br>';
}
}
}
}
}
}
if (sizeof($images_array)) {
sort($images_array);
}
$dir->close();
}
}

I think this is either a Zen Lightbox or Image Handler issue. Or maybe a Tabbed Product Pro issue? I dunno.

Any thoughts on how to fix this?

Thanks,
Mike

[mc12345678]

Any indication of what images are possibly involved? What filenames are being used? IH4 doesn't appear to modify anything at or before that point for basic image display/data collection.

The current code at that line doesn't appear to have anything in it that would result in that message other than what is introduced in: $products_image_base. That appears to be generated from the main image's name in a default install and it appears that there is something in the filename (even if it is some hidden character) that is being interpreted and a problem.

[DrByte]

Yes. Since the '/' is your delimiter in the preg_match call, if you have a '/' in the filename passed, then it's gonna complain.

"Unknown modifier T" means your $products_image_base contains "/T" in it.

[Feznizzle]

Thank you for the input, sorry for the delayed response. I got sidetracked but I'm back on it.

Whatever this is, it's triggering a massively prolific error logs. Numerous times a time, often the individual log files are huge (601kb).

Are you guys saying that this problem may exist inside the database itself? Like, the name of an image that has been inserted into a table?

[mc12345678]

Thank you for the input, sorry for the delayed response. I got sidetracked but I'm back on it.

Whatever this is, it's triggering a massively prolific error logs. Numerous times a time, often the individual log files are huge (601kb).

Are you guys saying that this problem may exist inside the database itself? Like, the name of an image that has been inserted into a table?

Yup, that's what we're saying, though DrB knew more about the actual content that is causing the issue, "/T" which would be related to the filename. That said, a "better" fix than tryng to find/change the filename is to change the regex delimiter to something not permitted (or not likely to exist) in a filename/folder structure but still would work for regex.

That would involve editing the if preg_match line.

[DrByte]

Since '/' is being used as the delimiter,

if(preg_match('/\Q' . $products_image_base . '\E/i', $file) == 1) {

would be better written as:

if(preg_match('/\Q' . preg_quote($products_image_base, '/') . '\E/i', $file) == 1) {

[Feznizzle]

Thanks, DrByte. I'll give that a go...

[Feznizzle]

I am unable to trigger an error, but I'm not sure that means the issue has cleared up. I was unable to trigger it myself, even before the fix I just applied.

Man, I wish the error log would provide the url where the problem occured, not just what file and what line of the file triggered the error.

I have cleaned out the log folder, will watch it for future occurrences.

On a weird note, I'm become paranoid that some nefarious is afoot. I swear site traffic is getting hijacked or something! And this problem... it seemed to solve itself this morning!

[lat9]

I am unable to trigger an error, but I'm not sure that means the issue has cleared up. I was unable to trigger it myself, even before the fix I just applied.

Man, I wish the error log would provide the url where the problem occured, not just what file and what line of the file triggered the error.

I have cleaned out the log folder, will watch it for future occurrences.

On a weird note, I'm become paranoid that some nefarious is afoot. I swear site traffic is getting hijacked or something! And this problem... it seemed to solve itself this morning!

Since you're using Zen Cart 1.5.4, you could install the myDEBUG Backtrace plugin, which has been incorporated into the ZC 1.5.5+ code base.

[Feznizzle]

Sweeeeet! Thank you so much! I will install that right away!