user registration module

1. hm, I know content_profile_register_content_profile_settings is a bit long, but it's only one function name, which gets a bit long as content_profile is already quite long.

@CCK: I know CCK does it that way and I don't like it. It introduces no problems as anyone knows and respects CCK, but potentially a "field" project would conflict with field module and so on.. As well as for the hook names. I think we should avoid every possible problem with this when possible and properly prefix our modules and hooks.

So if this is ok for you, I'd go ahead and prefix the module and create directories for the modules.

2. We can enable it per default, so users don't have to look for the setting after enabling the module.

3. Have you seen the settings provided by content profile? They are per content-profile type in a own tab like the settings of CCK. I propose to include "registration integration" settings there in a own fieldset - so one can control all content profile related settings of a content type from one screen.
For including settings there hook_content_profile_settings() and hook_form_alter() can be used.

If one really has a lot of content profiles, more than three or so I don't think it's so bad if you have one screen per content type. So even then the screens keep neat. Yes you have to go to through the page for each content type, but you'll have to go through the per content-type settings anyhow when setting up fields per content type.

4. I leave this up to you.

great! However I think it still needs quite some love, so I'll reopen it for now.

* First off be sure to follow the coding style! I've just improved the coding style of the main module. You can use the "coder" module, which is a great help here.

* Then please be sure to add some useful comments, in particular comment each hook implementation as it's usually done in drupal.

* The call "module_load_include('inc', 'content', 'includes/content.node_form');" sits directly in form_alter, which lets it include the file far too often.

* The validation routine can't work like it is now. As we have the form_state now, probably we should save the name of all fields we added in the form state, so we can avoid this ugly preg_match() call during validation.

* Nodeapi op submit is gone in d6, so this can be removed.

Then ease settings code by using the content profile API. If you want I can do the changes.
-> implement hook_content_profile_settings
-> remove the own the form submit handler, as it's unnecessary then.
-> use content_profile_get_settings() to retrieve the settings. Note that also content_profile_get_types() has useful "setting support".

great - the code looks good now!

I just gave it a short test and noted that it doesn't work with required radios. Then what's if people use the fieldgroup module? As of now i think this case isn't covered, perhaps we should invoke the fieldgroup module manually? But what happens if there are not all fields it awaits?
Probably we just keep it "cck fields only" and simple.

To get the whole form looking as in the node, it's probably a good idea to use the subform_element module, as I did for nodeprofile.

@ module_invoke_all('submit', $node);
I think there is no such hook in d6?

@Perhaps its best if you cover this?
ok, I'll do.

so, I just overworked it to make use of the settings API.

I have also fixed up the comment style to better follow drupal code style. Furthermore I
* fixed the display select to show only NOT required fields, so people can't unmark required fields
* added a note to the settings page when the module is disabled because there are no cck fields.
* changed the registration form to build the node properly during validation and to save the same node on submit
* changed the registration form to store the info about added fields in the form state so we need no preg_match() call

It should work as before - validation works too.
However furthermore I noted that,
* the node author isn't set right
* there are a lot of notices we need to fix

@node author:
$node->name isn't used when the user doesn't has node administration permissions. So this needs to be done manually, I remember that I had something like that implemented in nodeprofile's registration code.

@groups:
* An idea came up to my mind, perhaps it would make sense to optionally use the subform element when it's available? Or as an option.. Don't know.

oh, sry I was a bit too quick there. I simplified the logic to

    if (!isset($required) || $required == $info['required']) {
      $return[$fieldname] = $info['widget']['label'];
    }

- which should be equivalent. :)

@preg_match: I've already cleaned that up with my last commit.

@groups: I agree that we should stay simple and avoid complicated options :)

@author: I've just fixed setting the right author.

Recently I've done some work on embedding node forms in d6. This explains who to avoid some pitfalls: http://more.zites.net/embed-a-node-form-with-drupal-6

With this knowledge and some further investigation for CCK I overworked the code a bit. I changed it also use drupal_retrieve_form, as CCK needs to have it's #fieldinfo available. I was able to get #radios working that way, as well as the #ahah callbacks - so you can use a CCK field with "add more" button without errors or notices :)

I also changed the setting, so that one has to specify the fields to hide now, because it was more straight forward to implement.

This seems to work fine now, however I think it will break when one moves the fields in a fieldgroup. We need to have a look at this.