Drupal elements are not getting styled correctly

Question

This is a general issue but I will give an example:

In drupal, TT is generating some code for <table> element but is being based on Bootstrap for the rest. Issue is that in drupal, tables do not come with .table class and TT is not generating this.

For your help, it is as simple as that:

In template.php file, add the following code:

function <theme_name>_preprocess_table(&$variables){
$variables['attributes']['class'][] = 'table';
}

where <theme_name> is the name of the theme (should be automatically given).

This is a big gap for completing the bootstrap support for drupal.

Other elements besides <table> are the tabs and vertical tabs (lists) that really don't look well at default output and are not customizable in TT as well as fieldsets. Not sure for other elements. But it is easy to edit the few details. Tables are absolutely necessary to be supported. Please check the given code and fix this. It is 3 lines of code only.

Answer 1

Also ( I am going to update this one for each problem I find and/or solve ):

I am not sure if I did something wrong here. I manually updated the default button style and the default pagination style through TT and they are not rendered correctly.

For the buttons I have not found a solution yet. For the pagination, I have found a simple workaround but I don't know if this is a best practice or has bugs. Up until now, it has solved my case.

For pagination, there are the following divs created:

<div class="pagination">

<div class="item-list">

<ul class="pager">

<li class="pager-current first">

<li class="pager-item">
.
.
.
</ul>

</div>

</div>

</div>

But looking at the css generated by TT we get

#id_content .pagination > li > a, #id_content .pagination > li > span

where id_ is the prefix I have set for my theme.

Looking at the above, there is never a first child of pagination that is <li> so the styling is wrongly rendered.

A quick workaround for these until it is hopefully fixed is to edit the file template.php again and at the function <theme_name>_pager (where <theme_name> is the name of the theme) change the return statement with the following:

return '<h2 class="element-invisible">' . t('Pages') . '</h2><div class="pagination">' . theme('item_list', array(
'items' => $items,
'attributes' => array('class' => array('pager', 'pagination')),
)).'</div>';

FYI, the only thing I did there is actually add another class to the 'attributes' item. it was only

'attributes' => array('class' => array('pager')),

and the new is like above.

 

WARNING though. I tested it in my environment and works both for system pagination, and my own created by drupal's theme_pager() function (which is basically also a system pager). Cannot guarantee  that this will work for all cases but I think it is a good start. Hope issues will be fixed soon :)

Comments

Actually, the above comment did not work as well as I wanted. The thing is that if you add another attribute, it breaks a bit the styling in a way not easily fixed. Instead, the solution that kinda worked for me is turning the definition of "#id_content .pagination > li > a, #id_content .pagination > li > span"
to "#id_content .pager > li > a, #id_content .pager > li > span" and not assigne the pagination class mentioned above.
Accordingly, I didn't test it but I think that changing the same definition to "#id_content .pagination li > a, #id_content .pagination li > span" (basically removing the '>' symbol before li tag) would work as well.

It still has some minor issues with the padding but it is not such a pain.

Answer 2

Also for the buttons:
Now normal buttons and buttons created by html code directly are being rendered correctly but drupal 7 does not support a button type other than <input type="submit"> in it's core. And what good would it do if there was not any support for the basic elements of drupal.
Drupal uses the function l() to generate links and by providing attributes like class="btn btn-xs btn-default" you can create pseudo buttons. Now, also for these buttons, almost all cases are being rendered correctly except from the one above.
When an <a> element is being given the btn-<size> class (where <size> is xs, sm or lg) along with btn-default the btn-default's border radius and font size is overriding the default value while on hover. That means that the size of the button changes when you hover over it. In order to go around, edit the style.css file and find the

.btn-default:hover, a.btn-default:hover
{

and delete from there the border-radius and the font-size (and actually all the values that you will find that are being wrongly overrided there.

 

For the developers I have also found another workaround that seems to work better but the above is just simpler to use temporarily.

The issue here comes in two reasons but in one source. The source is the CSS selectivity. To fix (don't know if there are bugs) the above these are the two things that worked for me:

1) The above section that is quoted is defined after the following 3 definitions:

.btn-lg, .btn-group-lg > .btn, .btn-lg:hover, .btn-group-lg > .btn:hover {

 .btn-sm, .btn-group-sm > .btn, .btn-sm:hover, .btn-group-sm > .btn:hover {

.btn-xs, .btn-group-xs > .btn, .btn-xs:hover, .btn-group-xs > .btn:hover{

That means that no matter what, whenever btn-default and btn-<size> are together, the btn-default properties are going to override the rest (all the rest button definitions are defined in a correct order) so this should be reversed. The first definition I quoted should be moved a bit above, before the :hover of the rest definitions mentioned above.

2) The selectivity also pays attention to differences like .btn and a.btn. So even if you do number 1 it will still not work (at least it didn't work for me). The second thing that is needed to be done is add one more thing to the above three definitions quoted and be changed as shown below:

.btn-lg, .btn-group-lg > .btn, .btn-lg:hover, .btn-group-lg > .btn:hover, a.btn-lg, a.btn.lg:hover{

 .btn-sm, .btn-group-sm > .btn, .btn-sm:hover, .btn-group-sm > .btn:hover, a.btn-sm, a.btn.sm:hover{

.btn-xs, .btn-group-xs > .btn, .btn-xs:hover, .btn-group-xs > .btn:hover, a.btn-xs, a.btn.xs:hover{

At the btn-default definition, you include an "a.btn-default:hover" so the same thing must apply to the rest of definitions in order to maintain equal selectivity and be left to the sequence of the definition in the CSS file.

Sorry for the annoyingly long answers. 

Answer 3

Hello again :)

Today I am coming with a thing that I am not sure if it is a bug or not.

Both in drupal's basic teaser, and with the help of an external module I created a page to view a list of teasers (view mode of a node). Even if on the node's page the appearance is correct, in the list view of the teasers it was awful.

Searching a bit I found that the problem was because of closing a div tag in every teaser item (you can imagine the outcome).

Now I am not sure of the solution here but what did the trick for me was removing the </div> closing tag in node.tpl.php that is being generated by TT right after the closing </article> tag (if you search the node.tpl.php there is only one instance of "</article>"). Haven't tried it thoroughly but when I create a page to view teasers, it does not break anymore.

Thank you

Comments

Hello.
In the full article homeless tag <div>, the problem is not solved.
Teaser displayed incorrectly, field in the teaser are not displayed correctly.

---

Actually none of these were implemented and I don't think that this is watched by the admins unless it gets many points. I think I should also open a support ticket to get heard...