When certain content type is used as Content profile, not all the fields that belong to that content type are listed on 'Content profile' page, in 'Hide these fields during registration' section.

I don't know if it is a rule of some kind, but i have 2 different setups on different sites, and in both cases number of fields available to be hidden on registration page is 5.

Example of one setup:

I have created a content type ('Profile') for profile purposes with following fields/groups:
- group 'General', with fields 'Name' (Text field, required), 'Address' (Text field, not required), 'Birthday' (Datetime popup, using Date API, required) and 'Expertises' (Content taxonomy fields, multiple select, not required)
- group 'Misc', with fields 'Misc data 1' (Text field, required) and 'Misc data 2' (Content taxonomy fields, checkboxes, not required)
- field 'About me' (Text area, required)
- field 'Remarks' (Text area, not required)

I was thinking that any specified group or field in the original content type ('Profile') could be excluded in registration process. However, 'Hide these fields during registration' section lists only 5 items:
- Address
- Misc data 2
- Remarks
- Field Group: General
- Field Group: Misc data

Comments

sanja.tasic’s picture

I was wrong about the number of fields: it is not always 5, on another site this section lists only 4 fields/groups.

socialnicheguru’s picture

I am having the same issue

jeffschuler’s picture

Maybe your missing fields are marked as Required?

It seems that there is logic to remove Required CP fields from the Hide during registration list.

This logic makes sense, but would be more intuitive if all fields were listed in the Hide list -- but with Required fields as disabled checkboxes instead of removed entirely. Maybe a note explaining why they're disabled would help, too.

fago’s picture

Version: 6.x-1.0-beta3 » 6.x-1.x-dev
Component: User registration module » Documentation
Status: Active » Fixed

In the dev version there is an improved readme - update and check it out it should explain that.

jeffschuler’s picture

Category: bug » feature
Status: Fixed » Active

Not showing fields -- without an explanation of why they're not shown, (especially when it's easily depictable,) -- is non-intuitive, and I don't think the README is a complete solution here.

I can find the code in _content_profile_registration_get_field_select() that filters out required fields, but I'm not sure how to set the disabled state for individual checkboxes (the required ones) in this group. (Seems like #104715: Disable specific checkbox, radio, option, or optgroup items would help?)

fago’s picture

Category: feature » bug
Status: Active » Fixed

What is not clear about that? Citing the readme:

  * Hiding required CCK fields is not supported, as the created content node would have empty
   required fields afterwards, which in affect would make it impossible even for admins to edit
   the content node.

But it would be great, if you could get up with a way to make UI more intuitive, but keep that behaviour.

jeffschuler’s picture

Status: Fixed » Needs review
StatusFileSize
new925 bytes

Not many people read READMEs, and those that do don't always remember what they've read. They'll go to the issue queue first. Let's save you time.

It's not intuitive that certain fields should disappear. In this situation the interface can show what's happening and why.

The attached patch adds a simple description to the Hide form fields section:

Hide fields from the user registration form. Required fields cannot be hidden and are not shown here.

Going further, I think this can be even clearer and more sensibly solved by showing each field that's required as a disabled checkbox. Does that mean splitting the checkboxes field into individual items?

niklp’s picture

The disabled checkbox thing would be good - but of course it then allows cheeky devs to form_alter the form and re-enable them which will then in turn break the validation...

Simply having the text added would be adequate in my opinion, as it's less "tempting" to hack at the FormAPI after the fact - there is simply that reason that they aren't there, and that should be good enough.

fago’s picture

Status: Needs review » Fixed

oh this help text is great, thanks, committed.

Indeed disabled checkbox would be better, but for now the text is fine.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.