The module helps a lot motivating users to complete their profiles.
Are there also plans to support the new profile 2 module?

Thanks in advance
DocuAnt

Comments

laura s’s picture

Category: support » feature

+1. Subscribing (& recategorizing).

MacRonin’s picture

Title: Plans for Profile 2? » Plans for "Profile Complete Percent(PCP)" to work with Profile 2?

+1 subscribing and update title so it makes more sense on issue activity list and dashboard

bryancasler’s picture

subscribe

good_man’s picture

I still don't find benefit to use Profile 2 over core profile, any real need for Profile 2?

DocuAnt’s picture

The core profile module is no longer supported and deactivated in every fresh Drupal 7 installation. Profile 2 is the successor. I think this is a benefit to use profile 2. :-)

sw3b’s picture

+1 and subscribing

agent_danniel’s picture

Subscribing.
Profile 2 needs Profile Complete Percent(PCP) in 7.x

good_man’s picture

I'm sorry, I don't have enough time to work on this feature, but I can review patches.

ptmkenny’s picture

subscribing

Anonymous’s picture

@good_man #4:

Actually, AFAIK, profile core is deprecated in D7, not to be used only for migrating to Profile2.

brightbold’s picture

+1 subscribe.

bryancasler’s picture

subscribe

grasmash’s picture

quick note, I'm working on a patch for this. let me know if you'd like to collaborate.

I've currently added fields (correctly populating, saving, etc.) to each profile2 profile type while maintaining compatibility with the core profile module.

The next step is to actually get the block to generate correctly. I'll probably have it generate a separate block per profile2 profile type.

Any suggestions welcome.

grasmash’s picture

Status: Active » Needs review
StatusFileSize
new23.31 KB

This turned out to be a much larger job than I expected. But... it's alive.

Given that Profile2 does not attach fields directly to the user object, I had to significantly change the way that most of PCP's CRUD functions work. In the end, it means that PCP is much more entities friendly.

Many functions now require that you pass $entity_type as a parameter, with an optional $bundle parameter to help differentiate different profile2 profile types.

I've also changed the schema so that rather than storing Field IDs, the profile_pcp table stores Field Instance IDs (hence a change in column name to fiid). Since the same field can be shared across the core profile, and multiple profile2 profiles, this was a necessity. This also means that you'll have to reinstall pcp after applying this patch. This should eventually be handled with an update hook.

PCP now generates multiple blocks, one for the core profile and one for each profile2 content type. Given that we're dealing with multiple blocks, I had to change the CSS selectors in the tpl file, and also create unique entries in the {variables} table for each block.

I'm sure this needs some tweaking given that it's such a large patch, but please let me know if anything prevents it from be RTBC.

Thanks!

grasmash’s picture

crap. Just realized that pcp_delete_field_requireness() isn't working right. You were using 'field_name' to trigger a deletion from the profile_pcp table before... but now we need to just delete and instance... and I don't see a Field Instance ID in $form or $form_states.

BarisW’s picture

Matt, great work. Thanks for taking the effort in working on this.

You patch looks great. Just a few questions:
- After applying, does the module still work with core profile?
- Would you be so kind to add an hook_update as well? So that users don't need to reinstall the module after updating.

Thanks a lot, again. I'll test ASAP!

grasmash’s picture

Hi Baris,

I've actually already found 3 bugs. I've fixed two and I'm finishing up the third.

-This will still work with core profile
-I'll work on a hook_update.

I'll post another patch with fixes to these bugs:
-Improper saving of values on admin/config/people/accounts/fields/[field_name]
-Block variables error generated when block is 100% complete
-pcp_delete_field_requireness() not working correctly
-need to run through coder

BarisW’s picture

Great news! Do you want me to commit the patch with git-contribution? So it adds up to your name? Or would you like to become co-maintainer and do it yourself?

grasmash’s picture

Baris,

Either way works for me, I appreciate you offer to use git contrib.

I'd be happy to pitch and help you co-maintain any issues stemming from this patch-- I've become fairly familiar with the module.

Would you prefer me to branch the repo or just add a new 7.x-1.x version?

BarisW’s picture

Depends if you can get the hook_update working. If the module can just be updated without errors on already working installs, I'd be happy with a new 7.x-1.x version ;)

I'll make you co-maintainer. I'm quite busy with other modules, so any help is welcome!

grasmash’s picture

StatusFileSize
new50.54 KB

Thought I'd post the final patch. This is an aggregate of patches, so it's really just for reference.

I'll be pushing the changes to dev branch soon.

grasmash’s picture

Status: Needs review » Closed (fixed)

Baris,

I've committed these changes to the 7.x-1.x-dev branch of the project and added a note about the feature on the project page.

Please review the changes when you have time. I'd like your approval before tagging for release.

Thanks!