Update

User Pictures are still disappearing. This time, on a fresh 8.0.5 site though, it is not the default image that is being lost - per the summary below - and nothing to do with image styles - this time we have gone with the style we were given by default by the User module - but Pictures added after custom fields were added in Configuration >> Account settings (/admin/config/people/accounts) are going missing although AFAIR the default image which was added before custom fields were added, still remains intact..

Here's some new info: (Please see screenshot attached)

  • I uploaded the Picture last night after I noticed it had disappeared
  • The image had been deleted from the styles directory this morning
  • I looked in /admin/content/files and saw that the files was listed as "permanent" and "used in 1 place" even though the image file had been deleted
  • I removed and re-uploaded the User Picture and it displayed as exptect ... but ...
  • The image file appeared twice; once as a "Temporary" file and once as a "permanent" file per the screenshot.
  • The screenshot shows that both entries pertain to the most recent upload.

Previous summary

On /admin/config/people/accounts/fields/user.user.user_picture the UI still shows that a default Image has been uploaded. However the image has been removed from the appropriate image style directory.
The default image is displayed correctly for at least a day.
The image is automatically removed after a few days but survives several cron runs.
This behaviour happens regardless of whether Drupals default image style or a custom image style is chosen.
This behaviour happens even when the user picture field is referenced in a View.
Pictures of users explicitly uploaded (IE where the default image is not used) display correctly after the default image has been automatically removed.

Steps to reproduce:

  1. create a custom image style e.g. "User picture (85x85)"
  2. Add some more fields to Configuration >> People (admin/config/people/accounts/fields) e.g. Name and address text fields
  3. Upload a default image for the Picture field (admin/config/people/accounts/fields/user.user.user_picture)
  4. Tell Drupal to use our custom image style to display the user picture (https://admin/config/people/accounts/display)
  5. Create a View to list all users with their picture and any other fields like name and address
  6. Tell the view to use the custom image style to display the User_picture field
  7. Add some users. Some with pictures ; some without (IE that will use the default image)
  8. Wait a few days
  9. Monitor the use of the files directory in which the custom image is stored
  10. Monitor the page in which the View is displayed:
    note that, after a few days, the browser's "missing image" icon and our alt text of the users picture 's the rendered View row will replace the default image you uploaded in step 3.

O

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

iainH created an issue. See original summary.

cilefen’s picture

Can you add the steps to reproduce to the issue summary please?

iainH’s picture

Issue summary: View changes
iainH’s picture

Issue summary: View changes
swentel’s picture

I can't figure out why this would happen, this isn't really related to the user module or so since it's a normal image field.
When uploading, I don't see the status being set to temporary either.

iainH’s picture

Yes ... but ... as images are not dropped when referenced by Nodes etc. this suggests that the way that image styles and User module interact is the problem. Is there a User module test case that would be able to verify that the default user picture is retained after a few days .... perhaps by tweaking the timestamp of the image-style-generated file?

iainH’s picture

Title: Default image automatically removed incorrectly » User picture automatically removed incorrectly
Issue summary: View changes
FileSize
40.75 KB
iainH’s picture

Version: 8.0.3 » 8.0.5

This is a bit of a problem for me (I tagged it as a major bug) because displaying some fields of the user profiles - including the user pictures - are a visitor-facing requirement of the site and, currently, this is the only bug I know of that is preventing the site from going live.

iainH’s picture

I delved into this a bit more and have raised an issue on the Core Image queue #2683679: Images incorrectly deleted with a theory - to be refuted most probably!; not really knowing yet where the error lies. But as @swentel suggests it is unlikely to be a User module issue I thought it was worth a go.

xjm’s picture

Title: User picture automatically removed incorrectly » User picture automatically removed incorrectly
Version: 8.0.5 » 8.1.x-dev
Priority: Major » Critical

If this is still happening, it's critical because of the data loss. We can leave it filed against user.module for now (no need to file a separate issue against a different component within the core queue).

claudiu.cristea’s picture

xjm’s picture

Title: User picture automatically removed incorrectly » Images incorrectly stored as both temporary and permanent files, leading to file deletion
Issue summary: View changes
FileSize
58.82 KB

I think I just managed to reproduce this somehow with an image field:

The two things I did were rename a file, and rely on the file munging for a file with two extensions. Going to try those two things separately on a new install and see which is reproducible.

Edit: Not actually the bug.

xjm’s picture

Never mind, in #13, the files are actually named differently, and I confirmed that when temporary files are purged, the permanent file still remains.

xjm’s picture

Title: Images incorrectly stored as both temporary and permanent files, leading to file deletion » User profile images unexpectedly deleted

So the screenshot attached above is not actually enough to confirm that the original report cause the file to be marked as both temporary and permanent. /admin/structure/files displays the name of the file, which is not the same as its filepath. To confirm there were actually two entries for a single file using that view, one would need to look at the links displayed and confirm they are the same file.

xjm’s picture

xjm’s picture

Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)

There are a lot of steps that would seem unrelated in the summary, but I wasn't able to reproduce this, so I tried the following.

  1. Install Standard.
  2. Go to /admin/config/media/image-styles and add a "User picture" image style that resizes the image to 85 x 85.
  3. Go to /admin/config/people/accounts/fields and add a date field for the user's birthday.
  4. Go to /admin/config/people/accounts/fields/user.user.user_picture and upload a default user picture.
  5. Go to /admin/config/people/accounts/display and change the image style to the "User picture" one.
  6. Add a user that has no picture (so uses the default).
  7. Add an additional user account with a custom picture.
  8. Leave user 1 using the default picture.
  9. Add the user picture to the people view, using the user picture style.
  10. At /admin/config/development/configuration/single/import:
    • Select "Simple configuration".
    • Add system.file as the configuration name.
    • Paste in:
      allow_insecure_uploads: false
      default_scheme: public
      path:
        temporary: /your/tmp/filepath/here
      temporary_maximum_age: 1
      _core:
        default_config_hash: your_config_hash_here
      

      (Use the filepath and default config hash from your system.file config. You can see it by going to the single export tab and looking at the same system.file config.)

    Save. This overrides your temporary file purge time to be 1 second, meaning temporary files are essentially deleted immediately when you run cron.

  11. Run cron from /admin/reports/status.
  12. Return to /admin/people. Nothing has been deleted.

So I think we need some other steps to reproduce this, and maybe some more specifics for the original report in the summary. Such as:

  • What are the exact file paths of the images involved? Is it related to particular dates, etc.?
  • Are the source image files deleted, or only the image style files?
  • What do their entries look like in the file_managed table? Are there still entries there after the problem starts happening?
  • Are there other specific configurations different from Standard?
  • Were any images or accounts deleted through the UI?

Alternately, if anyone can find a different (less complicated) path to reproduce this, that would really help. Maybe someone who is having the problem could set up a simple site and monitor it and debug with it, then report back here.

yobottehg’s picture

I have a client reporting the same behaviour on the file upload form. Can't reproduce it also

xjm’s picture

@yobottehg, a few questions that might help diagnose it:

  1. What kind of a file upload is it on the client's site? A user picture? Another image field? Or just a non-image file field?
  2. What configuration options does the file field have? Max size, extension, etc.
  3. Are the files that are being deleted unexpectely being used anywhere else on the site? E.g., referenced in other items of content, uploaded separately to other content, embedded in WYSIWYGs, etc.
  4. Are the entities that are having the files deleted revisioned? Translated?
  5. Do they see the files listed at /admin/content/files? (Keeping in mind that the displayed file name does not necessarily have the counters like _0 so they need to check both the name and the link to the file.)

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dawehner’s picture

Last summer (July 2015) I debugged a similar problem with files disappearing from the system somehow.
This has been files attached to a regular node form though.

I observed the following things:

  • Some files got removed when being in temporary state. Some of them got lost from the {files} table, but some remained
  • The related nodes seemed to be edited recently
  • The effect was hard to track down, because a varnish cached the files for a long time, so it started to fail when something try to generate an image style
dawehner’s picture

There seems to be indications that its related to the wysiwyg editor, see #2806287: Wysiwyg uploaded images disappear

quiron’s picture

suscribing

lauriii’s picture

I have also faced this same issue on multiple sites that I have worked with. It has only happened few times and I have no clues what has caused it to happen.

dawehner’s picture

@lauriii
Did you had more than one language on the site?

lauriii’s picture

@dawehner yup, all of the sites where I have seen this to happen has been multilingual

quiron’s picture

Maybe this can be usefull, are steps to reproduce an unexpected image lost for image fields in multilingual sites: https://www.drupal.org/node/2810355

Juanswe’s picture

Hi, First i wanna say that im sorry for my bad english.
im a very new guy with Drupal, im using D8.2.5. And im having the same issues. But my problem its happening when i install a new language on my page and the logged in user change the default language on her page, the avatar dissapear, But only if he change the language. The others user have not problems.
Sorry, i can not help more because im new in Drupal, but i wanna share my problem so maybe can help somehow.
Thanks!

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Wim Leers’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

#28: thank you so much for posting that! Your information confirms exactly what I suspected:

its happening when i install a new language on my page and the logged in user change the default language on her page, the avatar dissapear, But only if he change the language. The others user have not problems.

Then the steps to reproduce are:

  1. use the "user picture" field
  2. user X uploads a photo to their "user picture" field
  3. install a new language (note this can be a new interface language — you don't need to have content_translation installed!)
  4. user X changes their preferred language
  5. user X' user picture disappeared!

This is because \Drupal\user\AccountForm::form() does:

    // User entities contain both a langcode property (for identifying the
    // language of the entity data) and a preferred_langcode property (see
    // above). Rather than provide a UI forcing the user to choose both
    // separately, assume that the user profile data is in the user's preferred
    // language. This entity builder provides that synchronization. For
    // use-cases where this synchronization is not desired, a module can alter
    // or remove this item.
    $form['#entity_builders']['sync_user_langcode'] = '::syncUserLangcode';

Which means that \Drupal\user\AccountForm::syncUserLangcode() is called upon saving the account form, which then does:

  public function syncUserLangcode($entity_type_id, UserInterface $user, array &$form, FormStateInterface &$form_state) {
    $user->getUntranslated()->langcode = $user->preferred_langcode;
  }

… which means that the default translation is being changed!

This is exactly the same problem as #2810355: $entity->isDefaultTranslation() behaves incorrectly when changing default translation, causing file/image field usage to be set to zero, causing files to be deleted then.

Thanks to #28, I was able to prove this conclusively.