I am using Collapsiblock 7.x-1.0 with Views 7.x-3.0-rc3.

I created three Views and display all three on a specific Basic Page as Collapsiblocks, configured through admin/structure/block to display in the Content block on that node. These Collapsiblocks work perfectly.

Then I created three other Views and tried display these three on a different Basic Page following the same method as before. For some reason, these three views do not collapse. They appear as regular Blocks but I cannot find out why they do not behave as the first ones do. These Views and Collapsiblocks are configured the same as before. I even tried cloning one of the original Views and that clone won't collapse. Am I missing something?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

zorax’s picture

Subscribe!
I use view, when you exposed filter in a block, then in the configuration block you select to collapse, there's no result...

finedesign’s picture

I'm having a similar issue.
I created a view block that is also an exposed filter, and collapsiblock does not work when I select it in the block config.

HOWEVER...
When I change the global collapsiblock defaults to anything other than none, they work. Even on the block above.

I don't want the default behavior to be anything other than "none" because I only need one block to collapse.

fraweg’s picture

Hello,

I created a view block that is also an exposed filter, and collapsiblock does not work when I select it in the block config.

For me its the same..

HOWEVER...
When I change the global collapsiblock defaults to anything other than none, they work. Even on the block above.

This changes nothing for me :-(

Can anyone help?

Best regards
Frank

Edit: Ohh I nee a header..after that it works but does not respect the value "Collapsible, collapsed by default"

shwx’s picture

Priority: Normal » Major

Subscribe!

ditcheva’s picture

Same for me... when the 'global setting' at Administration » Configuration » User interface is set to something other than 'none', the expected behavior works for my individual blocks.

But of course, this is a problematic solution, I want my default behavior to be 'none' and for me to enable collapsibility only for certain blocks. As soon as I set the default global behavior to 'none', I can't get collapsible blocks even when I set their individual settings appropriately.

ditcheva’s picture

FileSize
795 bytes

I just figured it out. It actually looks like a fix for this exists in the git repo, but not in the dev or stable versions yet.

The issue stems from the fact that the block's html id that the module uses is converted to lowercase when it goes through this function: http://api.drupal.org/api/drupal/includes!common.inc/function/drupal_htm..., while the module was not converting the id it was storing to lowercase, and so it wasn't finding/matching the settings for those blocks that had uppercase letters in their id's (such as apachesolr facet blocks in my case)!

In any case, I'm attaching a patch to fix this. Yay!

fasdalf@fasdalf.ru’s picture

Thank you, ditcheva! It solved my problem with Facet API too.

Anonymous’s picture

Version: 7.x-1.0 » 7.x-1.x-dev
Status: Active » Reviewed & tested by the community

Yes, that works. Please push/commit to stable/dev...

Lendude’s picture

Want to confirm that this also solved the issue for me too (Facet API also)

GiorgosK’s picture

#6 Its not working for me :-(

gagarine’s picture

Status: Reviewed & tested by the community » Needs work

Need an update path.

ianthomas_uk’s picture

Status: Needs work » Needs review
FileSize
849 bytes

Here is an updated patch.

This one does both the str_replace and the drupal_strtolower on the whole id, which I think is easier to read and ensures any uppercase characters in module names are also caught.

semei’s picture

It's not working for me. I would like to make an exposed form block collapsible.

Anonymous’s picture

I had the same problem, and didn't try the patch (was it submitted by now?). I had done several views creating a block, and they worked fine with collapsiblock. Then I did another view which also puts out a block, but which for some reason is not picked up by collapsiblock. However, it is being picked up when the global default is set to something other than 'none'.
But as mentioned by ditcheva in comment#6, enabling collapsiblock by default is problematic (but also worked in my case).
My workaround is to use the block_class module and to add an additional class to the blocks I want to get picked up by collapsiblock (which I called 'collapsiblock_enabled'). This one I put into collapsiblock's div for all themes (custom css classes), and then could set the collapsiblock default to 'collapsed by default'. As collapsiblock now only picks up blocks with the class 'colapsiblock_enabled', it doesn't cause havoc with other blocks on the site. Works - but still a workaround.

marcoka’s picture

ok got it too. it seesm collapsiblock picks up wring ids for its settings array. i added an image that shows it.

the class in the settings array has a "--" and the normale id has only "-"

marcoka’s picture

Issue summary: View changes
FileSize
83.67 KB

you can add this to function collapsiblock_submit right after $settings = variable_get('collapsiblock_settings', array());

 //fix double -- bug, if delta starts with "-", remove it
  if(substr($form_state['values']['delta'], 0, 1) == '-') {
    $form_state['values']['delta'] = ltrim($form_state['values']['delta'], '-');
  }

this would remove the - if the delta starts already with a -foo-name. as in some cases of views exposed filters.

R13ose’s picture

Unless I need to clear cache, none of the above is working for me. I have tried all the patches and code that has been written. I have used the stable and dev versions of this module and views 7.x-3.7.

I am doing this for a taxonomy block (term) and the id is: block-views-taxonomy_block-block which is a view. This also picks up: collapsiblock-processed for the class when I use this on my site. I have tried all the settings in this module and views without anything happening.

marcoka’s picture

well i discovered that views does the following.

sometimes the "machine name" you get from $form['delta']['#value'] could be one of the following

foo--bar-baz
foo-bar-baz
foo--Bar_baz-foo

that is actually why some views blocks do not work properly.

R13ose’s picture

If that is the case, how do we catch all the different cases in the code? This is important as views become more popular going forward.

pagach’s picture

has anyone solved this problem yet?
for me Collapsiblock works, it's just the default state that doesn't work (for some blocks)...

ñull’s picture

I manually applied patch #12 to the present date dev version and it fixes the issue for my views block display. In fact it was a block with taxonomy terms like ShawnRisk mentioned before.

To be on the safe side I would after patching, disable and de-install the file to remove old stuff from the Drupal settings table. In my case the old erroneous array entry did not break anything, but I like things clean.

May be inexperience but still keep thinking if there isn't another way to get the exact same string as used in the id? Why trying to reinvent the wheel to find a code that does exactly the same as the code that produced the id? Has somebody been running this through a debugger and checked whether this id exists already in some form somewhere in a variable that we could use? Or can we run the same theme code to get it and use it in the settings?

steeph’s picture

Apparently, after applying the patch, you have to go to the bock edit page and save the settings again. Now the patch works for me. Thanks!

shaisamuel’s picture

Here is the same #12 patch, but fixed, so it can be applicable.

But unfortunately, it didn't solve my problem. I did apply it, uninstalled and reinstalled the module, removed the block that was created by views, and recreated it using views, and set it up. IT works fine in the views preview, but not when used in views or even as a simple block.

After all, I what suggested in #1937552#6: added block.tpl.php with the code mentioned. And don't forget to clear all cache.

AlfTheCat’s picture

patch #23 applies but in my case too, doesn't solve the problem. After setting the general collapsiblock settings to something other than "none", I do get views blocks to become collapsible after editing and saving the individual block settings, however, the settings are not respected when I set them to be collapsed by default. Regardless of the block or global settings, they are always collapsible, expanded by default.

kulbhushan’s picture

Here is an updated patch.

This one does both the str_replace and the drupal_strtolower while showing the default value in block settings.

codium’s picture

#25 still not work for me when I want to collapse by default block with exposed filters form. Block title isn't clickable also.

pebosi’s picture

Be sure to set correct css selectors in your theme settings.

litzastark’s picture

This is a helpful patch, thanks! I had one additional problem with setting up collapsible blocks on an exposed view filter. The view happened to have a '-' at the start of its ID, and since collapsiblock was constructing the ID using [module]-[delta], it ended up with a block ID of [module]--[delta], whereas the actual ID reduced those double dashes to a single dash. I added a str_replace('--', '-', ...) around the final block ID in order to get it working.

AlfTheCat’s picture

#25 works on exposed view filter blocks :) Thanks!

pinueve’s picture

+1 to #25, it works on facets (search-api).
for bootstrap sub-theme follow instrucions on https://www.drupal.org/node/2676932, works perfect, thanks!

darvanen’s picture

Component: Miscellaneous » Code
Status: Needs review » Needs work

Re #25:

+++ b/collapsiblock.module
@@ -136,8 +136,8 @@ function collapsiblock_form_alter(&$form, $form_state, $form_id) {
+    if (isset($settings['block-' . str_replace('_', '-', $form['module']['#value']) . '-' . drupal_strtolower(str_replace('_', '-', $form['delta']['#value']))])) {
+      $default_value = $settings['block-' . str_replace('_', '-', $form['module']['#value']) . '-' . drupal_strtolower(str_replace('_', '-', $form['delta']['#value']))] ? $settings['block-' . str_replace('_', '-', $form['module']['#value']) . '-' . drupal_strtolower(str_replace('_', '-', $form['delta']['#value']))] : variable_get('collapsiblock_default_state', 1);

Good work here but these lines are incredibly long. If we're changing them in this patch I think 140 should use a couple of .= to fit within the 80 char line limit and 141 at the very least needs to be an if/else block instead of a ternary operator.

darvanen’s picture

More discussion here, closing the other ticket that addresses this.

darvanen’s picture

Status: Needs work » Needs review
FileSize
1.17 KB
darvanen’s picture

Note to self: credit @detroz for related code from #2491357: Block configuration not saved.

darvanen’s picture

FileSize
1.19 KB

Rerolled patch on 7.x-1.x.

sonvir249’s picture

Hi @Darvanen,

Changes added as suggested.

Thank you.

  • sonvir249 committed b5fe263 on 7.x-1.x
    Issue #1371972 by sonvir249: Views collapsiblock id cases
    
sonvir249’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.