Add a user-defined "required" indicator to tabs containing required fields

This is a javascript-only solution; I think that's appropriate since we want the module behavior to devolve gracefully if JS is disabled.

Thanks lesmana.

It worked in FF3 and Chrome, but it doesn't work in IE7 on XP for me.

A little debugging. For a required field,

$(this).attr('href')

returns "group_required" for a required field in Chrome (strips off the # sign)
returns ttp://domain.com/node/10/edit#group_required (strips off the h)

In other words, lets say the fieldset is named 'stuff', in IE, $(this).attr('href') evaluates to the http://example.com/node/1/edit#stuff or http://example.com/node/1/edit#group_required, whereas it Chrome and FF, it evaluates to simply #stuff or #group_required.

I'm not sure if this should be added, since the core version (#323112: Vertical Tabs) does not include this functionality. I'm open to discussion on the matter though. Either way this patch needs some work as per #3.

quicksketch: I think the 6.x functionality that allows custom CCK fields and fieldsets to be rendered as Vertical Tabs makes this issue relevant to this branch, as opposed to the 7.x core version in which (AFAIK) none of the fields in the default vertical tabs are required.

That said, the approach I took in the patch above isn't exactly elegant, so if anyone else wants to take a shot, have at it.

Here's another go at the patch in #2, with more processing of the 'href' attribute to account for browser differences. It should work in all cases now. Doing it this way seems like a workaround to me still, though. If the new branch to be backported from D7 still includes the option to render CCK Field Groups as Vertical Tabs, this issue should be reworked from scratch.

EDIT: oops. don't use this one. Use the one in #10.

I get popups for each group that I have defined regardless of wheather it is a manditory field or not.

activelyOUT: what browser are you using?

firefox

oh, whoops, I see what you're saying. That was stupid of me. Here's the same patch as #6 without the JS alert boxes.

After running into this frustration a few times, I have to agree, it's important. Let's start here, but make sure that Drupal 7 gets this same feature (it'd be a shame to *loose* functionality in Drupal 7). We should also also activate tabs when they contain form errors, but let's tackle that separately.

Is asterisk actually good for this ?
For field it is obvious and is established UI pattern, but for tabs ?

Some time ago I investigated different UI patterns and there was 2 things to remember
1) Using "(required)" after brief description of field is good and established pattern
2) If there are many required and few are optional, putting (optional) after optional fields is better.

Can this be made themable so we just put asterisks by default and let user decide what's more convenient to him ?

The patch as it is currently does *not* actually require the use of an asterisk. It will scan the contents of the field for anything that contains <span class="required"></span>, then duplicate that span (and its contents) and put it on the tab. So if the convention on the site uses "(required)" next fields, the tabs will contain the same string. I think it's a good approach generally.

In the rare circumstance where users have taken the effort to theme form elements so that they contain "(optional)" (and I note this is very, very, very rare in the Drupal world) instead of an asterisk for required, they can still get the same effect if they wrap the text in a span with the class "required". It'd be a somewhat backward class name of course, but I have to reiterate that's an extremely rare situation. If Drupal provided a better mechanism for specifying which fields were optional with a property like #optional = TRUE, then it'd be worth another condition to check for another span class, however there's no standard on this because generally forms in Drupal don't ever use that approach.

I'm definitely not arguing the practices that sometimes an asterisk is not sufficient or that specifying fields as "optional" is more appropriate than marking required (it really often is), but instead that those issues are general core problems, and not something specifically affected by this patch or Vertical Tabs.

Edit: Added <code> tags around the span.

Patch no longer applies.

Revised title to more accurately reflect intended action as described in #13.

Hi,

I would really enjoy to have an asterisk for the required fields, This is definitely a very good idea.

But I looked into you patch and I don't know where I should paste it in vertical_tabs.js... (I don't know Javascript at all...)

Could you tell me how to implement this patch ?

Thanks a lot if you can !

Here's a rewrite of the patch against the current dev release. The basic principles described by quicksketch in #13 are the same. Since I was poking around in there anyway, I also put in tab activation for validation errors, per #11.

this path does not work with the new revision (beta 7) of vertical tabs using forms.

a tried the patch, and it fails :(

The patch in #17 last applied to beta5. I don't have the time to keep up on this one, so I'm unassigning myself for now.

[incorrect js file for beta7, check next comment for correct one]

correct file for beta7

is this proper patch format? I get

patch -p0 < vertical_tabs.js__0.txt
patch: **** Only garbage was found in the patch input.

@SocialNicheGuru - that is not a patch, that is a ready js file that you can replace in vertical tabs module folder. (vertical_tabs.js - rename to that name)

Dohhhhhhh!

Seems to work :)

I need an actual patch file to review.
http://drupal.org/patch/create

patch for the latest dev version

formatting was fixed a little bit in this one:

works fine for me! thank you.

marking as RTBC since others tested as well in previous posts and it seems to work for them too.

@Dave: I think this would be a great addition to the module. Can you please take a look now that there is a patch?

Dave, ping?

...did I mention this still works like a charm in latest dev?

An update please?

I hate being the one that is busting b@@ls here (this makes it my 5th post asking the same thing), but the patch in #31 is working fine since like more than half a year now. I am aware that everyone is focusing in d7 and trying to solve issues in order to get it out soon, but can we hope this will be in with the next build?

subscribe - please don't abandon those of us who have D6 production sites.

Suscribing

git-formatted re-roll of #31 against 6.x-1.x-dev

Patch still applies… with slight offset. Do we need to re-roll this?