Allow weighting profile types

Could you give us more of an idea of what the problem is here? I'd be happy to work on it, but admin/structure/profiles/manage/main/fields already has weighting that works as far as I can tell.

Yeah, I realised shortly after fiddling with #894026: basic UI for editing / creating types the mistake i'd made with this ticket.

Well, if I can get entity API writing the profile names then a sortable table should be the next logical step.

I can confirm based on work I've done on #894026: basic UI for editing / creating types that the admin interface needs work to provide weightings as per taxonomy. However, as that issue has already required me to edit the code for the main table UI, maybe we should weight for that issue to close before we work on this one, so we don't get merge problems. Thoughts?

s/weight for/wait for/ . Whoops.

Well, I went ahead and rolled a patch anyway. It shouldn't be hard to adapt when #894026: basic UI for editing / creating types is finished.

The basic idea is:
* Change the hook_menu callback to be drupal_get_form, with profile2_overview_types as its argument
* Return a workable Form API array with weights from profile2_overview_types

This Form API array creates an ugly but accessible form. It's then themed as follows:
* Register a new theme function in hook_theme, to match the form ID profile2_overview_types
* Write that theme function to take the Form API array and build a sortable table from it
* Write a submit function profile2_overview_types_submit to write weights

Finally, to get profile2_get_types to respect those weights:
* Add a function profile2_type_sort to sort an array of profile types by weight
* Implement that function via uasort in profile2_get_types

This seems to work, but the main limiting factor is still that the profile in code doesn't get a new weight. See #798784: Remove default fields and use EntityDB API to install/uninstall a default profile, though.

so, the UI has gone in. To update the current UI, we'd have to add additional overrides in the Profile2TypeUIController

Hey everyone,

One note on this issue: The weight selected for the profile type should determine the order of the profile types on:

1. The user account page
2. The tabs at user/[uid]/edit

Currently, the default 'Profile' type is displayed at the top of the user account page (oldest profile type first), but at the far right of the tabs at user/[uid]/edit (oldest profile type last). So it would be best to make this ordering consistent based on the weight.

--Ben

Is the patch against the CVS version of the code? I've got Profile2 in place on a site after discovering that D7 presently doesn't allow people to put fields on the user registration page.

I'm here because I can't drag the the fields from hidden to public spaces here /admin/structure/profiles/manage/main/display/account

I've only got 2 fields that seem to be able to be public, neither of which I seem to be able to control.

I was looking exactly for this feature I agree with BenK in #8 it's important that this order is used with the tabs on the user edit page. (Sorry I can't help during the need work step, but I can review the patch.)

Apparently it's using alphabetical order of the machine names so an interesting workaround in the meantime is to modify the machine names with numbers underscore for example 1_main, 2_whatever, 3_etc

Any progress on this? Seems like a fairly reasonable feature request. Subscribe.

well, at least we should expose the setting in the UI I guess.

Attached is a patch which does that + adds the user-profile stuff via the user-account extra fields. Thus, the weight really is just relevant for ordering the edit-tabs.

ops, wrong patch. This is the right one.

Any feedback on this?

Hey @fago,

I pulled down the git repository then tried to apply it:

$ git apply profile_weight.patch 
error: patch failed: profile2.admin.inc:68
error: profile2.admin.inc: patch does not apply

Don't think I did anything wrong here, but....

ok, I've re-rolled it.

#16: profile2_weight.patch queued for re-testing.

The updated version 7.x-1.2 still has problem to weight the profile type.

The patch seems to work, but I get a notice when visiting the user account "Manage fields" page.

Notice: Undefined index: user_view in profile2_field_extra_fields() (line 832 of sites/all/modules/contrib/profile2/profile2.module). 

if ($type->data['user_view']) {

I don't see anywhere in code where user_view would be added to $data. Is this a patch for 7.x-1.x-dev? Anyhow, removing the entire if() works for 7.x-1.2.

i had some success using phpmyadmin and manually changing the values there. look for this table: profile_type

On a previous site, I had sorted these in the theme which was an ugly solution.

Thanks to brayo4's tip in #14, I'm handling this on my current project with a simple module:

$profile_weights = array(
  'contact_information' => 0,
  'research' => 1,
  'biography' => 2,
  'attendance' => 3,
  'accommodations' => 4,
  'transportation' => 5,
);

function profile_weight_adjust($type, $weight) {
  $profile_weight_updated = db_update('profile_type')
    ->fields(array(
      'weight' => $weight,
    ))
    ->condition('type', $type, '=')
    ->execute();
}


foreach($profile_weights as $type => $weight) {
  profile_weight_adjust($type, $weight);
}

where you just need to set the keys and values in the $profile_weights array to your profile types and and weights.

Thanks for this solution.

But how does a non coder deals with this «module»? Any link to some explanations on how to use this king of «module»? Thanks.

This is still needed.

Thanks for the patch. all straightforward stuff there.

Ditto to #23 . Not only is 'user_view' undefined, it is nowhere else in the codebase.
Here is a clean re-roll against todays dev, with the bogus 'user_view' removed.

Managing user account display over in admin/config/people/accounts/display now lets me position the extra profile section where I want it.

hook_extra_fields is what allows the UI to define what order the profile chunks show up in on the user account page.
Works as desired here!

I believe - from looking at it, and hook_extra_fields that

>$extra['user']['user']['display']['profile_' . $type_name]

represents

$entity_id = 'user';
$bundle_id = 'user';
$display = 'display'; // This key is defined by hook_extra_fields
// Alt display key could be 'form' but that's unused as profile2 publishes tabs instead.

$profile2_key = 'profile_' . $type_name; // Unique to each profile.

  $extra[$entity_id][$bundle_id][$display][$profile2_key];

Will this be added to the next version of profile2?

I can confirm dman's patch in #27 lets me add weights to profile2's for displaying a user's account. Awesome! However, these weight do not appear to get captured when the profile2 and contained fields are exported to a feature.

I added comment to hook_info_extra_fields.

This patch fixes weight settings @ x affecting y

- admin/config/people/accounts/display : viewing a user

- admin/config/people/accounts/fields : register a user with profile types

- admin/structure/profiles : editing a user by ordering the tabs for profile types

[edit]

+++ b/profile2.admin.inc
@@ -64,6 +64,13 @@ function profile2_type_form($form, &$form_state, $profile_type, $op = 'edit') {
+  $form['weight'] = array(
+    '#type' => 'weight',
+    '#title' => t('Weight'),
+    '#default_value' => $profile_type->weight,
+    '#description' => t('When showing profiles, those with lighter (smaller) weights get listed before profiles with heavier (larger) weights.'),
+    '#weight' => 10,
+  );

The description could use some rephrase as these values only affect user/%/edit right?

Being able to order the tabs is a useful addition too. Good thought!

@dman: please RTBC if possible :)

Hi,

I applied the patch from #34. I works great for User-1. But other users get random results...

Is it save to put back original files from Profile_2?

Thanks

@Québec what do you mean with random result? On what pages. See the list on #34.

Please give more feedback on the errs then set issue to status: Needs work. Tnx.

You can revert back to original files. I'm not 100% sure as extra fields are defined which must be cleared so probably a 'Cache Clear All' does the job.

Hello,

the patch #34 works for me, I also check the users'accounts and the profile types get re-ordered as expected at their level too.

One thing that could be improved would be to display the profile types weight number directly in the profile types list page as an extra column, in spite of having to open each profile types to modify its weight.

Thanks

@sp-drupy: Thanks for reviewing. Have you tested for UID <> 1 too as @Québec noted?

(I agree with the weight settings in the lists but that is afaik done by the entity API module.)

If you think the patch works as expected please mark as RTBC.

Yes I tested both as admin and as normal users, and it seems ok on my side,
maybe some feedback from others before marking RTBC.

Sorry for this post. I rarely get results with patches. I certainly made a mistake. I will wait for the next version of the module. Again, sorry for wasting your time.

Steps to configure after applying the patch:

1. Clear the cache
2. Goto admin/structure/profiles
3. Edit each profile type and assign weights (> 0 is best) (this is a little clumsy as @sp-drupy noted in #39)
4. Goto user/register (check the order) for profile types defined to show on register.
5. Configure profile types order on config/people/accounts/fields and register + edit a user
6. Configure the display order on admin/config/people/accounts/display and view a user
7. Done.

I'm not sure what the relation is between the weights set on admin/structure/profiles versus config/people/accounts/fields (I guess the first sets the defaults of the latter. I clear cache to late)

I RBTC as @sp-drupy said it works and I have re-tested and move it into production based on 7.x-1.2

Hi,

I tried again and it worked. The patch did the job.

My mistake came from the fact (I think) that I applied the patch to 7.x-1.2 instead of applying the patch to the Dev. version.

Is the dev. version safe to use on a production site?

Thanks.

I personally dislike using dev versions as it is hard to revert to an older version as you cannot download a zipped version.

I've applied the patch to 7.x-1.2 + 894904-34 according to my log.

Please consider to release a new version with the above patch applied.

You should not change the version. The patch applies to the dev version :-)

The project owner should take this one from now on.

This issue was filed in August 2010, and a working patch was submitted in June 2012. I've already shipped patch #27 in a production site that went online earlier this year, since I didn't have a better workaround.

However, nothing appears to have been committed by the maintainers to the 7.x branch of this module since May 2012. All commits since then have been to the 8.x branch.

Would the proposed resolution be more readily accepted if one were to submit an 8.x version of the patch, so that it could be backported to 7.x?

@westbywest that's a good question.

As the patch is RTBC the maintainers could have indicated for a 8.x patch ... unfortunately nothing happened to this RTBC state so we are stuck.

You could try to create a 8.x patch yourself. That probably helps move this forward. I myself have no time/money left to help you with this :-(

Patch #34 applied on 1.2 and instructions #43 followed, works great.
Thank you clemens.tolboom !

Thanks, Clemens!

Your patch works perfectly.

sry for letting this lie so long. I gave it a test and noted that it didn't work when profile2 pages module is enabled for a profile type. Thus I added a check for the userView option and an according cache clear such that it gets updated when necessary.

Committed, thanks.

@fago thanks ... we even have a release :)

in #29, @dman how did you get all your profile types display settings to show? ie Set the display for each of your profile types. When I try all this I only get the default option to configure. None of my other profile types show for me to me able to manage the display for each.

I don't think there was anything special. If Patch #34 went in, and you are using a version that has that, then each profile type should have its own draggable section on the form and field management UIs