<p>For anyone's future benefit - this happens due to the fact I'm adding the user in the <code>sproutForms.saveEntry</code> hook. That happens after it messes around with the <code>fieldContext</code> and <code>contentTable</code> options for the Entry. As such, the user is getting saved to the wrong context, so it won't appear...</p>

<p>A quick workaround for this is to move the following lines in <code>SproutForms_EntriesService.php:133-135</code> to lines 120. This resets the field context back before the hook is called.</p>

<pre><code>if ($transaction !== null)
{
    $transaction-&gt;commit();

    SproutFormsPlugin::log('Transaction committed');
}

// Reset our field context and content table to what they were previously
craft()-&gt;content-&gt;fieldContext = $oldFieldContext;
craft()-&gt;content-&gt;contentTable = $oldContentTable;

Craft::import('plugins.sproutforms.events.SproutForms_OnSaveEntryEvent');

$event = new SproutForms_OnSaveEntryEvent(
    $this, array(
        'entry'      =&gt; $entry,
        'isNewEntry' =&gt; $isNewEntry,
        'event'      =&gt; 'saveEntry',
        'entity'     =&gt; $entry,
    )
);

craft()-&gt;sproutForms-&gt;onSaveEntry($event);
</code></pre>

CC BY-SA 3.0
2015-06-28T17:03:29.193Z
This has been fixed in Sprout Forms v1.0.1
Ben Parizek
CC BY-SA 3.0
2015-05-07T00:51:04.763Z
2015-05-07T00:51:04.763Z
crawf
<p>I'm trying to programatically create a user (once the user submits a form through Sprout Forms). The user doesn't seem to appear in the Users section of the CP.</p>

<p>I've ensured the user is being added correctly - I can even see a row in the craft_users database table. Going directly to admin/users/349 (the ID of the newly added user) shows all the user details.</p>

<p>It's been suggested that I need to index the new element data - but not sure how to do this.</p>

<pre><code>$content = $entry-&gt;getContent();

$user = new UserModel();
$user-&gt;username         = $content['email'];
$user-&gt;email            = $content['email'];
$user-&gt;unverifiedEmail  = $content['email'];
$user-&gt;firstName        = $content['firstName'];
$user-&gt;lastName         = $content['lastName'];
$user-&gt;newPassword      = $content['password'];
$user-&gt;pending          = true;

$success = craft()-&gt;users-&gt;saveUser($user);

if ($success) {
    craft()-&gt;search-&gt;indexElementAttributes($user);

    // Assign them to the default user group
    craft()-&gt;userGroups-&gt;assignUserToDefaultGroup($user);

    // Send the activation email
    craft()-&gt;users-&gt;sendActivationEmail($user);

    // Update the Element Index
    craft()-&gt;search-&gt;indexElementAttributes($user);
}
</code></pre>

CC BY-SA 3.0
2015-05-05T19:16:30.120Z
FWIW, `craft()->search->indexElementAttributes()` shouldn't be necessary here. If you look at the `id` column for the user in the `craft_users` table, do you have a matching `elementId` in `craft_elements_i18n` and `id` in `craft_elements`?
Brad Bell
CC BY-SA 3.0
2015-05-05T23:13:22.160Z
Hey Brad - yeah I didn't think I'd need it. I have a matching row in both `craft_elements_i18n` and `craft_elements`. Both have `enabled` set to 1.
crawf
CC BY-SA 3.0
2015-05-05T23:44:36.130Z
Probably worth glancing through `craft\app\controllers\UsersController->actionSaveUser()` just to make sure you're not missing a piece of info before `craft()->users->saveUser()` gets called.
Brad Bell
CC BY-SA 3.0
2015-05-05T23:58:22.410Z
@BradBell, yep, thats where I started. Will have another look through!
crawf
CC BY-SA 3.0
2015-05-06T08:38:00.920Z
@BradBell I've just copy/pasted the code from `actionSaveUser()`, even adding the private methods, and still the same result. Very strange. Are there any caches to be emptied or something?
crawf
CC BY-SA 3.0
2015-05-06T23:09:33.620Z
I just tried your example virtually line for line (minus `$content = $entry->getContent();` and `indexElementAttributes`) and it's working fine for me.
Brad Bell
CC BY-SA 3.0
2015-05-07T00:44:03.687Z
@BradBell - Ah, figured it out...
crawf
CC BY-SA 3.0
2015-05-07T00:47:12.400Z
Ahh... nice catch.  Probably worth adding as an official answer?
Brad Bell
<plugin-development><users>
Programatically creating a user not appearing in Users index table
# Programatically creating a user not appearing in Users index table

(Asked by: username_0 on 2015-05-05)

I'm trying to programatically create a user (once the user submits a form through Sprout Forms). The user doesn't seem to appear in the Users section of the CP.
I've ensured the user is being added correctly - I can even see a row in the craft_users database table. Going directly to admin/users/349 (the ID of the newly added user) shows all the user details.
It's been suggested that I need to index the new element data - but not sure how to do this.
$content = $entry->getContent();

$user = new UserModel();
$user->username         = $content['email'];
$user->email            = $content['email'];
$user->unverifiedEmail  = $content['email'];
$user->firstName        = $content['firstName'];
$user->lastName         = $content['lastName'];
$user->newPassword      = $content['password'];
$user->pending          = true;

$success = craft()->users->saveUser($user);

if ($success) {
    craft()->search->indexElementAttributes($user);

    // Assign them to the default user group
    craft()->userGroups->assignUserToDefaultGroup($user);

    // Send the activation email
    craft()->users->sendActivationEmail($user);

    // Update the Element Index
    craft()->search->indexElementAttributes($user);
}

**Tags:** plugin-development, users

> **Comments:**
> **username_1**: FWIW, `craft()->search->indexElementAttributes()` shouldn't be necessary here. If you look at the `id` column for the user in the `craft_users` table, do you have a matching `elementId` in `craft_elements_i18n` and `id` in `craft_elements`?  
> **username_0**: Hey Brad - yeah I didn't think I'd need it. I have a matching row in both `craft_elements_i18n` and `craft_elements`. Both have `enabled` set to 1.  
> **username_1**: Probably worth glancing through `craft\app\controllers\UsersController->actionSaveUser()` just to make sure you're not missing a piece of info before `craft()->users->saveUser()` gets called.  
> **username_0**: @BradBell, yep, thats where I started. Will have another look through!  
> **username_0**: @BradBell I've just copy/pasted the code from `actionSaveUser()`, even adding the private methods, and still the same result. Very strange. Are there any caches to be emptied or something?  
> **username_1**: I just tried your example virtually line for line (minus `$content = $entry->getContent();` and `indexElementAttributes`) and it's working fine for me.  
> **username_0**: @BradBell - Ah, figured it out...  
> **username_1**: Ahh... nice catch.  Probably worth adding as an official answer?  

---

## 1 answers

### Answer by username_0 on 2015-05-07. Score: 2

For anyone's future benefit - this happens due to the fact I'm adding the user in the sproutForms.saveEntry hook. That happens after it messes around with the fieldContext and contentTable options for the Entry. As such, the user is getting saved to the wrong context, so it won't appear...
A quick workaround for this is to move the following lines in SproutForms_EntriesService.php:133-135 to lines 120. This resets the field context back before the hook is called.
if ($transaction !== null)
{
    $transaction->commit();

    SproutFormsPlugin::log('Transaction committed');
}

// Reset our field context and content table to what they were previously
craft()->content->fieldContext = $oldFieldContext;
craft()->content->contentTable = $oldContentTable;

Craft::import('plugins.sproutforms.events.SproutForms_OnSaveEntryEvent');

$event = new SproutForms_OnSaveEntryEvent(
    $this, array(
        'entry'      => $entry,
        'isNewEntry' => $isNewEntry,
        'event'      => 'saveEntry',
        'entity'     => $entry,
    )
);

craft()->sproutForms->onSaveEntry($event);

> **Comments:**
> **username_2**: This has been fixed in Sprout Forms v1.0.1  

---

