Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
The tabs are loaded by the callback function you list when you call magic_tabs_get().
The callback, upon being called, creates the full set of tabs (titles & content, with designation of the active tab) - and that is being sent back to the browser.
This is done mostly for reasons of simplicity - both for this module's code, and for the callback implementation.
Hmm. So it's supposed to be that if I have, let's say, 10 tabs - all tabs are executed at the beginning, and then once I click tab #3, all tabs are executed once again, et cetera?
The main reason for this is simplicity. I didn't know how this module would develop, and I am open to discussion here. In my case, I found this is an acceptable overhead, YMMV.
Can you please provide more information about your case, why you need individual tab loading, and whether you think this would serve other users as well.
In many cases it is an acceptable overhead, but for a higher traffic site with lots of tabs it could be an issue. Being able to have tabs load individually on each click, or in the background, would be a *huge* improvement for those situations.
What is the benefit of using this over something like JS tools tabs? It seems it's even more overhead since it's loading each tab instead of just the once and hiding them but over and over again on each tab being activated.
For example, I have tabs that are from A - Z and load content based on that. That's a lot of load. :)
I'd be interested in what other people think. Ideally, I think it'd be nice to have options for this sort of thing. I've been looking at possible ways of implementing it.
I think I will implement it by adding a paramter for the callback, that will be the active tab number.
your callback will then have to return the same tab structure as before, but only the content of the active tab will be displayed - so you can leave 'content' empty for all other tabs. You will still have to render their titles, as they are still visible regardless of the tab clicked.
If you will not want to implement this optimization, simply ignore this paramter and render all tabs every time.
That sounds great, though I'm a little unclear on a couple things. magic_tabs_get() already has an $active parameter which is the tab number (or first/last), so if you mean adding another parameter to that it might be confusing.
This sounds great, though! Can I have it by tomorrow? Just kidding. :P
Allright, I had some spare time and created this patch. I haven't tested it enough, so not committing it yet.
However, you said something about tomorrow, no?
Please test - you can see the change in the example function and learn from that how it works.
This is great! I'd like to go a little further and allow for multiple parameters, though. I think this patch just changes call_user_func to call_user_func_array
I actually have no idea what I was doing last night (kids, don't try to code on very little sleep). Anyway, I think this is good but does require a lot of handling. What about instead having another parameter on magic_tabs_get to do this automatically? What do you think?
Comments
Comment #1
brenda003To be more clear, with Devel on I see that all the queries are happening for all the tabs.
Comment #2
yhager commentedThe tabs are loaded by the callback function you list when you call magic_tabs_get().
The callback, upon being called, creates the full set of tabs (titles & content, with designation of the active tab) - and that is being sent back to the browser.
This is done mostly for reasons of simplicity - both for this module's code, and for the callback implementation.
Comment #3
brenda003Hmm. So it's supposed to be that if I have, let's say, 10 tabs - all tabs are executed at the beginning, and then once I click tab #3, all tabs are executed once again, et cetera?
Comment #4
yhager commentedWell, yes, that is how it is implemented now.
The main reason for this is simplicity. I didn't know how this module would develop, and I am open to discussion here. In my case, I found this is an acceptable overhead, YMMV.
Can you please provide more information about your case, why you need individual tab loading, and whether you think this would serve other users as well.
Comment #5
brenda003In many cases it is an acceptable overhead, but for a higher traffic site with lots of tabs it could be an issue. Being able to have tabs load individually on each click, or in the background, would be a *huge* improvement for those situations.
What is the benefit of using this over something like JS tools tabs? It seems it's even more overhead since it's loading each tab instead of just the once and hiding them but over and over again on each tab being activated.
For example, I have tabs that are from A - Z and load content based on that. That's a lot of load. :)
I'd be interested in what other people think. Ideally, I think it'd be nice to have options for this sort of thing. I've been looking at possible ways of implementing it.
Comment #6
brenda003Comment #7
yhager commentedI can definitely see your point.
I think I will implement it by adding a paramter for the callback, that will be the active tab number.
your callback will then have to return the same tab structure as before, but only the content of the active tab will be displayed - so you can leave 'content' empty for all other tabs. You will still have to render their titles, as they are still visible regardless of the tab clicked.
If you will not want to implement this optimization, simply ignore this paramter and render all tabs every time.
What do you think?
Comment #8
brenda003That sounds great, though I'm a little unclear on a couple things. magic_tabs_get() already has an $active parameter which is the tab number (or first/last), so if you mean adding another parameter to that it might be confusing.
This sounds great, though! Can I have it by tomorrow? Just kidding. :P
Comment #9
yhager commentedAllright, I had some spare time and created this patch. I haven't tested it enough, so not committing it yet.
However, you said something about tomorrow, no?
Please test - you can see the change in the example function and learn from that how it works.
Comment #10
brenda003This is great! I'd like to go a little further and allow for multiple parameters, though. I think this patch just changes call_user_func to call_user_func_array
This is very very handy!
Comment #11
brenda003Oh wait..ignore that last patch. I'm way too sleepy right now, I had this working a minute ago. Will look at it in the morning.
Comment #12
brenda003I actually have no idea what I was doing last night (kids, don't try to code on very little sleep). Anyway, I think this is good but does require a lot of handling. What about instead having another parameter on magic_tabs_get to do this automatically? What do you think?
Comment #13
yhager commentedAnyway, I think this is good but does require a lot of handling.
Why? Your callback should work thte same as before, only you don't have to render the inactive tabs' content.
What about instead having another parameter on magic_tabs_get to do this automatically?
To do what? Please elaborate.
Comment #14
brenda003Hmm, don't you need to check if each one is the active tab, though? Or am I misunderstanding?
Comment #15
brenda003This patch works well. I'll start a new thread for any additional requests.
Comment #16
yhager commentedCommitted. I updated the README with an additional example.
Comment #17
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.