All node fields/taxonomy/etc on registration form

hm, the registration module is currently CCK only. So I don't think that's a code bug, but probably a documentation bug. I've created an issue for that: http://drupal.org/node/313962

So I set this to feature request for now. The question is how we should deal with it... We could add support for taxonomy, but then people will come and ask for the next form field of module X.

So we have imho the options to

* stay with CCK only support
* make it possible for modules to extend support for further fields
* support the whole node form by default.. We could add an option like "Other form fields" to allow hiding others, so the module runs in CCK only mode too. In this case it would make sense to treat the title as field too imho.

+10 for taxonomy support on registration form...

subscribing

@ NikLP -- how does this work with content_taxonomy? http://drupal.org/project/content_taxonomy

What about that route doesn't work? How could these issues be addressed?

Also, changing status from critical to normal.

I tend to agree that this is the best option:
* support the whole node form by default.. We could add an option like "Other form fields" to allow hiding others, so the module runs in CCK only mode too. In this case it would make sense to treat the title as field too imho.

It's not really obvious to mix up the form, so best integrate the whole form and make it possible to hide single groups and fields. I can work on this once I've time.

This is starting to feel scope-creepy.

Including a checkbox feature to enable the whole node form seems to be a cleaner solution. Having this be the default, however, seems to be overkill. The majority of the sites we have rolled out in the last 2.5 years included some type of node-based profile, and never, not once, was this needed.

An admin option, enabled via a checkbox? Yes, absolutely - this seems to be a clean middle ground.

Having this as the default option introduces a host of usability issues. This is where Bio's administrative simplicity should be replicated.

I agree - keeping it more simple by default sounds to be a good thing.

subscribing

subscribing

I agree with bonobo's comment #11, let's keep it simple and disable it by default.

>Including a checkbox feature to enable the whole node form seems to be a cleaner solution
So probably best we add an additional checkbox "Other form fields".

As like it is now, the form fields are retrieved by drupal_retrieve_form() and drupal_prepare_form() - which fires up hook_form_alter, so any alterations done there are included. Apart from that one can form_alter() the registration form directly of course, too - just watch out that your module comes after content profile.

I think it's better to get just all and provide one option for this -> 'other form fields' as I'm sure there is other stuff that is also useful to have there.

Yes we already pull the usual $node form, so we have this stuff too. The question is if we can get validation and submit right for this stuff too, but I think that's doable.

I've been investigating a method to make this happen. The problem I keep running into is the inability of the forms API (or my inability to think up a solution) to have multiple node forms built, validated, and submitted as one process.

If the structure is not as expected CCK, AHAH and other stuff just doesn't work.

From my current standpoint the real issue is the inclusion of multiple node types as a "profile" this results in the necessity to potentially add data to multiple nodes at registration time.

One way around it is to enable only one "full node" profile type at registration time. The admin UI would probably be a bit clunky do to the current method for setting content profile registration settings.

If someone knows how to have multiple complete nodes submitted as one form submit let me know and I can get this done. Short of that there will have to be a compromise in either the number of content profile node types exposed at user registration or limiting it to multiple node types with only CCK.

One other method would be a multi-step user registration submitting one node type per step in addition to the standard username etc. I personally don't really like this idea though.

Maybe I'm missing something else that could be a solution?

>If the structure is not as expected CCK, AHAH and other stuff just doesn't work.

yep, I think the only possible way to do it, as pulling all stuff of $form of the node form directly in $form of the registration form.
As an affect if we have multiple node forms, some stuff which would be duplicate can exist only once: The title, the body, shared CCK fields and possible more. I think the only way to go is creating both profile nodes with the same values - so using $form for both!

Or as an alternative we allow only one node form for the main registration form activated. I'm ok with that too.

We're kicking some ideas around about a more structured roadmap for this feature -- either jgraham or I will post details shortly.

subscribe

subscribe

Hi NikLP
have u got any solution regarding taxonomy on user registration form. please give me some suggestion regarding this. how can i approach on this way.

I marked http://drupal.org/node/367601 as duplicate

Multiple people are in need of a solution. This is a major feature lack. Updating to critical as this is functionality that is essential.

I've got taxonomy terms on my registration form.

Create a field (presuming you are using Content Profile) with a Content Taxonomy Field using Hierarchical Select.

Then created a 'group' which is then selected to show in the registration form.

Hope this helps ...

Hi NikLP,

Definitely have sympathy and had the same problem for weeks, and this works for me.

Install the Content Taxonomy of HS at http://drupal.org/node/342992

In your content type, create a field-type in the drop-down 'Content Taxonomy Fields' and 'Hierarchical Select' as a form element.

Make sure you set up /admin/settings/hierarchical_select/configs' correctly.

I set up all my Content Taxonomy Fields in my content type as a 'group', and then in 'user registration' un-selected the 'group' to show in registration.

All good, oh yes, remember to set permissions for 'guest/visitor' and 'unauthenticated' to 'create/edit your content type', otherwise won't show.

Hope this helps some ..

A patch (which I haven't tested yet) is offered here: http://drupal.org/node/19014

Subscribing. Taxonomy on registration form is a critical matter. It was the most important advantage of Node Profile.

I've just posted another issue related to content_profile_registration module. Could you all please review that and +1/-1?

#410678: Move registration form code from hook_form_alter() to hook_user()

+1 on taxonomy on reg / edit

i'm working up a quick, dirty patch now because i need this immediately.

Don't use this patch. use the next one.

This patch integrates taxonomy into content_profile and content_profile_registration
Also adds toggle on the content_profile admin to enable or disable taxonomy (all or nothing toggle, no per-vocab options)

Thanks aaronbauman. Very timely for me :)

I had to make a change to get it to save the selected terms, though.

@hide title: I don't think supporting required fields is a good idea, so this won't get in. Auto-nodetitle solves that though.
@taxonomy: I still think supporting the whole-form is the way to go, so we don't have to care about each field on it's own...

ok, finally this got implemented.

Changes:
Added support to add all node-form elements to the registration form. It's activated by default, so check your settings if you don't need it.
Added the possibility to control whether the title field is hidden, integrating with auto nodetitle.
Added usage instructions to the README.txt

Check out the latest dev-snapshot. Thanks to NikLP for sponsoring this work.

Hi fago,
regarding the use of content profile with taxonomy, I installed the latest DEV version and wanted to point out this issue I had with hierarchical select on user registration:
http://drupal.org/node/374354#comment-1515148

I write also here because this issue occurs to me only with content profile module, maybe you can give a hint?

subscrib ing

Same problem here...
So, what are we going to do?

This doesn't work properly as it seems on 1.0

I had 2 types on registration, one with taxonomy. Both were saved with the terms, but now I have a profile that shouldn't have terms with them (and of course, they cannot be deleted within the interface either). I'll try to work out a patch for it later.

subscribe

I'm confused by #43 and #46. Fago, what is it that you have implemented? I think this issue refers to having taxonomy selector that is enabled for a c profile node be able to show on the user registration form.

The patch in #43 looks as though it might do this but this patch isn't in 6.x-1.0 (or in dev). So has it been implemented in the module some other way; and how would this be enabled? I don't see any thing to enable the taxonomy selector on the registration form.