Drupal version : Pressflow 6.24
Database : MySQL 5.1.61
PHP : 5.3.8

After updating to version 6.x-1.13, several custom blocks on the front page of a client's site became much more narrow. The Skinr 6.x-1.6 module is also enabled, and allows the configuration of block widths. The blocks do not have a width assigned, but the class added to the blocks is now grid12-4. When I rollback to Fusion 6.x-1.12, the classes are once again output as grid12-0. Client just reported the issue, so I have not had time to look through any code changes between version 1.12 and 1.13.

Comments

nickgee’s picture

Hi there,

Seeing the same bug in our upgrade, only our blocks are now grid12-2 instead of grid12-0.

sheena_d’s picture

Status: Active » Closed (works as designed)

grid12-0 is an invalid grid width value. This was a bug related to the context module, which was resolved in Fusion 6-1.13.

#1184952: Blocks in sidebars populated only by Context are assigned grid16-0

kkasischke’s picture

Status: Closed (works as designed) » Active

sheena_d, Sorry to re-open the issue.

The blocks that were previously given class of grid12-0 are not in a sidebar, but the content-region. The content-region is within the content-group and main-group, which both have grid-8 classes. The sidebar-first region has a width of grid-4. Shouldn't my custom blocks have grid-8 instead of grid-4?

I my mind, since there is no width assigned at all in the block configuration, I would think that a grid-x class wouldn't be added at all. But I may be misunderstanding the original issue.

sheena_d’s picture

Status: Active » Closed (works as designed)

Fusion automatically gives blocks a grid width of the region's width divided by the number of blocks in the region, with a minimum width (i.e it won't give blocks a grid12-1 class). This was changed in the 7.x version of Fusion, but will not be backported to 6.x.

Relevant issues:

#1277534: Make auto-generated block widths optional
#804508: Unit Widths on Blocks

kkasischke’s picture

Thank you, I understand.

If this issue is not related to the security fix, would you mind telling me which part of the code was changed? It will be much easier if I can suppress that one change in behavior on our sites rather than spend hours rewriting CSS. If there is a better place to discuss the issue, please let me know.

nickgee’s picture

Status: Closed (works as designed) » Active

Ok, if this is by design, then how do you make block elements act as blocks (ie. not inline)? Will every block need to be given a custom width that is the width of its container?

(Just curious, and thrown into a new fusion project, not trying to be facetious :)

sheena_d’s picture

Status: Active » Closed (works as designed)

@nickgee: Blocks floating beside each other, rather than stacking, is the intended behavior in the Fusion theme. You can override this by customizing the widths and behavior (float left or right or clear) of your blocks via the Skinr options available on every block.

@kkasischke: for future reference, you can view all commits for any project by clicking the "view commits" link at the bottom of the "Maintainers for this project" block on the project page. The particular commit you are interested in is here: http://drupalcode.org/project/fusion.git/commit/5e2f55e From that page, You can view a diff showing the changes made in this commit.