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.
I'm running 4.7.4, mysql 3.23.43
Using this module, if I add a filefield entry to a node built in the newest CCK, it works great.
If I go back in and edit my node, "DELETE" is checked in the checkbox list.
Even if I uncheck it, the file deletes itself and I'm forced to re-attach the file.
Comment | File | Size | Author |
---|---|---|---|
#10 | filefield-delete-error_0.patch | 1.06 KB | robomalo |
#7 | filefield-delete-error.patch | 1.06 KB | robomalo |
Comments
Comment #1
bomarmonk CreditAttribution: bomarmonk commentedI can confirm this bug. I'm running the CCK filefield module with Drupal 4.7.5. Also, even if the files are required, an edit (of other parts of the node) will result in the loss of the files from the published node. The title of the fields will appear, but the files will be gone, even thought they were required for the node type. The "requirement warning" only appears when you go back in to edit the node a second time (to add the files back into the node).
I would note: even on a first, successful submission of the node, complete with files, the check-boxes next to the files ("list," and "delete") appear to behave in an undesirable fashion. In addition to suydam's observation above, when editing the node, checkboxes next to the filefield are not defaulted to "list." In fact, both checkboxes, an the initial creation of a node, are filled (the files are still successfully published to the node with both "list" and "delete" checked). At this point, I'm not sure exactly what those check boxes are doing.
Comment #2
bomarmonk CreditAttribution: bomarmonk commentedI should add that I'm using MySQL 4.0
Comment #3
seanrConfirmed in 5.0 as well. I will attempt to debug this next week.
Comment #4
robomalo CreditAttribution: robomalo commentedFYI - Same thing is happening to me.
Comment #5
robomalo CreditAttribution: robomalo commentedfilefield.module v 1.12
Changing line 412
$form[$fieldname][$delta]['remove']['#value'] = 1;
to
$form[$fieldname][$delta]['remove']['#value'] = 0;
prevents the "Delete" checkbox from defaulting to TRUE and deleting the file automatically. The problem is you can't check "Delete" if you no longer want the file (the opposite of the current problem). I am only supplying this little bit of information so someone more knowledgeable than myself can tell us if the problem lies somewhere around here. If I get some more time and my deadlines lighten up, I will play around some more.
Comment #6
epicflux CreditAttribution: epicflux commentedIn the imagefield module there's second check after the first:
(this code is similar to the code on lines 412 - 417 in the filefield module)
that's not there in the filefield module, and seems necessary.
The filefield module does keep track of the files in the session (I think) so it would seem possible to implement this, but without knowing much about the module I'm just speculating.
Comment #7
robomalo CreditAttribution: robomalo commentedThis is my first patch. I tested it and it seems to work perfectly. Files don't get deleted automatically and delete is not checked by default. Please let me know if it works for you.
Comment #8
technivant CreditAttribution: technivant commentedthis works perfectly for me. tested on drupal 4.7.4, mysql 4.1.21, php 4.4.4
Thanks, robomalo - this couldn't have come at a better time!
Comment #9
anaxx CreditAttribution: anaxx commentedConfirming bug on 5.0, will test again after patch committed to CVS. Thanks, guys.
Comment #10
robomalo CreditAttribution: robomalo commentedI forgot to change this comment:
"// Mark [0] for deletion if there is more than 1 image."
to this:
"// Mark [0] for deletion if there is more than 1 file."
The previous patch is the exact same, but just has the wrong comment. Use this one instead. If you already applied the previous patch, you can just open filefield.module, search for the comment string, and replace "image" with "file." Or you can just forget about it all together.
Comment #11
robomalo CreditAttribution: robomalo commentedSorry I am filling this thread up (patches are new to me). I am changing the status to "code needs review" since I don't maintain this module.
Comment #12
liquidcms CreditAttribution: liquidcms commentedyea, not sure but i don't this patch is quite right... it should set list box when uploaded.. and if another item is browsed to it should likely set first as delete?? and the 2nd as list.. or more likely just do the delete anyway if you have NOT selected "multiple values" in config for the field
i see multiple items, i don't get msg anymore about deleting first item and i never have any boxes checked...
i iwll take a look at code a bit later if i get a chance - but possibly too many issues between this and subform to make this a workable solution for me.. i will likely go down the pageroute.module path to see if that works before coming back to try to fix all the issues with subform/filefield
Comment #13
wsuucmedia CreditAttribution: wsuucmedia commentedDoes the patch work for 5.0? I'm a bit confused and worried about trying it in a different version than intended. I stumbled upon this issue as it was replied to right around the same time I posted a bug report for audio files disappearing on me (deletes the file whenever I go to edit the tags), this sounds like it might be the same issue (I've only tried to upload audio files thus far). I'm a bit of a noob to the whole CMS admin thing, a bit of a "s/he who speaks up, volunteers for the task" case with this website and I'm just too darn lazy to do the HTML by hand every week for this podcast!
Comment #14
dopry CreditAttribution: dopry commentedTrying testing HEAD against 5.0. I believe this issue should be resolved in HEAD. I'll try to get a 4.7 fix in tomorrow.
Comment #15
redraven CreditAttribution: redraven commentedHas this been resolved for the Feb 1 4.7.x-dev release?
Thanks
Comment #16
redraven CreditAttribution: redraven commentedCould someone confirm if the most recent dev release incorporate this fix ?? I don't appear to be having this problem anymore, but want to confirm its resolution.
Thanks
Comment #17
jpetso CreditAttribution: jpetso commentedThis exact patch was definitely not committed to filefield, but dopry committed a rather large patch (the last one for DRUPAL-5) shortly after his last comment in here. As the issue seems to be fixed according to redraven, I'll take the freedom to close this issue. If it does manifest again, please reopen it.
Comment #18
(not verified) CreditAttribution: commented