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?
Comment | File | Size | Author |
---|---|---|---|
#36 | collapsiblock-id-cases-1371972-36.patch | 1.24 KB | sonvir249 |
Comments
Comment #1
zoraxSubscribe!
I use view, when you exposed filter in a block, then in the configuration block you select to collapse, there's no result...
Comment #2
finedesign CreditAttribution: finedesign commentedI'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.
Comment #3
fraweg CreditAttribution: fraweg commentedHello,
For me its the same..
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"
Comment #4
shwx CreditAttribution: shwx commentedSubscribe!
Comment #5
ditcheva CreditAttribution: ditcheva commentedSame 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.
Comment #6
ditcheva CreditAttribution: ditcheva commentedI 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!
Comment #7
fasdalf@fasdalf.ru CreditAttribution: fasdalf@fasdalf.ru commentedThank you, ditcheva! It solved my problem with Facet API too.
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedYes, that works. Please push/commit to stable/dev...
Comment #9
LendudeWant to confirm that this also solved the issue for me too (Facet API also)
Comment #10
GiorgosK#6 Its not working for me :-(
Comment #11
gagarine CreditAttribution: gagarine commentedNeed an update path.
Comment #12
ianthomas_ukHere 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.
Comment #13
semei CreditAttribution: semei commentedIt's not working for me. I would like to make an exposed form block collapsible.
Comment #14
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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.
Comment #15
marcoka CreditAttribution: marcoka commentedok 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 "-"
Comment #16
marcoka CreditAttribution: marcoka commentedyou can add this to function collapsiblock_submit right after $settings = variable_get('collapsiblock_settings', array());
this would remove the - if the delta starts already with a -foo-name. as in some cases of views exposed filters.
Comment #17
R13ose CreditAttribution: R13ose commentedUnless 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.
Comment #18
marcoka CreditAttribution: marcoka commentedwell 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.
Comment #19
R13ose CreditAttribution: R13ose commentedIf 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.
Comment #20
pagach CreditAttribution: pagach commentedhas anyone solved this problem yet?
for me Collapsiblock works, it's just the default state that doesn't work (for some blocks)...
Comment #21
ñull CreditAttribution: ñull commentedI 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?
Comment #22
steeph CreditAttribution: steeph commentedApparently, 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!
Comment #23
shaisamuel CreditAttribution: shaisamuel commentedHere 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.
Comment #24
AlfTheCat CreditAttribution: AlfTheCat commentedpatch #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.
Comment #25
kulbhushan CreditAttribution: kulbhushan as a volunteer commentedHere is an updated patch.
This one does both the str_replace and the drupal_strtolower while showing the default value in block settings.
Comment #26
codium CreditAttribution: codium as a volunteer commented#25 still not work for me when I want to collapse by default block with exposed filters form. Block title isn't clickable also.
Comment #27
pebosi CreditAttribution: pebosi as a volunteer commentedBe sure to set correct css selectors in your theme settings.
Comment #28
litzastark CreditAttribution: litzastark commentedThis 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.
Comment #29
AlfTheCat CreditAttribution: AlfTheCat commented#25 works on exposed view filter blocks :) Thanks!
Comment #30
pinueve CreditAttribution: pinueve commented+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!
Comment #31
darvanenRe #25:
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.Comment #32
darvanenMore discussion here, closing the other ticket that addresses this.
Comment #33
darvanenComment #34
darvanenNote to self: credit @detroz for related code from #2491357: Block configuration not saved.
Comment #35
darvanenRerolled patch on 7.x-1.x.
Comment #36
sonvir249 CreditAttribution: sonvir249 as a volunteer and at QED42 commentedHi @Darvanen,
Changes added as suggested.
Thank you.
Comment #38
sonvir249 CreditAttribution: sonvir249 as a volunteer and at QED42 commented