Add computed {$profile_type}_profiles fields to users, use them to render profile data on the user profile

Using the original patch from Matt https://www.drupal.org/files/issues/storing_the_active-2654980-39_0.patch we have experimented problems when importing users via migrations, users that are processed for creation via migration trigger the following call at ProfileEntityFieldItemList.php:

$profile_storage->loadMultipleByUser($user, $this->getSetting('profile_type'), TRUE)

As the user is not yet saved the $user do not have an assigned uid so when the load query is executed the following condition uid is empty:

return $this->loadByProperties([
      'uid' => $account->id(),
      'type' => $profile_type,
      'status' => $active,
    ]);

This causes the exception: Query condition 'profile.uid IN ()' cannot be empty. (core/lib/Drupal/Core/Database/Query/Condition.php).

In order to solve the problem the loadMultipleByUser should execute only when the current user is not anonymous, the fix is added to the attached patch.

Needed to re-roll the patch to apply cleanly on 8.x-1.x and generated the interdiff from 2654980-39 to 2946670-7 that is the fix for the error: Query condition 'profile.uid IN ()' cannot be empty. (core/lib/Drupal/Core/Database/Query/Condition.php).

Changed approach to check if user profiles should be loaded for an user, needed to use id() instead of isAnonymous() entity method due was still experimenting the query condition error on profile module functional tests. This new patch should resolve those problems.

Restored the views.view.profiles.yml view config file that was initially removed in Matt's patch but that was required to properly display profiles list when user have more than one profile at userProfileForm:

      // Render the active profiles.
      $build['active_profiles'] = [
        '#type' => 'view',
        '#name' => 'profiles',
        '#display_id' => 'profile_type_listing',
        '#arguments' => [$user->id(), $profile_type->id(), 1],
        '#embed' => TRUE,
        '#title' => $this->t('Active @type', ['@type' => $profile_type->label()]),
        '#pre_render' => [
          ['\Drupal\views\Element\View', 'preRenderViewElement'],
          'profile_views_add_title_pre_render',
        ],
      ];

Additionally I extended some tests to include configuration of the profile field on user entity to show in the default display mode. Attached an interdiff of the changes compared with Matt's initial patch.

Correct interdiff from last patch.

Added a testProfileFieldOnUserDisplayConfig() to check that profile field configuration at User entity display mode allow to customize the render configuration. Updated the interdiff with the last version.

All tests are passed so now need help from other developers to review and confirm that all is working as expected and hopefully @mglaman can review and commit the final patch. :)

The rendered entity of the profile works, but in /admin/structure/display-modes/view there are no profile display modes

@jwilson3

I know how to create a view mode.

The problem is that the profile view modes that it's created, are not listed on /admin/structure/display-modes/view

I have another problem. If I add the code {{ content.profile_personnel }} to the user's twig, the profile is not displayed.

The profile is displayed if I do not create a twig.

If I create a twig of the user display, the profile does not work.

Can you confirm ?

With this configuration, there is no identifier in the url :

{#
/**
 * @file
 * Default theme implementation to present all user data.
 *
 * This template is used when viewing a registered user's page,
 * e.g., example.com/user/123. 123 being the user's ID.
 *
 * Available variables:
 * - content: A list of content items. Use 'content' to print all content, or
 *   print a subset such as 'content.field_example'. Fields attached to a user
 *   such as 'user_picture' are available as 'content.user_picture'.
 * - attributes: HTML attributes for the container element.
 * - user: A Drupal User entity.
 *
 * @see template_preprocess_user()
 *
 * @ingroup themeable
 */
#}
<article{{ attributes.addClass('user--comment') }}>

  <div class="row">

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

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

  </div>

</article>

@jwilson3 I cleaned the cache and I do not see anything :-(

@jwilson3

#20 It works, but impossible to create a link to the profile (see screenshot).

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

  <div class="row">

  <a href="/profile/{{ content.personnel_profiles }}" title="{{ user.label }}">

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

  </a>

  </div>

</article>

Before applying the patch, the {{ content.profile_personnel }} code worked

This is working as expected. Thank you all for your work.

I needed the patch on the rc1 version so i rerolled it to work with it.

I'd say once the broader #2750059: Move the profile "registration" form to a field widget is fixed, anyone can leverage core's form display configuration to move and disable any profile or profile field.

1. I think it is different issue. #2750059: Profile fields to appear on manage form display for account settings is about manage form (!) display and this issue is about manage display.

2. I've fix the patch.
While creating user with:

$user = User::create([...]);

I have warning:

Automatically creating the first item for computed fields is deprecated in Drupal 8.5.x and will be removed before Drupal 9.0.0. Use \Drupal\Core\TypedData\ComputedItemListTrait instead.

Change record: ComputedItemListTrait has been added to standardize the behavior of computed fields

Used patch and field widget display settings appearing as expected.
Tested it with several different view modes as rendered entity.

git: dev commit "716e81dd0328bab469bf1574351c0de373d1ae9a [716e81d]"

+1 RTbC

Also can be applied to "5400cebed4afe4271095f003d754e0361aba5822 [5400ceb]"

@Martijn de Wit thanks for the screenshots! Helped test this before commit. I will be reviewing.

Don't know where my screenshot did go.. uploaded it again...

Finally sitting down so we can commit this :)

+++ b/src/Plugin/Field/ProfileEntityFieldItemList.php
@@ -0,0 +1,47 @@
+    // Ignore anonymous and user accounts not saved yet.
+    if ($user->id() === NULL) {
+      return [];
+    }

Anonymous user's do not have a uid of null, it is 0.

Fixing some phpcs. Will post patch with an interdiff.

Here is an updated patch to address #38. The problem I see is this: what about already configured extra display fields? Do we need some kind of upgrade path or just a change record so users know to reconfigure their profile displays on users?

The extra field used to be keyed ['profile_' . $bundle->id()] and now it is [$profile_type->id() . '_profiles']

Client work and DrupalCon derailed my effort to finish this up. Since no one has replied, I am going to give it a quick test. I will probably post another patch that puts the field keys back to the way they originally were.

Okay, I experimented with my thoughts in #40. When reusing the same keys, the following error shows up for already configured profile extra fields: Notice: Undefined index: type in Drupal\field_ui\Form\EntityDisplayFormBase->buildFieldRow() (line 367 of core/modules/field_ui/src/Form/EntityDisplayFormBase.php).

I'm going to open a change record that states end users embedding profiles on user pages will need a quick reconfigure.

Here's a new patch which removes an unused function that hacked in the View title, and the view display that used to be used.

CR: https://www.drupal.org/node/3048287

+++ b/config/install/views.view.profiles.yml
@@ -310,70 +309,3 @@ display:
-  user_view:

+++ b/profile.module
@@ -255,25 +255,6 @@ function profile_form_user_register_form_submit(array &$form, FormStateInterface
-function profile_views_add_title_pre_render($element) {
-  /** @var \Drupal\views\ViewExecutable $view */
-  if (isset($element['#title'])) {
-    $view = $element['view_build']['#view'];
-    if (!empty($view->result)) {
-      $view->setTitle($element['#title']);
-    }
-  }

Bah, this was still needed for ProfileController::userProfileForm

Okay, #41 just was a bad idea. Here is #39 again. If green, merge ahoy!

🎉Thanks everyone, committed.

Better title :)

Published the change record, but we'll want to flesh it out a bit too.

Just had the need for this when building a Search API index. Thanks y'all #partytimeexcellent