Posted by Wesley Tanaka on December 11, 2005 at 12:25pm
6 followers
| Project: | Drupal core |
| Version: | x.y.z |
| Component: | comment.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
the comment block is completely unconfigurarable
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| comment.block.patch | 2.29 KB | Ignored: Check issue status. | None | None |
Comments
#1
Ok, the patch works in CVS!
#2
patch still applies against 4.7.0-test2
#3
I think it would be better to introduce a theme_comment_block() function so we can change the whole look and not only some visual settings
#4
I agree with Tobias. In any case this is neither a bug nor critical.
#5
#6
Trying to distinguish between bug and feature without a spec is a bit academic, but I was under the impression that the (as far as i know, implicit and undocumented) specification of drupal is that it shouldn't be outputting things that can't be themed.
That certainly seems to be the philosophy, and one of the things that attracted me about the project in the first place.
#7
we want that the code and style/theme gets completely seperated.
You have a sql query in your theme-function
please modify it so that it gets an array with comments... (maybe you have to introduce a second helper function...)
thanks tobi
#8
+1 for the idea.
I find the hard coded comment area very inflexible.
#9
The problem is the hard coded 10 is being passed to the SQL function. Is there a mechanism other than theme functions (rejected in comment #7), hook callbacks (not appropriate here) or configuration variables (rejected in comment #3) that can be used to get a piece of data (like a replacement count) into the system?
Unless by second helper function you mean a second theme function that doesn't return HTML, but instead returns the data structure...
Attaching a (untested) patch which I don't think you're actually suggesting.
#10
#11
Committed to HEAD. Thanks.
#12