When one enables the 'Expose vertical tabs selection on the edit content type forms' setting in Vertical tabs (../admin/settings/vertical-tabs), there is a tab called 'Vertical tabs' present in every content type edit page. Since vt_default has only a single setting for the name of the default tab, I think that it is a great idea (space-saving-wise) to detect if that Vertical Tabs' setting is enabled and then place our single setting in the same tab.

The default behavior of having our own 'Vertical tabs default tab' tab needs to remain for the cases when users do not enable the 'Expose vertical tabs selection on the edit content type forms' setting.

...setting it to minor (since people can live without this).

Comments

patcon’s picture

Assigned: Unassigned » patcon
Status: Active » Needs review
StatusFileSize
new1.58 KB

Was thinking the same thing. Give this a shot... Let me know if it works. Cheers :)

patcon’s picture

Oh hey, I know it's bad form to mix and match patch contexts, but just noticed that the package isn't given, and so vt_default shows up under "Other" and vertical_tabs shows up under "User interface".

Just updated the .info file so that they're together now. This also has the #1 patch rolled in.

klonos’s picture

Status: Needs review » Reviewed & tested by the community

...Works like a charm Patrick! Thanx.

With the 'Expose vertical tabs selection on the edit content type forms' setting enabled, the 'Name of Default Vertical Tab' filed is moved inside the 'Vertical tabs' tab. If the setting is off and thus no 'Vertical tabs' tab is available, then the 'Vertical tabs default tab' tab comes to hold the setting (fall back to default behavior). Minor but brilliant improvement!

As for the extra touch in #2, did you know that there is an issue for that? Here it is: #844918: move the module from the generic 'Other' package category into the 'User interface' category (same as Vertical Tabs). Perhaps you should move it there (solely for the procedural purposes and in order to keep the maintainer sane).

Once again, thank you Patrick for your time and effort on this ;)

PS: I am rushing to RTBC this, since it seems simple enough and in order to gain Andrey's attention.

klonos’s picture

...done it for you Patrick 9+ gave proper credits ;)

klonos’s picture

One minor wish/improvement on this ...if it is easy to be implemented I mean. Can the 'Name of Default Vertical Tab' field somehow be grouped with the 'Default settings' checkbox in the list? That would allow the filed to be grayed out if the checkbox is unchecked and be editable only if the checkbox is enabled. It does make sense, doesn't it? One final touch to perfection ;)

crea’s picture

There's one problem related to this patch: Vertical Tabs module had versions which didn't have control for the forms, and I want this module to be compatible with all versions, including old ones (I use one myself). That's why it's good to have a separate configuration fieldset (tab) and not rely on presence of VT configuration fieldset.
So I think about this feature as something that increases complexity without significant payoff.

patcon’s picture

Thanks for the comment crea.

I'm not sure I understand, but I still have yet to look over the legacy code. I get that it's a little more complexity in the logic, but isn't it less complex from the end-user UI standpoint (which is the angle most will see it from)? Anyhow, obviously it's up to you, but let me know if it's just a matter of cleaning up the logic. I'm just starting to submit patches after years of avoiding it, and I'd love to contribute something that's worth committing :)

klonos’s picture

@crea: do you know which versions of VT don't have control for the forms? Perhaps we could check for these cases and once again fall-back to default behavior. I mean, it would be a shame to not push this improvement in.

@patcon: Hey Patrick, do you think that if we solve the issue Andrey is mentioning in #6 and move on we could also implement what I propose in #5?