search

CFCommunity-net / buddypress-group-restrictions

Prevent group access to a group based on Member Type (BP 2.2+)
GNU General Public License v3.0
0 stars 1 forks source link

Manage member types thanks to xProfile component #6

Closed imath closed 9 years ago

imath commented 9 years ago

See https://github.com/CFCommunity-net/bp-mt-extended/issues/1

1/ Create a specific new Field type to manage member types in xProfile Field Admin UI : xprofile-field

2/ Include a migration tool

if the field that where containing the options used to type members is edited in favor of the new Member type field, then it will be possible using WP Admin > Tools > BuddyPress to migrate the field data as member types.

imath commented 9 years ago

NB: don't use this plugin with BP MT Extended activated, else nothing will happen.

BoweFrankema commented 9 years ago

Thanks a lot for you work on this imath, it's a very elegant solution to the problem. Sadly though there are a few issues related to how I've set up the site that I need to find a solution for. Both problems are related to not saving the xprofile value but saving it as a member type.

I'm relying on Brajesh (Buddydev) his conditional profile fields plugin to show/hide profile fields based on xProfile value (relationship with CF). https://github.com/sbrajesh/conditional-profile-fields-for-buddypress

Another similar issue is using checks to see if a user has completed his profile as I'm doing here: https://github.com/CFCommunity-net/cfcommunity/blob/master/wp-content/themes/cfcommunity/lib/buddypress/bp-hooks.php#L262.

The 2nd problem should be easy to fix by checking for a member type instead of a xprofile field value. The first problem is harder. We would have to show a certain xprofile field based on Member Type similar to Brajesh his plugin. If this makes things too crazy, the easiest (but ugly solution) would be to still save the xprofile field value as well as the member type. Unless you or @henrywright have any other brilliant solutions :-)

imath commented 9 years ago

Too bad :(

I guess the easiest way is to duplicate the member type in the xProfile data. That is to say remove the code i was using to prevent it :)

imath. http://profiles.wordpress.org/imath/

Le 7 avr. 2015 à 10:51, Bowe Frankema notifications@github.com a écrit :

Thanks a lot for you work on this imath, it's a very elegant solution to the problem. Sadly though there are a few issues related to how I've set up the site that I need to find a solution for. Both problems are related to not saving the xprofile value but saving it as a member type.

I'm relying on Brajesh (Buddydev) his conditional profile fields plugin to show/hide profile fields based on xProfile value (relationship with CF). https://github.com/sbrajesh/conditional-profile-fields-for-buddypress

Another similar issue is using checks to see if a user has completed his profile as I'm doing here: https://github.com/CFCommunity-net/cfcommunity/blob/master/wp-content/themes/cfcommunity/lib/buddypress/bp-hooks.php#L262.

The 2nd problem should be easy to fix by checking for a member type instead of a xprofile field value. The first problem is harder. We would have to show a certain xprofile field based on Member Type similar to Brajesh his plugin. If this makes things too crazy, the easiest (but ugly solution) would be to still save the xprofile field value as well as the member type. Unless you or @henrywright have any other brilliant solutions :-)

— Reply to this email directly or view it on GitHub.

BoweFrankema commented 9 years ago

Yeah.. it's not super elegant but for it's not a disaster either. And the good thing is that besides that everything is working as it should! Could you maybe uncomment/abstract the code you used to prevent the saving of the field?