Drupal 7 port

Hi Kilenearth,

I didn't have it in my plans, to be honest, but if you are interested, we could explore the options.

I think migrating this module to d7 shouldn't take more than 16 hours. I will propose it for a BoF in the upcoming #SANDcamp

Firstly an awesome module rmontero.
Deffinately a lot better approach than webform_register, both from data analysis and CRM integration perspectives.
I like the way it shifts the configuration emphasis to the webform itself for a lot better flexibility.

I've started an unofficial d7 port of this module as I needed very similar functionality.

I've carried out the following tasks.

• Upgraded to drupal 7.x
• Removed unused settings page
• Removed unused functions
• Removed unused javascript functionality
• Removed support for webform 2.
• Removed content_profile support.
• Removed default page-registration.tpl.php (very theme specific) override still available.
• Moved user registration settings from 'edit' to its own tab under 'webform'
• Added implementation of drupal states api to hide fields unless registration-mode 'enabled'
• Reduced database lookups. Script was querying for values which were already loaded on node object.
• Removed login ability for now

I've still got to:

• Reinstate d7 login ability when password fields present
• Integrate with d7 user entity fields
• Add special needle <clone> for confirmation fields
• Add an upgrade path (although it's largely compatable

Throwing this out now incase users like kilenearth can use or at least learn from it.
Will try keep this issue updated with how I progress.

Please see comment #39 for latest update

Looking for this as well. Thanks in advance if it develops

apologies there was a bug when adding registration settings to a new webform in the code above

have attached version with fix

Please see comment #39 for latest update

Integrated with d7 user entity fields

Please see comment #39 for latest update

I tried to the newest zip file here, and since there is no good documentation, I tried what I thought was right. I came up with this error: Notice: Undefined index: account_fields in webform_registration_settings_form_submit() (line 188 of /sites/all/modules/webform_registration/webform_registration.admin.inc). Here is what I did to produce the error:

1.) Uploaded Folder to Module Folder.
2.) Checked Module in Drupal Module List
3.) When to Webform, hit edit, clicked Webform Tab and Registration Settings Sub Tab
4.) I clicked Allow users to register using this webform
5.) Filled out the settings as I saw I needed them.

Would I still be able to use this even with the error?

Hi ShawnRisk,

The error shouldnt be a problem and before php5.3 that error would never have been displayed.
The error will occur because at some point I tried to check the value of 'account_fields' without first initialising it or defining that there weren't any but it shouldn't have a negative effect on the logic.

I advise always testing a module thoroughly before putting on a production website.

If you find anything is buggy please report back

Cheers
Darren

@Darren Shelley,

I will try it out, and if it all works I will push it into the 7.x-1.x branch.

Thanks a lot for your hard work.

@rmontero.

Thank you, I needed to write a module like this for end of Jan and as you had the correct approach for me it seemed more sensible to upgrade it myself than to create a rivalling module.

If d7 isn't on your radar I'll happily get round to reintegrating some of the functionality I stripped. Primarily the login capability and getting an upgrade path in for users converting from d6->d7.

I do not mind atall if you want to take elements of this to perform upgrades yourself or want to contest some of my changes :-)

I am also looking for a way once someone registers after submitting the webform, that user that signs up should be attached to that webform submission. The reason being is that this user will be able to edit that webform if they have permissions to do that. Would that be possible to do or is that something that would be much harder?

Attached patch (for source in #6) updates the webform_submissions table with the new user id so that submission is accessible to user when they log in

I have tested the patch from comment #12 and this woks for me. Hope that this gets added into the patch before this becomes an official version 7 of this module.

@Darren Shelley

Thanks for porting this super useful module!
I also get the same warning in #7 and this one too:

• Notice: Undefined property: stdClass::$webform_registration στην webform_registration_settings_form() (line 24 of C:\xampp\htdocs\test\sites\all\modules\webform_registration\webform_registration.admin.inc).
• Notice: Undefined property: stdClass::$webform_registration στην webform_registration_preprocess_page() (line 93 of C:\xampp\htdocs\test\sites\all\modules\webform_registration\webform_registration.module).

Same steps like #7. At first I asked only for username, then I returned and added a password field too. Thats when I got that extra warning.

**Update**

Something's wrong with the password field. When I hit Save I get the "The registration settings have been updated." but the checkbox "Allow users to register using this webform" returns to be unchecked!

I have tested the patch from comment #12.

This provides good functionality, I am personally now using this in my environment.

I will try and look at the issues highlighted by #14 tomorrow.

I think there needs to be a cache clear after the webform settings are saved. Often they are being saved but the node load was cached so it still appears that they weren't saved. It takes a hard cache clear to get them to show up.

You could be right. Today my set up is working.

Since there is no documentation could someone clarify these questions/statements for me?

1. When mapping the fields, even if your original field is not mandatory, it becomes mandatory.
2. For the "Password Confirmation field" you need to select the same field as above? (doesn't seem to work. when typing in the password I don't see any dummy field for confirmation)
3. Are there any validation checks on the "Username field" besides the check if the username already exists? e.g no underscores allowed, at least one alphanumeric character? If not, I guess I can define my own custom validations on the field through webform validation module.
4. Same question for the password. Are there any validation rules for it?

@Perisdr, #17

1. Correct, if you choose a field to represent the username, the email or the password the module forces them to be required. This is because they are essential to creating a new user. It makes the workflow easier.

2. In the current d6 version of the module if you chose 'email' for both 'email' and 'email confirmation' field it would clone the field on the front end and validate the two matched.

As i had to do a very fast port i stripped this functionality, and i would recommend to reimplement it with the special selection of "" to make it clearer to the configurer what the functionality does, and to make the code easier to read/maintain. On the zip above you can create 2 components one password, one password confirmation and then map both of those.

3. Certainly in the 7 port ive done (i can't remember what 6 does) I check the usename matches drupals requirements using user_validate_name:
http://api.drupal.org/api/drupal/modules%21user%21user.module/function/u...
If it does, i go on to check the username is unique.

4. Neither iteration (rmonteros nor this 7 port) do password validation currently.

Thank you Darren. So far I have been able to work with the module successfully. Good to see that the username uses the same validation criteria as the core registration. As far for the password a regex can be added with webform validation in order to take care of this.

The only thing I would really like to see (well this should go on a new issue) is to add the feature of assigning a role to the user that submits the form. I tried to do it through rules but the problem is that the user is anonymous before submitting the form so I don't have his uid. Tried to fetch a user entity by the username property but so far rules denies cooperating with my request…

+1. I'll need this functionality in a couple months,
perhaps an integration with something like auto assign role (http://drupal.org/project/autoassignrole)

Currently I'm allowing my customers to opt-in to free trials on the registration page of a drupal site(opting in gives you a free trial role). It would be great to have such an ability tied to webforms.

One of the biggest powers this module provides and the reason I'm using rmonteros approach is the ability to a/b or multivariate test different registration forms, extending that to permit group opt-ins and it gets really powerful

I've actually just finished functionality of adding a role to a user. I used webform_rules and created a rule for when a webform is created that adds the role to a user. The only difficulty I ran into was the order the submit hooks were called was causing the role to be assigned before the user was created. To fix this I changed the way the submit function was added for webform_registration to:

In webform_registration.inc around line 81:

    $form['#validate'][] = 'webform_registration_validate';
    // A little ninja work here. Need the webform_registration to come after the 
    // first element but before the normal submit so that webform_rules works.
    $first = array_shift($form['#submit']);
    array_unshift($form['#submit'], 'webform_registration_submit');
    array_unshift($form['#submit'], $first);

This probably should be a patch but I don't have time to format it yet.

@Darren Shelley - Wanted to sound you out on some ideas:

1) It strikes me as an oversight that webform/registration does not accommodate an opt-in field (i.e. a component that indicates whether the person filling in the current webform actually wants to automatically become a registered site member). We should have the option to give form users the option, if you know what I mean.

2) I also thought it may be better to include role assignment in the process of creating the user by including a selection of site roles on webform/registration. It seems we just need to add roles to account object before calling user_register_submit() so that we avoid the rules etc. that @randallknutson refers to in #21.

I'm happy to patch (and back-port to D6), but would like to hear other voices on the subject before I get carried away.

@vernond
some good suggestions

Regarding
1) I can see where you're coming from, and in certain applications an opt-in ability is essential. In my opinion this should be an optional thing as it might be clearly obvious in the text that an account would be created. For instance if you were using the form to emulate user/register a user would expect the creation of an account, submission is sufficient to assume opt-in here.

My suggestion would be that by default a user account is created but in 'registration settings' you could nominate a boolean field (from the components) which represents 'opt-in'. This approach feels more flexible andin keeping with the modules field-orientated approach. It will keep all components on the component page of the webform settings for consitency and allow greater flexibility over its text, default state and just about anything you can configure on a component. It would also mean the choice a customer made would go into results and could be passed on to a CRM system.

2) I agree that rules is not the ultimate solution here and wont fulfil all the needs for flexibility. Rules is a great solution for system configurers in the current state of the module, but is far too complex a system to hand out to content editors and marketing people to use in my opinion.

I'd probably advise a similar approach to my suggestion in point 1.
It could be nice to setup role associations to boolean fields. I.e if this value is true enrol them in x,y and z roles (as chosen by a content editor).

I'd be interested in hearing other peoples thoughts.

Thanks for testing the port thusfar. It'd be great to thrash out the bugs and get rmontero's approval of the port then these issues could be branched out into seperate trains of thought against version 7.x-1.x-dev, backporting where possible to 6.x-1.x-dev

I'd recommend the rules fix as outlined above anyways so that rules will work as people expect. I agree though that there should be another, easier way of adding roles.

Attached patch (assumes patch from #12 is already applied) adds the following functionality to admin form (see screenshot):

1) Specify a source field for an Opt In value, as well as specify the value in that source field which indicates that the user opts in. If no source field is selected, then all submissions will be attempted registrations. If a source field is selected, then a non-blank opt-in value is required.

2) Specify via checkboxes which roles the new users should be assigned to when they get registered.

Apply patch and run update.php to get the three new db fields (opt_in, opt_in_value, roles) added into webform_registration table.

Shameless justification: In an ideal world there would not be two changes in one patch, but this is not an official branch yet, so I've relaxed the rules.

@Darren Shelley - what I did not say in #25 was that I couldn't think of way to implement your suggestion of assigning new users to various roles dependent on a variety of booleans. What I have in the patch in #25 is an "all or nothing" kinda thing - all new registrations will be assigned to the same role/s, the only modifier being the opt-in scenario.

@rmontero - How close are we to qualifying for a 7.x branch with what we have so far? Is there any specific functionality or other minimum requirement we have not met?

It would be good to get the branch so that future fixes and patches can happen in their own separate issues instead of stringing along in this issue.

Hmmm weird. When trying to edit the submissions of the webform I am getting this

Fatal error: Cannot use string offset as an array in C:\xampp\htdocs\xxxxxx\sites\all\modules\webform_registration\webform_registration.inc on line 60

From what I see in the code the problem exists if a logged in user tries to access the webform.
In the comments it says:

// Hide everything but populate the fields in case webform needs them for
    // something, e.g. Connecting with a CRM or such

I do not require to populate any user data in my webform (since its meant for registration, my user is always anonymous). What can I do to to remove this action?

For now when I am logged in and try view my webform I keep getting this error
Fatal error: Cannot use string offset as an array in C:\xampp\htdocs\xxxxxxxx\sites\all\modules\webform_registration\webform_registration.inc on line 60
Maybe there is a problem when reading some of the user fields? I also have fields like "Select or Other", don't know if this could be causing any problem. Any ideas?

Hi perisdr,

This appears to be an issue with the user fields functionality, commenting that part out could be a fast solution.
Im over at drupalcon denver currently but will try to have a look at this in a break today or tomorrow

Cheers
Darren

Thanks Darren. I 've also been playing around with many fields and I may have found some issues.

• A multivalue select/radio/boxes component does not seem to pass its values to the equivalent user field. Both fields have the same key|values. On the webform the box for allow multiple values is selected and on the user field I select the maximum number of values for this field.
• What happens when you assign a webform file component to a user file field? The file does not copy.

@Darren Shelley - Do you perhaps have some idea when we're likely to see a D7 branch? rmontero has not replied to my questions in #26 Edit - Oops, I meant [#27]

@pesidr #31

To fix the bug with user fields change:

  //Add use field instances
  $user_field_info_instances = field_info_instances('user', 'user');
  foreach ($user_field_info_instances as $field_name => $instance) {
    	$user_register_info['values'][$field_name]['und'][0]['value'] = $fields[$field_name]['value'];
  }
  user_register_submit($form, $user_register_info);

to: (this will prevent it trying to save fields that are not set to be included, ie have the special value of <none>)

//Add use field instances
  $user_field_info_instances = field_info_instances('user', 'user');
  foreach ($user_field_info_instances as $field_name => $instance) {
     if(!in_array($fields[$field_name]['value'], _webform_registration_get_special_needles())) {
    	$user_register_info['values'][$field_name]['und'][0]['value'] = $fields[$field_name]['value'];
     }
  }
  user_register_submit($form, $user_register_info);

It'd be interesting to see list and file behaviour working as you describe. Currently i have no time to carry out this work, but if you do investigate further please post in here. or raise as a ticket in a d7 branch if/when one becomes available

@vernond, thats largely up to rmontero. What you can do to help is thoroughly review the port, check that its in keeping with the d6 version and change the state to reviewed and tested by the community if happy that this is a good progression and direction for the module.

Just in case anyone like me reached this thread while searching for feature patched in #12, below is the code for Drupal 6 for same:

// Update the main submission info based on $user_form values updated by user_register_submit, but only if this submission is new instead of old one being editted.
    if ($form_state['values']['details']['is_new'] == TRUE) {
      db_query('UPDATE {webform_submissions} SET uid = %d WHERE sid = %d', $user_form['user']->uid, $form_state['values']['details']['sid']);
    }

Its a bummer that multiple select components don't copy themselves to the user profile.
I though of breaking my checkboxes into separate components for each value as a workaround but in order to create a single value checkbox you need to check the muliple select, so it doesn't work!

The patch at #12 failed for me. Here is the error I received:

File to patch: webform_registration.module
patching file webform_registration.module
Hunk #1 FAILED at 171.
1 out of 1 hunk FAILED -- saving rejects to file webform_registration.module.rej

Any advice will be greatly appreciated

@vip_sa. Just to check you're applying it to the correct thing. Did you download the code in #6 and apply the patch to that?

Hi Darren

Thank you for the reply. I think I used the code at #5 and so I will use the code at #6 and see if that works.

and so I tried it and the same error.

This is such a great module and if someone can make it that you can add a role to the registration then this module would be complete.

This thread feels like it has become a bit lost.

There are a lot of feature requests, a lot of bug fixes. People are on varying versions and seeking help.

rmontero has different priorities than maintaining a d7 branch, largely i imagine, because 'achieve enterprise drupal' do not currently have a need for a d7 version, which is more than fair enough :-)

I am more than happy to become a co-maintainer to help maintain the d7 version of the module, if rmontero approves this as a foundation. That way a topic can be created per issue making it easier to manage.

In the mean time please find attached the version I am using. I've uploaded both a zip, and a p1 patch file taking it from 6.x-1.x-dev to 7.x-2.0

If you're seeking help at present it would be easier to go from this as a start point.

The version i've attached:

• uses source from #6
• incorporates patch from #12 (stores new user id)
• didn't implement code from #21 (breaks setting user on submission)
• incorporates code from #25 (adds optin and role assign functionality)
• incorporates code from #33 (fix bug with userfields)
• If you're logged in it will add the new roles to your existing account

Please community review this version as a candidate for succession

HI,

Thanks for working on a D7 version of the module...

I've set up your version in the ZIP file and encountered a notice when completing the form of:

Notice: Undefined index: administer_users in user_register_submit() (line 3762 of ..../modules/user/user.module

Also when logged in as User 1, I see an error (repeated 3 times) on the webform page of:

Notice: Undefined index: und in webform_registration_inc_form_alter() (line 61 of ..../sites/all/modules/contrib/webform_registration/webform_registration.inc).

Note that my test form has three fields to fill out - first name, last name, email address.

The site is not running anything unusual - I do have account creation enabled only for the admin account - the only other webform modules are:

• Webform Conditional - 7.x-1.0-beta1
• Webform multifile - 7.x-1.2+12-dev

Also using LoginToboggan - 7.x-1.3

Eric

I am having a strange problem.

I have installed the following webform modules

webform-7.x-3.18
webform-conditional-7.x-1.0-beta1
Webform Registration-7.x-2.0
Webform Report-7.x-1.x-dev

I have a webform with a page break that is used to register a new user.
When I hit Next Page on the first page, the user account gets created and it goes to the next page in the webform.
When I hit submit in the next page, I get sent to the error page and in the log there is the following database error:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'name': INSERT INTO {users} (uid, name, pass, mail, theme, signature, signature_format, created, access, login, status, timezone, language, picture, init, data) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15); Array ( [:db_insert_placeholder_0] => 40 [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => [:db_insert_placeholder_3] => [:db_insert_placeholder_4] => [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => [:db_insert_placeholder_7] => 0 [:db_insert_placeholder_8] => 0 [:db_insert_placeholder_9] => 0 [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => [:db_insert_placeholder_12] => [:db_insert_placeholder_13] => 0 [:db_insert_placeholder_14] => [:db_insert_placeholder_15] => a:1:{s:7:"contact";i:1;} ) in drupal_write_record() (line 7036 of /home5/amspools/public_html/includes/common.inc).

has anyone else seen this and does anyone know of a solution.

thanks

Aron

@abennett.

Do you have a field asking someone what their username should be?
Is that 'username' field selected in the webform registration settings as the 'username' field?

If the answer is no, a quick fix would be to follow those instructions, how you are you expecting the username to be generated?

thankyou.

I have the same problem such as in 40 post

Notice: Undefined index: administer_users in user_register_submit() (line 3762 of ..../modules/user/user.module

webform-7.x-4.0-alpha6

@Darren @rmontero re #39 - is it likely that when D7 module is firing on all cylinders that Darren will be made co-maintainer? Is rmontero still engaged on this module much? (just wanting to avoid the outcome of everyone's hard work resulting in a working module but not able to get it committed)

is it worth bumping this - still seems from the above discussion that a lot of the work required has already been done - is that true?

Bumping and changing issue settings. May be then rmontero sees it.

EDIT: I'm having the same problem than #41 http://drupal.org/node/1336486#comment-6736770 the PDOException: SQLSTATE[23000]: Integrity constrain

Hi,

I'm browsing for a webform registration module and I found this Webform Registration one which looks promising. I'm using a D7 set up as well and noticed there are still PDOExceptions. Meanwhile, I found http://drupal.org/project/lazy_registration which seems to do something very similar and has a D7 version. Has anyone compared the two? What are the differences?

Thanks,
Diwant

@drewbolles Oh, that's disheartening. Lazy Registration's description and this one's description both seem to indicate they would do the thing we want. I'm going to play around with these when I get to the lazy registration part. Your custom hook alters sound very specific to your setup, huh?

I have two fields the Username and Email Address and set it in Registration form on the webform_registration after saving there is an error message "Notice: Undefined index: administer_users in user_register_submit() (line 3795 of /var/www/html/modules/user/user.module)."
and also a message that the registration was successful and the receive email from my site. What should I do
also I used the unpublished D7 webform_registration

I am also interested in a proper D7 port on this. This was so close to being ready for prime time, be a shame if it dies. I dont know enough about coding yet to fix the last couple of issues.

Any progress on this? I tried mrP's module and after some fiddling managed to get it installed. However I'm now seeing this error:

Notice: Undefined property: stdClass::$webform_registration in webform_registration_settings_form() (line 24 of /var/www/example.com/public_html/sites/all/modules/webform_registration/webform_registration.admin.inc).

Any ideas?

Cheers

Has anyone managed to get webform registration to work in D7?
I tried the version from #39 but couldn't get the patch to work
I tried the version from #52 and the first patch from #53 gave

patching file webform_registration.inc
patch unexpectedly ends in middle of line
Hunk #1 succeeded at 160 with fuzz 2 (offset -11 lines).

on applying the second (roles) patch from #53 I got

patching file webform_registration.admin.inc
Hunk #2 FAILED at 245.
Hunk #3 FAILED at 267.
2 out of 3 hunks FAILED -- saving rejects to file webform_registration.admin.inc.rej
patching file webform_registration.inc
Hunk #1 succeeded at 148 with fuzz 2 (offset -5 lines).
Hunk #2 succeeded at 160 with fuzz 1 (offset -5 lines).
patching file webform_registration.install
Hunk #1 FAILED at 62.
1 out of 1 hunk FAILED -- saving rejects to file webform_registration.install.rej
patching file webform_registration.module
Hunk #1 FAILED at 46.
Hunk #2 FAILED at 68.
2 out of 2 hunks FAILED -- saving rejects to file webform_registration.module.rej

every version I have tried to run on my D7 has produced errors
Am I doing something wrong?
Is there a working solution for Webform Registration out there anywhere?

The #52 zip from MrP seems to be working fine for us (D7-not fully tested yet) but a possible caveat for others is that it only works with webform content type not webform-enabled content types.
With small code alterations someone could enable it for other webform-enabled content types as well...

@olisb, I had some success

I used the #52 build (the one with the 7.5mb size) and applied fixes from #53 (minus the roles and opt_in mod changes).

I use this in conjunction with Salesforce

So ...

Mapped the Salesforce

Created a basic form:
- First Name
- Last Name
- Company
- Email

Filled it out the form.

It successfully created an account, sent out emails, and generated a lead in salesforce.

However, it gave me the "Notice: Undefined index: administer_users in user_register_submit()" error. But as far as I can tell it had no impact on creating an account.

Fixing title

I managed to get this working thx to @vitalik_m notes - Im using it to create a Drupal account and also squirt data into infusionsoft to create a contact record. One thing its not doing is logging the account in straight away - it gets blocked and has to be approved by the administrator.

Ive set it up for users to register straight away without approval so not sure why this is happening? Thx for a very useful module..

EDIT:
Also tried logintoboggan and auto assign role but still no joy

cross-posting: #2564961: Is Webform Registration still maintained?

D7 version committed

I probably won't have any time soon to go through the issue queue and determine which issues are still relevant, if any, so please create new ones or reassign to the new 7.x branch if you know of any.