Sync contact membership data to Acf field

[jbonlinea]

Hi there,

I've seen you started to merge civi-acf with this plug-in ! And this opens the way to sync contact to users ! Awesome, seriously you rock !

This is great as we can even sync Civi-custom field !

I realize that this "civi-acf" integration is still a recent project, which has already gone a long way, but there is one Civi feature that seems central, at least in my needs), and that is not covered yet, membership. Ok I'm just throwing a bottle.

Civicrm-ux provide fex shortcode to display memberhsip data, and Caldera-cf provide a processor to create the membership, which is great. However the experience I have with civi-acf let me belive in a much finer integration, so I'm writing it down :) (I could detail the bits I have in mind if you want)

This said, that you very much for this excellent plug-in, or should I say all of these excellent plug-inS !

Cheers

[christianwach]

there is one Civi feature that seems central, at least in my needs, and that is not covered yet, membership

@jbonlinea Are you looking for this?

https://wordpress.org/plugins/civicrm-wp-member-sync/

[jbonlinea]

Hi :)

there is one Civi feature that seems central, at least in my needs, and that is not covered yet, membership

@jbonlinea Are you looking for this?

https://wordpress.org/plugins/civicrm-wp-member-sync/

well I've been using this extensively ! The capabilities feature, which include membership type and membership status is genius :)

But, I haven't seen any way to retrieve the current user, or any user, membership and membership statut, like what this provide.

Of course members can be grouped according to their status, both in civi and in wp by syncing wp group with a term, or with a group from group plug-in.

But here the idea is actually simpler, and allow to change membership type and status form user/post edit screen with acf field,as well as end date, etc. This for three reason, first simplify the display of civi data, in this case membership in wp front end, secondly avoid user with no knowledge to go into civi (overwhelming) admin to modify their data, and third, get rid of civi user right, who can see what "issues", most user (roles) couldn't go to civi dashboard and just go in wp dashboard or use front end form to manage their data, including their membership.

Maybe there are easier way to do that rather than syncing the data between wp and civi, but I've been excavating in this way a long time without any good solution at least not nearly as powerful as civi-acf and this plug-in are :)

[christianwach]

@jbonlinea I don't understand why you'd want such a simple switch on the User record. Memberships are usually granted or revoked via payments, time limits (or other criteria) which are handled in CiviCRM. I wouldn't want my users switching their "Trial Grace Period" Membership into a "VIP Lifetime Membership"!

[jbonlinea]

Hi,

Indeed, I do agree with what you describe, and would like to add that not ALL membership data should be editable by the members themselves, but some may. For instance when membership gives you access to certain "things" that can be on physical support as well as electronic (newspaper, scientific journal, etc.).

They may want to chose the format they want, and may be offered the option to change it when they want. It might be nice to offer the possibility to these guys to edit some of their membership data. you simply prevent them to access to Civi dashborad, so no fuzz with civi acl, and can only edit selected field for themselves from a known environment (wp-dashboard), event if the best is still to build a front end form

Then, but this is secondary, it may be nice for the "small admin" not to have do dig into civi to edit membership changes

But not that I may be thinking of all this because of my experience with civi-acf, which basically brings civi and wp togather, whihc is what we want :)

Cheers

[christianwach]

@jbonlinea Comments noted. Thanks!

[jbonlinea]

Hi, Just to say that I bumped into this following the path, contact can be member, member get journal access 6 month before the other, access if offered for either electronic or paper. But as second thought, for many use case, adding the civi custom field to the contact rather than the membership would be perfectly fine.

If the Civi instance is multi-domain, with multi-organization, each having membership options, and if it is not critical that the contact custom field for holding the "custom membership data" remains private across institution, then we can also use a contact field. The only use (edge) case where having a custom field for membership data is critical is for civi instance handling multi-organization between which membership privacy is critical.

[christianwach]

@jbonlinea Closing because I think we discussed a possible solution to this using CiviRules and CiviCRM Group Sync elsewhere.

[jbonlinea]

@jbonlinea Closing because I think we discussed a possible solution to this using CiviRules and CiviCRM Group Sync elsewhere.

Yes this approach could work when we are not on a multidomain civi :)