>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3380160. --> Reported by: [kingdutch](https://www.drupal.org/user/1868952) Related to !35 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>In Open Social we want to ensure every user always has a default profile for our profile type. This simplifies a lot of code downstream that deals with users and user names (for example displaying the right name in a registration e-mail). To solve this we implemented hook_user_insert and created a profile when a user is created.</p> <p>The problem occurs when adding the ProfileFormWidget to the user registration form. The widget will prepare profiles, but won't actually save them until after the user creation is completed (which includes all invocations of hook_user_insert). It then calls <code>saveProfiles</code> where the profiles will actually be persisted and are loadable as normal entities. </p> <p>This causes for example <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/profile/-/work_items/3170143" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/profile/-/work_items/3170143</a></span>.</p> <p>There are no good workarounds for this that I was able to find in a few full days of experimenting. Modules could hook into the form, but then users that are not created through the registration form (e.g. in tests or through an API) will not have a profile because that code path isn't triggered. We also can't fall-back to hook_user_insert for non-registration form users because we have no way to know whether a user is being created through the form and will thus get a duplicate profile saved in <code>::saveProfiles</code> right after the user creation is completed.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>We can move ::saveProfiles to happen after the user entity is built, but before the user is saved. The user will have a UUID generated at that point even though the entity has no ID yet. In case the entity is new, we can then save the profile in a <code>profile_user_insert</code> to make sure that any downstream modules that also want to use <code>hook_user_insert</code> will already have the profile available for loading.</p> <p>In case the user already exists we can just immediately save the profile (or alternatively also implement <code>hook_user_update</code> but that function is called more often and thus might have a performance penalty).</p> <p>Transfer of data between <code>::saveProfiles</code> and <code>profile_user_insert</code> needs to happen through site state. The reason for this is that if we try to attach it to the user entity itself the Drupal entity API will treat it as an entity reference. Entity references cause the referenced entities to be saved first because the ID of the referenced entity is stored on the referencing entity (i.e. User --&gt; Profile, rather than Profile --&gt; User). This also suggests that a future version should possibly consider inverting the relationship between the entity that "has a profile" and the profile (to also allow other types of entities to have profiles, like a profile for an organization).</p> <p>This also fixes <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/profile/-/work_items/3170143" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/profile/-/work_items/3170143</a></span> without making the tokens smarter.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h3 id="summary-ui-changes">User interface changes</h3> <h3 id="summary-api-changes">API changes</h3> <p>ProfileFormWidget::saveProfiles is now called before the ::save method for the account and register form.<br> Profiles created for users going through the user forms are now available as soon as the user entity is inserted into the database.</p> <h3 id="summary-data-model-changes">Data model changes</h3>