Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
From an end-user perspective, I would like Drupal to remember which page sections I have (not) collapsed, so that the page layout remains the same after I, for example save the settings.
Currently, after having saved a settings page or after having browsed from and to a settings page, all page sections are intracted again. I would like to have them the way the are. Is it possible to store this information in a cookie / session?
Comment | File | Size | Author |
---|---|---|---|
#12 | drupal.storage-collapse.12.patch | 9.02 KB | dmitrig01 |
#11 | drupal.storage-collapse.11.patch | 9.01 KB | dmitrig01 |
#7 | drupal.storage-collapse.7.patch | 8.92 KB | sun |
Comments
Comment #1
cosmicdreams CreditAttribution: cosmicdreams commentedI remember requesting the same feature for the Block bar module. I believe they are still working out a bug on that. Given our renewed interest in the user experience, I think it important that we take another look at this feature.
Comment #2
Sutharsan CreditAttribution: Sutharsan commentedMoving the issue from User experience project to Drupal core usability component.
Comment #3
cosmicdreams CreditAttribution: cosmicdreams commentedThis seems to be handled by: http://drupal.org/project/fieldset_helper
After things approach a Release candidate phase (or earlier) this module can be migrated to Drupal 7.
I'm marking this as won't fix, since this feature request seems to be handled by the module I listed and therefore will not likely be implemented for Drupal 7.
Comment #4
cosmicdreams CreditAttribution: cosmicdreams commentedforgot to add Usability tag
Comment #5
yoroy CreditAttribution: yoroy commentedContrib is where new core functionality often starts, so that in itself is not a reason to won't fix. It would be a very nice thing for core to provide out of the box so that any contib module can benefit from it too. Bumping this to Drupal 8 then
Retitling this and marked #176168: remember collapsed module sections a duplicate. Thanks cosmicdreams for the issue cleanups.
Comment #6
cosmicdreams CreditAttribution: cosmicdreams commentedNo problem, Trying to get that "inbox" cleaned up.
Comment #7
sunheh, holy cow. Cool probably cuts it.
Most of this patch is just moving some lines around.
Drupal.settings.q is something I probably could have used hundreds of times in contrib and custom sites already.
Drupal.storage, as added to drupal.js in this patch, is a very nice way to store and read such settings from the client-side. Modern browsers only, but that's perfectly acceptable exactly for features like this. Drupal.storage, itself, also shapes and introduces a common "interface" (similar to our Drupal interfaces in PHP), for which the API function signatures are set in stone, but the underlying storage functionality can be replaced (like any other JS function).
Comment #8
kscheirerThis patch only remembers fieldsets that should remain open, like on admin/structure/taxonomy/tags/add. It would be nice to remember which ones I want closed as well (hello admin/modules!).
But the patch works as advertised, and it's a good idea to have an interface around using the new window storage stuff in html5, so RTBC from me. Might want to add some developer docs, so they know roughly which browsers this is available for. Any interest in providing cookie-based backup storage?
Comment #9
sun#7: drupal.storage-collapse.7.patch queued for re-testing.
Comment #10
sunComment #11
dmitrig01 CreditAttribution: dmitrig01 commentedHow about this? I abstracted out the things that each function had in common. In addition, I switched the arguments of .save, so key and bin stick together. Not sure if this is a good thing or bad thing, simply an alternate.
Comment #12
dmitrig01 CreditAttribution: dmitrig01 commentedfixed two little errors.
Comment #13
sunI've completely revised the Drupal.storage code over in #910636: Use HTML5 features instead of GreaseMonkey and heavily advanced on it last night.
@dmitrig01: I think we should prepare such an API during D7 for contrib consumption and potential inclusion for D8. How about moving the current incarnation into Edge so we can join forces to come up with a bullet-proof and rock solid API for D8?
Comment #14
yoroy CreditAttribution: yoroy commentedneeds git patch
Comment #15
cosmicdreams CreditAttribution: cosmicdreams commentedLooks like a lot has changed since the patch in #12 was made, but the essential point seems to be that we need to store $_GET['q'] so that Drupal.settings can access it later while evaluating in the javascript whether a fieldset should be collapsible. The approach seems to rely on localStorage to persist the collapsible state.
cross referencing with #1172670: Evaluate standardized usage of HTML5 Storage API through a library
Comment #16
Crell CreditAttribution: Crell commentedThis seems like something that could be implemented 100% client side with localStorage. That would make far more sense to me than messing around on the server at all.
Comment #17
cosmicdreams CreditAttribution: cosmicdreams commented@Crell cool, that was my instinct as well but didn't know it was right. I'll put this on my tracking list and try to touch on it next week.
Comment #18
sunThis patch uses localStorage already. Please look at the latest patches first.
An improved version of the Drupal.storage helper exists in Dreditor. However, even though I authored it, I can't believe that we have to invent such a helper on our own. I'm sure that there must be something in latest jQuery core or some jQuery plugin that provides such a facility. For Drupal core, I'd like to see us using a standardized library.
That should be figured out in #1172670: Evaluate standardized usage of HTML5 Storage API through a library first. Thus, postponing on that.
Comment #19
nod_Let's just use localStorage with no wrapper, let's talk about introducing more code when there is a working patch in here.
Comment #20
nod_Is there a compelling use-case for this?
Comment #21
nod_Closing since #1168246: Freedom For Fieldsets! Long Live The DETAILS.