Quick Tabs Block Order

The block is listed as the last block in the page source. Are you sure you are modifying the block order in the right theme?
From the page source it seems like the current theme is fusion.

the attached screenshot is from your page source. It shows that the quicktab block is rendered as the last item.
Do you have page caching enabled? Try to clear the cache.

We ran into this issue as well. We found a workaround in specifying the contents of each tab to come from a view, instead of a block. Asking the contents of the tab to come from a block messed with things for some reason.

As I see the 2.0 version is used on the site, so I have changed the version number..

I am not sure why would a block inside quicktab change the quicktab block weight, but I can not exclude this possibility. Will have to test it.

I'm also using Acquia Prosper and noticed the same exact issue. I'm using Advanced Taxonomy Blocks with Jquerymenu and using quick tabs to put 2 advance taxonomy blocks inside tabs. So i can't really use a "view" instead of a block :(

Looks like this issue is a couple months old. Hopefully someone figures this out.

Regarding what JennySmith said I think its just a simple float that doesn't get cleared.
.block has a float of left so i just added this to my local.css file

.quicktabs_tabpage .block{float:none}

oh and changing the theme to something else fixes the weight ordering of the quick tabs block. So its this theme. Shutting off the Skinr module didn't help either.

I just got pointed to this issue from IRC. I have the exact same problem. I have a QT block made up of 3 views (not blocks) and it stubbornly refuses to move in the block order. My theme is a custom subtheme of Fusion. Fusion seems to be the common element here, so I suggest moving it to that queue but I'm a latecomer to this issue and don't want to be the one to move it unless others agree.

Michelle

Problem still Exists. I'm going to move it over to the Fusion project and hopefully they'll get a chance to look at it. It seems fusion is the problem here.

I'm taking a look at this issue, but am so far unable to replicate the troubles with block order when using a quicktabs block with blocks for the tab content. Fusion does do some block preprocessing, but nothing that should affect block weight/order. So I need some more information to help track down what is happening. I'm assuming that everyone is using the latest versions of Fusion Core, Acquia Prosper, and Quicktabs.

- Are any Skinr styles being applied to the quicktabs block or the blocks within it?
- Does it only occur in the sidebar, or does it occur in other regions as well?
- Does it occur in Fusion Starter as well as Acquia Prosper?
- Have any custom block-related functions been added to template.php?
- Can someone message me with a site that I can examine that does this? (I'm not currently seeing quicktabs on JennySmith's site)

Also JennySmith, gooddesignusa is correct, the issue with the background not displaying should be fixed by adding this to your local.css file:

.quicktabs .block {
  float: none;  /* keep content in div */
}

I'll be adding this to Acquia Prosper's css file for the next release.

- Are any Skinr styles being applied to the quicktabs block or the blocks within it?
-- The quicktab block I have set up is 2 blocks that list some taxonomy. The taxonomy blocks have a skinr style of "Gray rounded title background, list styling" The quicktab block has no skinr style. I shut off the skinr styles for the 2 taxonomy blocks that quicktab uses but that didn't fix the issue.

- Does it only occur in the sidebar, or does it occur in other regions as well?
-- I will check later. Right now its set to the sidebar on the left.

- Does it occur in Fusion Starter as well as Acquia Prosper?
-- I tried switching to the fusion core or fusion starter theme. Issue was still there.

- Have any custom block-related functions been added to template.php?
-- No custom block functions have been added.

- Can someone message me with a site that I can examine that does this? (I'm not currently seeing quicktabs on JennySmith's site)
-- I will msg you with a dev site I'm currently working on.

Thanks a lot for looking into this issue.

I've figured out what is causing the problem, but I'm not sure how to fix it. The problem is the block_list() function used in Fusion Core. It seems to drop the position of a Quick Tabs block to last position when it's called on the block's parent region.

I've filed an issue in the Quick Tabs queue (#709782: Calling block_list() drops Quick Tabs block to last position) and hopefully this can be fixed in Quick Tabs, because I don't know of a way to avoid using the block_list() function in Fusion Core.

In order to fix the background in Quick Tabs not showing, I added the following code to the most recent release of Fusion Core (RC1), not in Acquia Prosper as mention above in comment #13:

.quicktabs .block {
  float: none;  /* keep content in div */
}

.block is float-ed in Fusion? that does not seems good to me..

Pasqualle, why does that not seem good to you? This is the foundation of Fusion's layout, where blocks are floated in the grid and controllable through Skinr.

normally the sidebars (regions) are floated and blocks are relative, otherwise you need a new div to make the position relative inside the block..

but the problem is with fusion_core_preprocess_block() (in template.php)

notice: Undefined index: quicktabs_tabpage in fusion/fusion_core/template.php on line 245.

there could be blocks inside QT which are assigned to a non-existent 'quicktabs_tabpage' region. I guess that may create some mess in the calculation..

so before

$regions[$vars['block']->region]

there should be a region check, something like:

isset($regions[$vars['block']->region])

Pasqualle,

As it is now, the only thing fusion_core_preprocess_block() does to the blocks in a Quick Tabs block is to give them a grid width class of grid16-0 (which is undefined and harmless) and add extra block edit links for each of the blocks (which could be considered a feature if you wanted to edit the individual blocks).

When checking for whether the block is in one of Fusion's regions (as opposed to a Quick Tab "region"), we can remove the grid16-0 class and the extra block edit links, but it has no effect on the order of the Quick Tab block in the region. It is still last regardless of what position you set.

Is this what you were referring to? Were you able to fix the block positioning error with this approach?

Thanks.

I did not check, but as I see this could easily ruin the positioning, as blocks inside qt are counted as normal, and incrementing $total_blocks, which is being used in some kind of region size calculation.

I only saw many error messages (php notices), which I fixed with the above isset() check..

Pasqualle,

Well thanks very much for that suggestion. It put me on the right track to a fix to avoid this problem for Fusion-based themes!

Attached is a patch against the latest version (rc1) of Fusion Core's template.php file that exempts Quick Tabs blocks from any preprocessing, including the block_list() function. It doesn't fix the fundamental issue in Quick Tabs (#709782: Calling block_list() drops Quick Tabs block to last position), but at least it works around it for Fusion users.

I dislike module-specific hacks in the Fusion codebase, so I'm going to work on a more generic solution that doesn't just target Quick Tabs. But I figured folks needed some relief from this issue in the meantime.

Let me know if this patch takes care of the issue.

Thanks.

Awesome, sociotech! I'm with you that module specific hacks aren't the best but this at least lets it work until a better solution is found.

Thanks,

Michelle

using

  // Do not process bogus blocks. Block assigned to unknown region.
  if (!isset($regions[$vars['block']->region])) {
    return;
  }

which has the same result, would not be a module specific hack

Pasqualle,

Did you try that code? It shouldn't be able to work because it depends on $region being set, but needs to execute before the code that sets $region. That's because it's the code that sets $region that contains the block_list() functions.

If your code works, perhaps I'm not understanding where you inserted it.

Here's the more generic option I was working on. If you or anyone else has a chance to try it and let me know if there are any issues with it, that would be helpful:

// Do not process blocks outside defined regions
if (!in_array($vars['block']->region, array_keys($theme_info->info['regions']))) {
  return;
}

Thanks!

Here's a patch version of the above code.

The generic version of the fix (in comment #25) will be in the next release.

In dev release

Thanks!

Michelle

Thanks!, Michelle!!

I have solved this problem thanks to you, thank you

Not me. sociotech fixed it. :)

Michelle

Any solution for non-fusion themes? I am using a custom theme and whenever I switch the a subtheme, the block order gets messed up but if it's set to the main theme the block order is correct.

Edit: I was misled, turned out to be a block order issue not quicktabs issue.