Move the profile "registration" form to a field widget

Thanks for submitting your suggestion.

Please see documentation on patches for how to produce a patch file in unified diff format. If you give your file a .patch extension, you'll be able to attach it in a form that's much easier to review.

Also, it helps a lot if you provide details about what issue you're addressing and exactly why you're proposing the specific changes. See the issue summary template.

Some quick comments:

	-   $weight = 90;
+   //Abhay: Commented all $weight variable present in this function
	+   //$weight = 90;

No need to put your user name here. If something isn't needed you should simply delete it in a patch rather than commenting out. But presumably there's a reason for the weighting, so if you're removing it it's important to explain why (in the issue summary).

Again, thanks for contributing!

@abhaysaraf: Please see https://www.drupal.org/patch for how to create a patch as @nedjo has suggested. It's a file with .patch extension that should be attached to this issue.

made a patch out of the file but it doesn't seem to work...

Okay, I see. The problem here is that the injected fields are not on the form display and they can't be moved around in relation to the normal fields on the form.

+++ b/profile.module
@@ -128,6 +128,16 @@ function profile_entity_extra_field_info() {
+    //Profile fields to appear on MANAGE FORM of ACCOUNT SETTINGS
+    //Account Settings Page: admin/config/people/accounts/form-display

@@ -194,7 +204,9 @@ function profile_form_field_config_edit_form_submit(array $form, FormStateInterf
+  //Commented all $weight variable present in this function;
+  //Since, it always make Profile type fields appear at the bottom of user registration page
+  //$weight = 90;

Need spaces after //

Also.. the latter half can just be removed.

This is still a problem, on user/%/edit pages the profile fields are not shown.

I created a patch that uses a form_alter (like the user register) to add the profile fields to the edit form with the active profile types prefilled.

I made some code style fixes :)

There's a related issue #2946670: Add computed {$profile_type}_profiles fields to users, use them to render profile data on the user profile which takes an approach written by Matt for another ticket to get the injected profile field working on the "Manage Display" tab of user entity.

Wow, this issue looks quite confused to me. The only reasonable approach is #6 and no form alter is needed then.

Patch flying in that worksforme.

Ups, missed some leftovers. Here we go.

Ah, i adjusted the form keys to use a allowed namespace, thus fixed tests.

OK, it looks like in the test, without a configured user form display, the form does not appear. What is to be expected if the patch succeeds. Will fix the test later.

Let's move the form key namespace fix to a followup. Added a needed cache reset on profile type save.

With this patch the profile now appears in "manage form display" at /admin/config/people/accounts/form-display but this doesn't affect the user edit form ("user_form"). #9 mentioned this and while it might seem like a separate fix, it means the form display modes only apply to the user registration form and not the user edit form, which is a bit confusing.

The profile currently appears as a separate tab on the user edit form but this doesn't reflect the user account settings.

This combines #9 with #19 to provide consistency between the user edit and create forms.

I am lost with all these question and different patch.

I used this patch that will work :

https://www.drupal.org/project/profile/issues/2946670#comment-12640613

Now I deleted it and applied the patch #21

But you can not get the ID of the profile.

There is even more formatting options for the field.

I used in the twig of my template :

<article{{ attributes.addClass('user--comment') }}>

  {{ content.user_picture }}
  {{ user.label }}

  <div class="bs-field-link">
    <a href="/profile/{{ content.personnel_profiles.0 }}" title="{{ user.label }}"></a>
  </div>

</article>

But it does not work anymore with this patch. How can I get the profile ID ?

With the old patch, it works :

https://www.drupal.org/project/profile/issues/2946670#comment-12640613

The patch in #21 is incorrect because the extra-field bit is not inside the foreach, and therefore generates 500 errors when installing the module.

This should be the correct patch. Credits to previous contributors, I just moved the code at the right place.

Thanks to all contributors of this feature patch it worked for me here https://www.hookupndate.com before it my custom profile registration fields showed below the email field and username field now I have control.

Yes, thank you all. It's a very nice feature. I was just wondering if this patch could have anything to do with this bug: https://www.drupal.org/project/multiple_registration/issues/3036696

Thanks!

When profile specified for Allowed roles in /admin/config/people/profiles/manage/[profile_name]
The profile form show in user edit form anyway even it is not an allowed role.

For example, there are profile_a and profile_b,
and profile_a allowed role_a to have this profile,
while profile_b only allowed role_b to have it.

However, both profile_a and profile_b show in the user edit form.

There is no such thing as a critical feature request.

@amourow, I think you are correct, there should be a check in the form alter that checks whether the current user has permission to update the profile before it is displayed.

In the patch in #24:

+/**
+ * Implements hook_form_FORM_ID_alter().
+ */
+function profile_form_user_form_alter(&$form, FormStateInterface $form_state, $form_id) {
+  // user_register_form is also called by this form alter.
+  if ($form_id != 'user_form') {
+    return;
+  }
+
+  // Add the profile values to the $form_state so the form_alter of register picks this up.
+  $account = $form_state->getFormObject()->getEntity();
+
+  /** @var \Drupal\profile\ProfileStorage $profileStorage */
+  $profileStorage = \Drupal::service('entity_type.manager')
+    ->getStorage('profile');
+
+  // Load in all the profiles for this user and add it to the form state.
+  /** @var ProfileType[] $profile_types */
+  $profile_types = ProfileType::loadMultiple();
+  foreach ($profile_types as $profile_type) {
+    if ($profile_type->getRegistration() === TRUE) {
+      /** @var Profile $profile */
+      $profile = $profileStorage->loadDefaultByUser($account, $profile_type->id());
+      $property = ['profiles', $profile_type->id()];
+      // Attach profile entity form.
+      $form_state->set($property, $profile);
+    }
+  }
+
+  // Add profile module form alter of user register.
+  profile_form_user_register_form_alter($form, $form_state);
+}

Possibly do something like this:

/**
 * Implements hook_form_FORM_ID_alter().
 */
function profile_form_user_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  // user_register_form is also called by this form alter.
  if ($form_id != 'user_form') {
    return;
  }

  // Add the profile values to the $form_state so the form_alter of register picks this up.
  $account = $form_state->getFormObject()->getEntity();

  // Get the current user.
  $user = \Drupal::currentUser();

  /** @var \Drupal\profile\ProfileStorage $profileStorage */
  $profileStorage = \Drupal::service('entity_type.manager')
    ->getStorage('profile');

  // Load in all the profiles for this user and add it to the form state.
  /** @var ProfileType[] $profile_types */
  $profile_types = ProfileType::loadMultiple();
  foreach ($profile_types as $profile_type) {
    // First, check if the current $user has permission to update the $profile_type
    if ($user->hasPermission('update any ' . $profile_type->id()) || $user->hasPermission('update own ' . $profile_type->id())) {
      if ($profile_type->getRegistration() === TRUE) {
        /** @var Profile $profile */
        $profile = $profileStorage->loadDefaultByUser($account, $profile_type->id());
        $property = ['profiles', $profile_type->id()];
        // Attach profile entity form.
        $form_state->set($property, $profile);
      }
    }
  }

  // Add profile module form alter of user register.
  profile_form_user_register_form_alter($form, $form_state);
}

So, basically get the current user, and check if they have update permission before added to the form. Though, I am thinking this might require some massaging of profile_form_user_registration_form(). Should we also be checking for 'create' and 'delete' permissions?

Thoughts?

Hm, thinking about this a bit more, if we need the $profiles to be passed to profile_form_user_registration_form_alter, we might need to set it up a bit differently.

/**
 * Implements hook_form_FORM_ID_alter().
 */
function profile_form_user_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  // user_register_form is also called by this form alter.
  if ($form_id != 'user_form') {
    return;
  }

  // Add the profile values to the $form_state so the form_alter of register picks this up.
  $account = $form_state->getFormObject()->getEntity();

  // Get the current user.
  $user = \Drupal::currentUser();

  /** @var \Drupal\profile\ProfileStorage $profileStorage */
  $profileStorage = \Drupal::service('entity_type.manager')
    ->getStorage('profile');

  // Load in all the profiles for this user and add it to the form state.
  /** @var ProfileType[] $profile_types */
  $profile_types = ProfileType::loadMultiple();
  foreach ($profile_types as $profile_type) {
      if ($profile_type->getRegistration() === TRUE) {
        /** @var Profile $profile */
        $profile = $profileStorage->loadDefaultByUser($account, $profile_type->id());
        $property = ['profiles', $profile_type->id()];
        // Attach profile entity form.
        // create a version of $form_state that will pass directly to profile_form_user_registration_form_alter.
        $registration_form_state = $form_state;
        $registration_form_state->set($property, $profile);
        // First, check if the current $user has permission to update the $profile_type
        if ($user->hasPermission('update any ' . $profile_type->id()) || $user->hasPermission('update own ' . $profile_type->id())) {
          $form_state = $registration_form_state;
        }
      }
    }
  }

  // Add profile module form alter of user register.
  profile_form_user_register_form_alter($form, $registration_form_state);
}

I am not sure this is the best way to handle it, I don't like assigning $registration_form_state, then possibly reassigning it to $form_state. I think it will do what we need.

Honestly, I am not sure why we're checking $profile_type->getRegistration() here. Maybe I don't understand how that plays into whether or not a user can edit a profile.

Well, the patch doesn't apply to the latest dev (dev-1.x 6ab5cb0). I don't have time to re-roll at the moment.

The attached patch provides a field widget for the computed field that was added as part of #2946670: Add computed {$profile_type}_profiles fields to users, use them to render profile data on the user profile.

There's a post update function that is in charge of placing the computed field on the user "register" form mode if the "Include in user registration form" profile type setting is checked.

The widget should also support editing the default profile.

I added some code to react when the "Include in user registration form" setting is updated. If it's unchecked, the computed field is removed from the form mode, otherwise it's placed at the bottom.

Attempt to fix the tests, sorry for the noise.

Adding a "form_mode" widget setting and removing the revision log message in preparation for when #2844963: Complete the revision implementation is committed.

Attaching the interdiff.

Rerolled the patch.

Updating title and issue summary.

Here is a reroll with some small cleanups (such as a rewritten profile_post_update_configure_register_form_mode()).

I copied the Field group code we had in the form alter... But it doesn't seem to work as expected, but I'm suspecting it to be broken with the current code as well (See screenshot), the fields are rendered outside of the Field groups.

Ok, the attached patch fixes the integration with Field Group, I figured out what was causing the issue that also affects the current code.

I removed the function_exists() call and only make use of the #process function (the #pre_render has been marked as deprecated in nov 2017).

Sone cleanups, as discussed with jsacksick.

Now storing and retrieving the profiles from $form_state.
Renamed the widget from 'profile_inline' to 'profile_form'.

When using the widget multiple times, the form #process and #submit callbacks were added twice, the attached patch fixes that.

Tweaked and committed. Thanks, everyone!

Please excuse me for butting in on a closed issue, but why was the ProfileAccessTest.php file removed in the commit (but not in the patches)?

I got 2 out of 2 hunks FAILED -- saving rejects to file 2750059-50-register-widget.patch.rej while applying patch #50. Why?

Becaus the patch has already been committed and there's no point to applying it.

But Im not getting form modes in profile manage form display
-You can manage profiles on other user form modes as well. This was stated as benefit from the post T_T

To answer my Question, I found the form modes for profile at config > account > form-display then there's the option for add view mode for profile.

My problem now is how can I use the form mode I created in edit profile form? -_-