| Project: | Omega |
| Version: | 7.x-3.1 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
This may be the intended behavior, but I'm having some trouble with the application of the clearfix class. Clearfix is added to all fields with labels (inline or above), but it is not added to fields with hidden labels. This is causing issues, as I have an image field (w/ multiple images) with a hidden label. The images have been floated left to form a grid, which means that the following (text) field (which has an inline label, and thus is clearfix'd) is not clearing to a new line. If I add the clearfix class to the image field with firebug, however, everything works.
So, a) is this the intended behavior, or am I seeing a bug? b) If it's intended, is there a good reason not to add the clearfix class to fields with hidden labels? and c) If it's okay to change, where do I change it? I'm guessing I would need to copy node.tpl.php to my subtheme's template folder and edit that?
I'm not sure if this is an Omega issue or a core issue, so I apologize if it's the latter. Also, this is a product node for ubercart, so the problem could also lie there (or probably in about a hundred other places).
Thanks.
Comments
#1
I've found that the problem is caused by template_preprocess_field in field.module. In this file, lines: 1063-1064 (drupal 7.17) there is a condition:
<?phpif ($element['#label_display'] == 'inline') {
$variables['classes_array'][] = 'clearfix';
}
?>
To fix it you have to change it to something like this:
<?phpif ($element['#label_display'] == 'inline' || $element['#label_display'] == 'hidden') {
$variables['classes_array'][] = 'clearfix';
}
?>
The best way to do this is to use your own template. Copy entire function to your template.php file. Change it like I show you and everything should be working. :) I attached example template.php file if somebody couldn't find function I wrote about.
#2
Thanks for the reply. So this isn't an Omega issue at all then, right? If it's not, I'll mark it as closed.
And assuming this is in Drupal core, would you say this is intended, or a bug? I'm a little hazy on the particulars now, but obviously this was unexpected and unwelcome behavior in my particular case. But I guess the question is whether that's just me and this one site I was working on, or if it's more generally problematic for others as well. I've already worked around the issue (it wasn't a big deal, but I just didn't want to use a kludge if I didn't have to), but I wouldn't want anyone else to have this be a problem if it's something that should be fixed.
Thanks again.
#3
Yes, this is a Drupal core problem, which was unexpected by me too.
There's a chance that developer just forgot to add that condition, but personally I think, that we miss something and it was intended. Anyway this is the correct way how to deal with it (I think so... Theme function is overridden by custom theme function. That's how should be it done, isn't it?). Thanks Drupal for its easily alteration of behavior, for most of the functions. :)
Regards.
#4
Thanks for the help. Marking this closed.