"Collapsible, collapsed by default" does not work
| Project: | Collapsiblock |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Hi,
I am trying to get Collapsiblock to work. Everything goes smoothly, except for the "collapsed" states, at each of blocks settings and at the default setting. Here is what in detail happens: when I set default state for the blocks "Collapsible, expanded by default", everything is OK -- blocks are collapsible. Exactly the same thing is produced by the "Collapsible, collapsed by default" setting -- every block is collapsible, however expanded. The same happens, when I set "Default block collapse behavior" to "None" and try to tinker with each one of the block's collapse settings -- both "expanded" and "collapsed" produce "expanded" state.
I can provide additional information, but I have to know what exactly.
Regards
PS. Nice work! Exactly what I needed.
Clawz

#1
Sorry to bother you. I just discovered, that browser remembers my previous settings of collapsed or expanded blocks. NAvigating through the site leaves blocks at the previous states.
Maybe this is something worth looking into: control over making blocks to return to default collapse setting (expanded or collapsed) when page is refreshed?
So I am changing this into "feature request". :D
Regards!
Clawz
#2
#3
Subscribing...
I think it cannot be a feature request...
#4
I had a js developer tweak one of the files in the module, and it now works very well for me. I'm attaching it to this post, perhaps it can be of use to someone else (my current version is 6.x-1.x-dev).
#5
Thanks for posting your suggested change. Could you please explain what the patch does, and what changes after it is applied?
#6
Attached is a screenshot of the original and modified files. I'm not a js programmer, so I'm not sure how, but the new version fixes this ticket and does a better job of remembering the block's collapsed/expanded state, and will also allow for cookies to remember the users collapsed/expanded setttings. Works well and has greatly improved the look of my site. Contact me if you want to get in touch with the developer who did the work.
#7
Thanks for following up.
However, please consider the following.
Like dozens of other modules that I wrote and maintain as a volunteer, collapsiblock is something I put together years ago as a volunteer, have never been paid to do any work on, and have never used on a site.
This issue is only one of many that I deal with every week.
You have hired a developer to fix an issue. What makes more sense: that I should need to track down that developer and try to get an explanation of what he did and why?
Or that you should think of getting the fix into the software as part of - in fact, the main purpose of - hiring a developer? And, yes, part of the cost. If for no reason, so that, when you upgrade to a new release, you don't need to reapply a patch every time.
If the developer's work ends the moment you have a hack that "works" on your site, you're missing a lot of the point and the benefit of open source.
If you want a patch that you submit to go in, please take the time to do the small amount of additional work that is required to make that possible. Thank you.
#8
Again, thanks for the contribution. I'll be happy to review the patch if someone can provide some explanation.
I've added a section to the handbook page on hiring a Drupal developer with suggestions on how and why to contribute back:
http://drupal.org/node/51169#contribute-back
#9
Hi nedjo, I've made some changes I wanted and included a patch. The first change adds a fourth option to the existing settings, which sets blocks to be always collapsed rather than remembering the state with the cookie, as per the feature request.
I've also added another couple of settings which deal with the animation of the block. You can choose whether you want blocks to slide open as before or use a fade and slide effect. You can also set the speed of the effect. Both these extra settings are globally set in the admin settings page.
I haven't done any validation on the speed entry field and I'm guessing that the script could get broken easily by entering something other than a number here.
Let me know if you need any more info on the patch.
#10
Thanks for the helpful link nedjo.
#11
Thanks Tanc and Vote_Sizing_Steve.
I've committed Tanc's changes in full--nice work!--worked in something drawing on the fix from Vote_Sizing_Steve, and refactored the cookie handling to address #345684: too many collapsable blocks causes the user to be logged out.
Leaving the status at needs review because I'd appreciate some confirmation that the issues are now addressed. With that in place I'll issue a new stable release.
Thanks all.
#12
Thanks for committing my patch nedjo. Unfortunately something seems to be broken with the new CVS version. It looks like its a problem with the cookie in passing it the JSON string. I'm getting a 'Data is NULL' in my js console which hoses all the other javascript in the site. I've set a breakpoint and I'm pretty sure that its the 4th line of the collapsiblock js that's causing it although that's as far as my debugging knowledge goes. I've tested this on a live site and to be sure on a fresh Garland based install.
Any ideas?
#13
@Tanc: Thanks for testing. I've applied a follow up patch to ensure we have cookie data before trying to parse it with Drupal.parseJson(). I think that should solve the issue, but more testing of that and the rest of the patch would be great.
#14
haha, nedjo, your timing is impeccable! I had just fixed the issue (with less elegant code) and was about to roll a patch. Testing yours and everything is fine. I've deleted the cookie and no longer have the null data issue. All good from here!
#15
Seems to be working.
#16
strangely, on my site every setting results in all blocks being open at outset, and state being remembered.
is there any info that would be helpful to reproducing?
I've just upgraded to d6.8 and simultaneously upgraded to the dev version of collapsiblock available yesterday. Ran update.php a few times. Deleted all cookies a few times. Tested in IE7, Chrome, Firefox (mac & pc) and Safari (mac). Using Zen subtheme, fwiw.
Collapsiblock is set to 'collapsed all the time,' and I've tried several of the settings, but always get all open at outset, and state remembered. Before the upgrade, all blocks were closed at outset and state remembered.
hope this bug report is of use....
#17
Thanks for the report.
I would so appreciate someone taking the time to look at the code and address this issue.
#18
I'm seeing the same issue as #16, using the current dev release.
#19
@grendzy - what theme are you using?
are others seeing things work with a given theme?
#20
I'm using a custom zen sub-theme.
I switched to Garland, just for testing -- and I'm still seeing the same thing. "Expandable, collapsed by default" has no effect. I made sure to clear all my cookies too.
#21
Here is a patch from cyberpunk in #375215: "collapsible & collapsed" setting doesn't work
This patch works for me!
#22
similar issue: #232332: QT Always not collapsed
#23
I can confirm that the patch @ #21 works for me too.
#24
I confirm patch from #21 works for us too. Tested on Firefox 3.0.13 and IE 7.0.5730.13.
Thanks.
#25
I'll also confirm that the patch posted in #21 works perfectly.
Blocks that would previously start opened, even though they were specified to start closed, now start closed but still remember their last opened/closed state.
Tested in Google Chrome and Firefox.
#26
#21 patch works for me.
Nedjo, please commit ASAP! This is a basic, silly bug.
#27
Can we please have a stable version released - if the problems have been "patched up" (I hope this is the acceptable way of making such a request)
#28
Thanks, committed.
#29
Automatically closed -- issue fixed for 2 weeks with no activity.