Collapsiblock v2 for Drupal 7 [#1186198]

I've created a sandbox module to test my changes to the collapsiblock module. http://drupal.org/sandbox/j0rd/1186184

I've used this module once before in Drupal 6 and while it worked pretty well, it had some problems which arose from it doing everything on the client side.

In my version some of the logic is moved to the server. This helps in sure blocks which are supposed to be closed by default, don't show a flash of "open" when loading the page.

Additionally I've changed around how the classes work. This makes themeing a little easier.

Each collapsiblock will have some of these classes
.collapsiblock (every block)
.collapsiblock-collapsed (for blocks which should be collapsed)
.collapsiblock-cookie (for blockk which we'll keep state of via cookies)

I've also re-factored the code a little, so less cookies are being saved to store state.

There's still some bugs if you turn the default collapsiblock state to something other than "do nothing". But other than that, it appears to work fine.

Test it out and let me know.
http://drupal.org/sandbox/j0rd/1186184

Comments

Comment #1

gagarine CreditAttribution: gagarine commented 12 June 2011 at 22:44

I didn't read your code right now but just want to let you know than I appreciate your work.

About the server side... I don't know if I like it (again I didn't read the code, I will). It could be a problem with reverse proxy and cache. What do you think? For me it very important than the page doesn't need to be generated for each request.

The CSS class is a cool idea.

Did you write it from scratch? Or did you start from the 7.1 version?

Thanks

Comment #2

gagarine CreditAttribution: gagarine commented 12 June 2011 at 22:52

LOL ok I was too curious so I check it and I like it. But how you say we need some test.

Do you want to be a co-maintainer? You can work on the branch 7.x-2-dev

Regards

Comment #3

j0rd CreditAttribution: j0rd commented 13 June 2011 at 09:42

While I could read the cookies on the server side and output the proper collapsed or non-collapsed blocks in the HTML, I chose not to do this because of the caching issue you mentioned. It would break Drupal when it comes to anonymous surfing. Instead I simply check the cookies on the client side (js+cookies) to see if the visitors state is different than the default state, and if they differ, I update them.

I started off from your previous version. I just re-factored some of the code to make it a little cleaner and easier to read.

I'd gladly assist in becoming the maintainer for the 2.x branch.

Here are some features I'd like to add or remove.

#1.1 Have a region selector in the admin interface, like how the accordion_blocks module works, then only apply collapsiblocks to those regions. This will speed up the performance a little & it will make sure that admin type blocks (like in content top) do not become collapsed by default. Currently this fix is hacked in to the code in preprocess_block via `if($block->module = 'system') return;` . It needs to become more elegant.

#1.2 Remove the default state setting entirely. If a lot of people use this feature though, I suppose we could leave it in.

#2. Reduce the amount of cookies which need to get saved on the client side. Cookies need to get sent with every request from the client and the way the module works currently, it creates a lot of cookies. Multiple this by every user who ever visits the site and plays with a block and well, you're using a lot of extra bandwidth. We should only save a cookie if the default state differs from the current state. Additionally, we might also be able to use the block.bid as the identifier instead of block.module + block.delta. Although, I'm not sure if this is an accepted practice.

Any other suggestions are welcome.

Comment #4

gagarine CreditAttribution: gagarine commented 13 June 2011 at 11:05

You are now a maintainer :) welcome. So create a 7.x-2.x branch to work inside. Please write small commit and add the issue number in commit message.

#1 I'm for removing the default state. You need to set your state for each block but is not so long... If really peoples complain a lot we can still add an admin page than give an overview. We need to be careful about the upgrade path for this point.

#2 Using bid doesn't look "standard" for me. I don't know any other module than use that.

Comment #5

RobLoach

he/him

CreditAttribution: RobLoach commented 21 June 2011 at 19:18

Might be better to split your changes into a number of different feature issues instead of just one big 2.x change. Will be easier to maintain and migrate the features in...

Comment #6

kopeboy CreditAttribution: kopeboy commented 4 October 2014 at 00:40

Priority:	Normal	» Major
Issue summary:	View changes

Has this been included in this module, either v1 or v1 dev?

Comment #7

cindyr CreditAttribution: cindyr commented 13 October 2014 at 12:33

Maybe I don't understand clearly how it would work, but I'd like to vote to keep the default state. I'm adding this into my site after I've already created it. I want to make sure that 95% of my blocks don't collapse, but there are a special few that I would love to have collapse. That default state lets me rest comfortably knowing that the default is to not collapse, but I can select a few to do so.

Perhaps this functionality would remain the same (not implemented by default), but better documentation would ease my fears?