Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.this patch adds the same filtering mechanism that's already available at admin/user/user and admin/content/node. it seems to me we should have the same basic layout for all three of those admin screens, for consistency. the patch eliminates the secondary tabs, as they are no longer necessary -- simply filter the comments by status to see all unpublished comments.
test site here: http://test.xcarnated.com
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | Picture 3_9.png | 10.34 KB | webchick |
| #10 | comment_filter_4.patch | 17.76 KB | jvandyk |
| #8 | comment_filter_3.patch | 17.63 KB | hunmonk |
| #7 | comment_filter_2.patch | 13.82 KB | hunmonk |
| #6 | comment_filter_1.patch | 13.39 KB | hunmonk |
Comments
Comment #1
hunmonk commentedone note: i wasn't able to figure out the CSS to properly float the filter buttons as they are on the other admin pages, so i've temporarily punted and just put them below the filter options. :) i would appreciate it if a CSS wizard could fix that up!
Comment #2
add1sun commentedreally nice stuff. i agree that a consistent UI would be a Good Thing (tm). +1
Comment #3
yched commentedOn the test site, publishing / unpublishing comments produce white screens
Comment #4
michelle+1 from me. This would be awesome to have on d.o. Currently deleting comment spams is a manual job because there's no way to filter the comment admin screen by user name.
Michelle
Comment #5
hunmonk commentedcouple of updates:
the one remaining problem that i see is to fix the layout issue with the filter buttons. i'm no CSS guru, so somebody else please step up to help!
test site here: http://test.xcarnated.com
Comment #6
hunmonk commentedok, the button overlap is caused by a fixed width setting in system.module:
system.css: line 158, there is a width:14em applied to dl.multiselect dd.b select
all the other admin filters use this setting, so it seems most sensible to just back off the width of the user autocomplete field to fix the issue.
attached patch corrects.
Comment #7
hunmonk commentedhunmonk: Steef: i checked IE 6, and the only difference i see when removing the width: 14em; line is that it throws the buttons below the filter list
hunmonk: Steef: i think this is fine, given it's still an ok layout, and all the others work as they are supposed to -- thoughts?
Steef: hunmonk: yes, include it in your patch
so attached patch restores the original length of the user textfield, and bags the fixed width CSS line...
Comment #8
hunmonk commentedthis update completes the comment admin interface conversion to be consistent with the node admin interface:
hook_comment_operations(), which functions just likehook_node_operations().Comment #9
dmitrig01 commentedIt's all good!
I did code review, tests came out definite positive
I reviewed the patch on hunmonk's test site for about 7 minutes and I found no errors, except for
which is present in all core filters :x
But besides that, it is rtbc!
Comment #10
jvandyk commentedThe filter worked fine, except for status = published. That was failing because if ($form_state['values'][$filter]) fails when the value of $filter is 0, as it is when the 'published' option is selected in the dropdown. Changed the test to isset() and it works.
Refine works. Undo works. Reset works.
Changed 'user' to 'author' in the filter. It should either be that or 'username', otherwise it's not clear what to type in the autocomplete textfield. I went with author because that is the title of the column in the comment table below, so it's consistent.
Also fixed the funky array formatting.
This is a very helpful patch and makes Drupal more consistent.
Comment #11
webchickHm. I'm getting the depicted weird output, in Camino, Firefox, and Safari. I tried shift+reload but even in new browser instances it happened.
And if this is truly about making the admin/content/comment and admin/content/node screens identical, that very handy author option ought to be on the node administration thing too.
Comment #12
hunmonk commentedit would be great if somebody else could pick this up and bring it home -- it's a needed usability improvement.
Comment #13
panchoWe need to pick this up and bring it home - to D7, unfortunately.
Comment #14
dave reidI might pick this up. It's sorely needed and we need to stop hard-coding the #$^@ comment operations. :)
Comment #15
dave reidComment #16
sun#355926: Add comment_mass_update() was marked as duplicate of this issue. If it really is (I did not check), then this issue is critical, because the other is. If you revert to normal, then this issue is not a duplicate and the other needs to be re-opened.
Comment #17
dave reidCross-tagging for core issues that need to be fixed for the Mollom.module.
Comment #18
sunTagging for feature freeze.
Comment #19
sun.core commentedThis would still be nice to get in, 'cause those half-baked comment_operations functions are totally insane to work with... if webchick agrees, then perhaps someone manages to do this until 15th.
At the very least, not critical.
Comment #20
sun.core commentedComment #21
jhedstromThis should be a bit easier now that this page is a view (I think?).
Comment #22
miro_dietikerWe realised that hook_entity_operation_alter() is not triggered for comments when implementing that hook in collect module #2491307: Add "Capture" operation to all content entities.
Currently the operations are hardcoded in CommentAdminOverview::buildForm().
A similar limitation still exists in D8 with terms and a solution: #2469567: Entity operations for terms are hardcoded in taxonomy terms's overview page
Retitling the issue to refer to hook_entity_operation_alter()?
Comment #30
andypost