Possible conflict between security advisory updates and plupload - Can not upload files anymore

This is most likely due to the fact that the previous versions were not respecting the file extension settings.

Please review your settings here:

/admin/config/media/file-settings

and here:

/admin/structure/file-types

Hi Joseph,

thank you for the reply. I am not sure what to look for.

To me, the settings look OK.

E.g. at Media -> File settings I have "default allowed file extensions" for the file types I am trying to upload ("jpg jpeg gif png…").

At Structure -> File types, the MIME type for images is "image/*".

Can't find something that appears to be wrong or missing.

At Media -> File settings there is a setting for a "File Upload Wizard" with an option to "Skip filetype selection". I checked this setting and saved, but the behaviour did not change.

What version of D7 are you running?
7.99?

My build is pretty much up-to-date with the latest D7 7.99 , file_entity, latest
maybe there's something else going on. Not sure

Yes, Drupal 7.99 & file_entity 7.x-2.38

Since no other reports are coming in since the last file_entity release, it is most likely an exotic interaction between the modules I am using.

However, the only updates I installed since November 2023 are file_entity and Drupal 7.99.

I can upload files just fine with the latest update, but this issue is kinda scary. We're delaying the update on prod with the hope it can get figured out so we don't run into a potential "exotic" issue we haven't tested.

I just searched my codebase and database for the string, "The image file is invalid or the image type is not allowed," but could not find it.

Which module produces this exact error string (I assume that's the place to set a breakpoint to debug)?

Related to file uploads, I am running the following modules from contrib: file_entity, filefield_paths, filefield_sources, filefield_sources_plupload, and plupload. Except file_entity, nothing of this has been updated recently.

If the error message string is in the Drupal 7.99 codebase, this could point to an issue with Drupal core since it was updated recently, but only in combination with one of the other modules. However, in the D7 issue queue I can not find anything reported recently about newly introduced issues with file uploads.

In my error log (/admin/reports/dblog), no errors are recorded, just a PHP notice from advanced_forum module about an "undefined property" (most likely unrelated).

I am out of ideas where to look for any pointers :-(

Ideally, you'd place a breakpoint in file.inc on a local instance and go through the backtrace to find where the failure occurs. Are you able to do that?

@darkodev: Unfortunately I have no usable dev experience, so this would not be very targeted.

But I have good news for 'file_entity' as far as this issue is concerned - I can disable and uninstall the module, but the problem remains. It seems to be a freak coincidence that this problem occured with the 'file_entity' 7.x-2.38 upgrade.

Even more bizarre, on another D7 site (also without 'file_entity') the issue does not show up, so it might not even be related to the Drupal 7.99 upgrade. That means the issue appears to have developed without any module upgrades or configuration changes. WTF.

@asb, have you tried restarting the PHP service on your production server?

Perhaps the old code is cached, sometimes if using APCu caching or other types of code caching there's need to restart the services after upgrading modules and code.

Are you still having an issue with this?

I restarted the Apache webserver and made a 'drush cc all'. Theoretically other caching layers could still interfere (varnish, apc), and the server has currently 2002 days uptime.

However, since 'darkodev' found the string from the error message in Drupal core and nobody reports issues with 'file_entity', I guess that D7 7.99 introduced some kind of regression. Would not be the first time, and that's one of the reasons why most of my sites still run on D6 - rock solid and fast.

@asb

2002 days uptime is rediculous, I'd say it's possibly time for a reboot.

There are kernel bugs in Linux that can affect certain models of CPUs after more than 4 years of uptime.

With that said, you should also restart the php services , apcu, memcache, redis, anything relating to PHP. Restarting apache is not going to fix that.

ha! reboot that sucker!

I have more or less the same setup and exactly the same problem.
file_entity, filefield_paths, filefield_sources, filefield_sources_plupload, and plupload.
All my modules and core are up to date.

I did some testing
Standard file upload works.
Uploading with Plupload widget does not work and gives the error.
Same problem with jpg and png files.

hmm, ok there could have been a conflict introduced between the security advisory updates for file_entity and plupload .

Is there any javascript errors in your browser console related to this upload?

Disable your js aggregation to get the origin of the errors.

@vedeem, if you can figure this out I'll review what you come up with

FWIW i've ran into this on a site that upgraded File Entity to 7.x-2.38 and core 7.99 at the same time. I went through and saved all of the file type definitions again, and the media settings, but it made no difference.

In file_validate(), before it gets to file_validate_is_image(), there were three validators defined:

• file_validate_size
• file_validate_extensions
• file_validate_is_image

The error seems to happen when it gets to file_validate_is_image() as $file->url points to a temporary path, e.g.:

$file (stdClass)
    uid = "1"
    filename = "myfile.jpg"
    uri = "temporary://something.tmp"
    filemime = "mage/jpg"
    filesize = false
    timestamp = (int) 1712143164
    status = (int) 1

The thing is that the file has already been saved, so it's not clear why it's executing this again.

FWIW on this site we have File Entity, plupload and filefield_sources, along with filefield_sources_plupload. What seems to happen is that filefield_sources_plupload_element_value() runs on the file, it saves the file, but then ends up running _form_validate() after it has already saved the file, which is too late.

#3414082-7: Possible conflict between security advisory updates and plupload - Can not upload files anymore →

Tested with 7.99 and latest file_entity and file uploads are working for us.

hmm, looking at DamienMcKennas description of the validation executing at the wrong spot, I'd appreciate any assistance with this.

I've confirmed that the problem doesn't exist with 7.98, i.e. a change in 7.99 causes the problem.

Correct status.

The problem seems to have started from 🐛 Users are able to upload 0-byte images Fixed where the file_validate_is_image() validator is added for all image uploads.

A part of the problem seems to come from multiple modules running file_validate().

Still working on digging through it. I suspect a change could be made to plupload or filefield_sources to work around the bug, but I need to do more poking at it.

I've found that if I disable the file_validate_is_image validator from plupload_element_validate() then the file save works correctly. But this feels like treating the symptom rather than a proper cure.

diff --git a/plupload.module b/plupload.module
index e187f7a5..9e9dc3a8 100644
--- a/plupload.module
+++ b/plupload.module
@@ -239,6 +239,11 @@ function plupload_element_validate($element, &$form_state) {
     $file->filename = drupal_basename($destination);
     $file->filemime = file_get_mimetype($destination);
 
+    // Don't run file_validate_is_image() because it causes problems with the
+    // way the $file object is handled. The file is also likely to have been
+    // saved already.
+    unset($element['##upload_validators']['file_validate_is_image']);
+
     foreach (file_validate($file, $element['#upload_validators']) as $error_message) {
       $message = t('The specified file %name could not be uploaded.', array('%name' => $file->filename));
       form_error($element, $message . ' ' . $error_message);

Just to be clear, the patch is for plupload, not file_entity.

@DamienMcKenna, thank you very much!