When I attach a file to an ad, and then edit the node, the various form widget elements are missing their labels rendering this part of the UI extremely user unfriendly.
The labels that are missing are:
- Remove (checkbox)
- List (checkbox)
- Weight (select list)
- Private (checkbox)
See screen shot of this. I get this on all browsers, and the HTML markup is in fact not rendering the labels so it's not a browser issue.
I'm running Drupal 6.20, Private Upload 6.x-1.0-rc3, FileField 6.x-3.9.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | attachment_form_labels-1080662-17.patch | 562 bytes | danny englander |
| #15 | attachment_form_labels-1080662-15.patch | 562 bytes | zerolab |
| file-attachment-no-labels.png | 31.86 KB | quinns |
Comments
Comment #1
quinns commentedNobody have any clues on this one? Still an issue for our customer. Thanks.
Comment #2
john franklin commentedI can confirm that when I enable Private Upload the labels disappear. I also see this in CCK-created content types with a file field. Disabling Private Upload fixes both the CCK-based content type's and the Advertisement type's create & edit forms.
Comment #3
quinns commentedJohn Franklin, thanks very much. That fixed the problem for my customer too.
Comment #4
quinns commentedComment #5
john franklin commentedDisabling the module may fix the site, but it doesn't fix the code. Reopening so the Private Upload maintainers can investigate.
Comment #6
sbellens commentedConfirming this bug here. I'm using the same versions and bump into the exact same problem as described and pictured. I'm experimented a bit with the 6.x dev version of the module atm.
The problem is in the javascript section of the private_upload.module file, lines 385 - 408. Changing the lines 386 and 387 from
$form['files']['#theme'] = 'private_upload_form';
// $form['#submit'][] = 'private_upload_form_submit'; // ???
to
// $form['files']['#theme'] = 'private_upload_form';
$form['#submit'][] = 'private_upload_form_submit'; // ???
Already get's the original view back plus an added checkbox - which is however misplaced. I'm all but a PHP expert, so maybe one of the module developers can take it from here?
Comment #7
Anonymous (not verified) commentedI just updated to the latest dev and this looks to be fixed...
Comment #8
Anonymous (not verified) commentedI updated to the latest dev, 6.x-1.x-dev, still have the same issue as quinns (thanks for that screenshot).
I did run update.php & flush cache.
Am not using conflicting modules noted in project page (Upload Path, Upload Image).
I am using the core Upload; not using FileField, btw, does this affect Private Upload?
I originally made a separate post, http://drupal.org/node/1177216, but this thread covers the same issue.
Comment #9
torrance123 commentedJust thought to pass on my fix to this:
Around line 649 of private_upload.module change this:
to this:
Did you miss the difference? It's that single ampersand character before the $form variable in the function definition. I'm not sure why this hasn't affected everyone, but it may be php version related.
Comment #10
Anonymous (not verified) commented@torrance123 - That did it, thanks very much! Yes I had missed the difference. The widgets are back! I can list and delete!
That frees me up to raise a previous issue I had encountered but couldn't separate out :)
[ instead of a private/ directory being created, files are being uploaded into the files/ directory with names like private, private_0, private_1...
I'll look for, and if necessary, start a separate post about it.]
Comment #11
john bickar commentedConfirming that this issue exists when running PHP 5.3 (does not affect PHP 5.2) and that removing the ampersand (passing the variable by reference) in theme_private_upload_form() fixes the issue for 5.3.
Comment #12
b-netix commentedusing changes from sbellens and torrance123 fix my problems
thanks
Comment #13
Anonymous (not verified) commentedWorked for me, thanks.
Time for porting it to rc4 or an updated dev!?
Comment #14
mortona2k commentedWhat cmseasy said.
Comment #15
zerolab commentedAttaching the fix from #9 as a patch
Comment #16
pierrozone commentedComment #17
danny englanderI had the same issue but the patch in #15 did not work as something in dev has changed since the patch was written. I've attached a new patch against the latest dev (2013-May-24) and tested it and it all seems fine to me.
Comment #18
mygumbo commentedWorked for me, thanks, highrockmedia.
Comment #19
yesct commentedI just ran into this also, after upgrading my php version.