Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.By default drupal adds managed_file as temporary which means that while running cron, these images will be deleted eventually.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | scald-images_are_uploaded_with_temporary_status-1765142-11.patch | 623 bytes | gisle |
| #1 | temporary-status-fix-1765142-1.patch | 710 bytes | nagy.balint |
Comments
Comment #1
nagy.balint CreditAttribution: nagy.balint commentedThe solution is on this page:
http://api.drupal.org/api/drupal/developer!topics!forms_api_reference.ht...
Patch attached.
Comment #2
jcisio CreditAttribution: jcisio commentedDoes it happen with a clean install using the latest version of Scald? I think this is a duplicate of #1706108: Problem with scald_thumbnail field
Comment #3
nagy.balint CreditAttribution: nagy.balint commentedYes it happens on the dev version of scald.
To reproduce upload an image on the UI, and then check in database the file_managed table, and in the status column, with the latest dev what we get is a 0. Basically this patch fixes that so the images enter this table with value 1 (permanent).
This happens because when scald delegates the upload to drupal (http://drupalcode.org/project/scald.git/blob/refs/heads/7.x-1.x:/modules/providers/scald_image/scald_image.module#l26), the upload happens in this callback: http://api.drupal.org/api/drupal/modules%21file%21file.module/function/file_managed_file_value/7
That will call
http://api.drupal.org/api/drupal/modules%21file%21file.module/function/file_managed_file_save_upload/7
Which calls:
http://api.drupal.org/api/drupal/includes%21file.inc/function/file_save_upload/7
Which sets status to 0, which is temporary.
Comment #4
DeFr CreditAttribution: DeFr commentedThis patch is wrong: as long as the atom isn't saved, we don't want the file to become permanent. Cleaning it up on cron run is thus quite welcome, pretty much like the file attached to a node that's never saved . (Consider the case of an editor only performing the first step of the form, uploading a large file, and never finishing the atom creation process, which means that the file can't be use anywhere, can't be seen using standard UI, but is still uselessly taking up disk space)
When the atom is created, file field automatically takes care of both setting the status to permanent in http://api.drupal.org/api/drupal/modules!file!file.field.inc/function/fi... and adding the file usage information in http://api.drupal.org/api/drupal/modules!file!file.field.inc/function/fi...
Comment #5
nagy.balint CreditAttribution: nagy.balint commentedApparently thats not the case as we had this issue happening several times, and we did create the atoms and used them in content, so then a day later we came back and it just deleted all the original images leaving error messages.
So we then need a better solution but for the time being, i applied this patch on my site, since we cannot have images getting lost on production.
Comment #6
jcisio CreditAttribution: jcisio commentedDid you test with a clean Drupal install (remove all tables, reinstall Drupal, then Scald). What was constated in #1706108: Problem with scald_thumbnail field is there is a bug between alpha/beta release upgrade, however it is not identified.
Comment #7
DeFr CreditAttribution: DeFr commentedClosing pending additional informations on how to reproduce.
Comment #8
sahaj CreditAttribution: sahaj commentedI'm also getting troubles with 'scald_thumbnail' in the last stable version. Here is the message I'm getting during the install (sorry, it is in French):
FieldException: Tentative de créer une instance d'un champ scald_thumbnail qui n'existe pas ou qui est actuellement inactif. in field_create_instance() (line 474 of /Users/Sahaj/Sites/resonantworlds/modules/field/field.crud.inc).This is not a clean install. Maybe this can help you.
Comment #9
jcisio CreditAttribution: jcisio commentedThis is not at all related to this issue. Could you open a new one, with more detail, how to reproduce?
Comment #10
sahaj CreditAttribution: sahaj commentedThat's right, I misunderstood it. Here is my new issue: http://drupal.org/node/1970080
Comment #11
gisleThis does not happen on a clean install, but it happens on an install where somebody has managed to munge the file system permissions for the upload directory so that the web server is not allowed to write to the atom upload upload directory.
The ScaldAtomController actually checks that this directory is writeable, but it fails to produce a meaningful error message if the check fails.
The attached is an a patch simply makes sure that the user is shown a meaningful message when this happens.
Comment #12
nagy.balint CreditAttribution: nagy.balint commentedThis should have been a new issue, where the old one could have been marked as related.
Comment #13
gisle@nagy.balint,
sorry - I've reversed its status back to "Closed".
Comment #15
nagy.balint CreditAttribution: nagy.balint commented