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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

bomarmonk’s picture

I 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.

bomarmonk’s picture

I should add that I'm using MySQL 4.0

seanr’s picture

Confirmed in 5.0 as well. I will attempt to debug this next week.

robomalo’s picture

FYI - Same thing is happening to me.

robomalo’s picture

filefield.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.

epicflux’s picture

In 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)

        if (!$field['multiple'] && $delta == 0) {
          // Mark [0] for deletion if there is more than 1 image.
          if (count($_SESSION['imagefield'][$fieldname]) > 1) {
            $form[$fieldname][$delta]['flags']['delete']['#value'] = 1;
            $form[$fieldname][$delta]['replace'] = array(
              '#type' => 'markup',
              '#value' => t('If a new image is chosen, the current image will be replaced upon submitting the form.'),
            );
          }
       }

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.

robomalo’s picture

This 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.

technivant’s picture

this 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!

anaxx’s picture

Confirming bug on 5.0, will test again after patch committed to CVS. Thanks, guys.

robomalo’s picture

Status: Active » Closed (fixed)
FileSize
1.06 KB

I 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.

robomalo’s picture

Status: Closed (fixed) » Needs review

Sorry 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.

liquidcms’s picture

yea, 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

wsuucmedia’s picture

Does 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!

dopry’s picture

Trying 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.

redraven’s picture

Has this been resolved for the Feb 1 4.7.x-dev release?

Thanks

redraven’s picture

Could 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

jpetso’s picture

Status: Needs review » Fixed

This 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.

Anonymous’s picture

Status: Fixed » Closed (fixed)