I use Vertical Tabs and its addon module Vertical Tabs Default Tab that place the default fields (title, language, body & input format) in a tab (à la D7) and the other fieldsets in their own separate tabs (different ones for Menu settings, Authoring information, Revision information, Publishing options, URL path settings and so on).
The way it is now, the 'Location' fieldset in the node create/edit form is rendered along with the default node fields. When someone uses the above mentioned modules, this causes the 'Location' fieldset to be rendered in the default settings tab (the one provided by Vertical Tabs Default Tab). This in turn causes the tab to be really long when the 'Location' fieldset is expanded, which actually makes the use of vertical tabs lose its purpose.
I think that this could be solved if the 'Location' fieldset was rendered in its own collapsible fieldset (Vertical Tabs would pick it up automatically and place it in its own 'Location settings' tab).
Thanx in advance for considering this one.
PS: If I am wrong and this issue should be handled by the modules in question, please let me know so I can take it there.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | vertical_tabs_location.zip | 978 bytes | vlooivlerke |
| #12 | 859650-location-p2-D6.patch | 1.93 KB | kndr |
| #10 | 859650-location-kndr-1-D6.patch | 1.92 KB | kndr |
Comments
Comment #1
klonosI think this would provide a more solid solution rather than any hack provided in this issue #772766: Move the 'Location' fieldset in its own vertical tab (in the Vertical Tabs module's issue queue).
PS: it is strange how nobody else has commended here (judging by both modules' usage stats). Doesn't anyone else have a problem with this? I am really curious to see what others think on this one.
Comment #2
dnotes commentedHeh yes this is definitely an annoyance and yes I'd like it fixed... what I've done is a form_alter on node forms and move $form['locations'] to $form['location']['locations'], then unset the $form['locations'] and it works. But... it would be very nice if this could happen by default.
Comment #3
vlooivlerke commentedsubscribe
I have given up. Was a big Fan of Vertical Tabs, but a bigger fan of Location module. Now I use nodecolums.module to style my node form to make location look better. But vertical tabs would be nice
Comment #4
jp.stacey commented+1 for this. It sounds like it could be a straightforward fix from this comment on #354920: Support for location module (a.k.a Move the 'Location' fieldset in its own vertical tab):
(http://drupal.org/node/354920#comment-2438850)
Comment #5
jp.stacey commentedLooking through the codebase, the following pseudocode modifications in
location_form()would "fix" Location for Vertical Tabs. Try adding&& !module_exists('vertical_tabs')twice in the twoifstatements as follows:Note: I don't recommend this as the actual contrib fix, although it will work for you if you're happy hacking your own copy of the module! But these are the two "pinch points" where what Location does is just not correct for what Vertical Tabs wants to see.
The problem is that the UX suffers a little bit as a result, but maybe that's OK. Can anyone on the Location or Vertical Tabs projects help with suggesting the most reasonable behaviour for this code, without introducing a cross-dependency between the two modules? I hate using
module_exists()if I can avoid it.Comment #6
bryancasler commentedThanks for your work jp.stacey, I will use your hack for the interim. +1 For a proper fix.
Comment #7
yesct commentedper #5 adding a tag
Comment #8
barry_fisher commentedI came across this as well. Thanks to jp.stacy for his pointer. It led me onto this following solution for me. The locations key doesn't appear to get populated into the $form array at the point of a regular form_alter(), but it is after the form has been fully built- therefore I needed to enter the #after_build to perform the action I needed:
Hope that helps.
Barry
Comment #9
klonosThanx for sharing your solution Barry, but I would love to hear what the maintainer(s) think on this issue and perhaps provide a solid solution if they agree.
Comment #10
kndrTkanks for solutions #5 and #8. My method is different. No module_exists() but pure CSS is enough when code is modified a bit. I am attaching the patch.
Comment #11
kndrComment #12
kndrI've tested #10 and found one mistake. Class 'location' should be also add to single-location fieldset. Without this, some css rules don't work. I am attaching new patch.
Comment #13
klonosGive me some time to test this Konrad and I'll be coming back with feedback.
Comment #14
cameron tod commentedsubscribing
Comment #15
aaronbaumanSeems like patch in #12 does not add support for Vertical Tabs.
It may work for adding support for Vertical Tabs Default Tab, but I do not use that module.
Comment #16
kndrI am successfully working with Vertical Tabs and Vertical Defaul Tab after applying #12 for long time. Did you test this or just saying that it doesn't support Vertcal Tabs?
Comment #17
klonosPing? I'm working on D7 and trying to switch my other setups from D6 too. Any chance the maintainers will have a look at this?
Comment #18
vlooivlerke commentedHi here is a small module to put location in vertical tabs
Comment #19
castawaybcn commentedvlooivlerke's module works beautifully, thanks!!
Comment #20
monsoon commented@vlooivlerke
Can you please make this module available for Drupal 7?
I need this fix as soon as possible.
Thanks,
Comment #21
Berliner-dupe commentedFor D7 with this module you can move Location-Fieldset to vertical Tabs from "Field Group"
https://drupal.org/project/rel
Comment #22
legolasboClosing old D6 issues as D6 is end of life