You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here is something I had in mind for a while, but haven't shared yet ! The relatively recent arrival of the "participant" syncing ability revive this questioning.
Let me start by recalling what is the situation "at the moment" then provide an use case and finally what could be an enhancement.
At the moment
Civi Only (not considering Acf)
Civi provide for bi-directional relationship, and these relationship are "characterized".
There are built-in "kind of" relationship, that may be or not applied between certain type of Civi-Contacts ; and a given relathioship has different labeling for A-> and B->A ; for instance "Child of" and "parent of".
Acf Only (not considering Civi)
Acf (and some extra module or custom coding within the Acf realm) provide for bidirectional relationship between Post ; theses relationship could be set within the same CPT or across different CPT depending on Acf group location.
To my knowledge, Acf relationship field can't be "characterised", there is no "type" of relationship (beyond mono/bi-directionality)
The UI is quite friendly for the editor, and displaying Acf relationship on frond end means templating within Acf realm.
Civicrm-wp-profile-sync
This plug-in add a type of Acf-field named CiviCRM Relationship field.
As Civi relationship are characterised, the field has an mandatory option to select the "type of" relationship, including the direction A->B or B->A.
In practice when editing posts, the Civicrm relationship field is an auto complete field which gather contact form CiviDB.
I'm not sure how it works, if it create a reationship between the CPT and the related contact, or "just" sync this Acf field with a sort of Civi Field containing one kind of relationship
Anyhow that is super powerfull.
Use case
set up
We have three type of Civi-Contact, and three CPT that are synced togather like this
There are several kind of relationship between individual, institution and lab so I'm not gonna list them all as one example is enough.
An individual may be an employee of and Institution, and an institution may be an employer of an individual.
Within Civi, handling this relationship is built in, and adding it to some contacts requires nothing more than editing a contact relationship.
Within Wp/Acf, handling this requires to create two ACF field group - respectively located in Wp-Cpt-Author and Wp-Cpt-institution - each containing a CiviCRM relationship field set to the proper type of relation and direction.
This is super great !
But there is a but...
Downside/ Limitation
The CiviCRM Relationship field creates a bidirectional-relation between the synced Civi-Contact. There is thus no relationship between the a Wp-Cpt-Author and a Wp-Cpt-Institution.
On the contrary, setting a bi-directional Acf relationship between two CPT wouldn't add this relation into Civi
This is sad for few reasons :
CiviCRM relationship field UI is not as nice as Acf relationship field
it is difficult to read an reorder related items when there or several of them
seach is limited to "free text" while Acf has taxonomy too.
you can't add/edit CiviContact from Wp UI, while Acf provide for inline add/edit of related post (as many level as you may want)
templating is more complicated has you can't use conventional Acf relationship templating design but need to get related post out of their CiviCRM-Contact-Id meta
Make ACF/CiviCRM relationship field smartly integrated
I think you start to see where I am heading :)
It would be absolutly awesome that setting an ACF relationship between two CPT that are synced with Civi-Contact, add the relationshp in Civi.
I'm not sure you get my idea but if not, I hope the following explanation of how might clarify my propo.
a new Acf Field type, let's say CiviCRM-Acf Relationshipwith
a dropdown field to set the type of relation, which value are collected from Civi
a toggle to enable bidirectional relationship between CPT (or no toggle and forced ON)
a multi selecf field to set the Acf relationship field involved in the bidirectional process
On post edit page, we would have a single "Acf relationship like" field where we define the related CPT.
Adding a value/CPT in such field would add a bidirectional relationship field between the two posts, let's say PostA and PostB, as well as add a bidirectional relationship - of the kind set in the CiviCRM-Acf Relationship field setting - between postA-synced-CiviContac and postB-synced-CiviContact
This would keeps relationship between Wp-Cpt and CiviContact neat across both Civi and WP ! Yay !
There is also one interesting extra feature that I may mention : Acf Relationship field can set to be multi-bidirectional-relationship, i mean one Acf relationship field on Cpt-author can be bidirectional with both an Acf Relationship on Cpt-Instutution and an Acf Relationship field on Cpt-Lab (belonging to thus three Acf field groups).
With this feature, author in Wp could have one Acf Relationship field which type of relation is "member of" that would be used for both member of an Institution or/and member of a Lab
Maintaining the synci of Civi relationship with this Acf set up is almost critical if we have to use Civi-Contact-Subtypes of Individual and Organisation synced in wp and having their own Acf field Group. Almost as if not it would probably also fails when sharing Acf Group between CPT, and as if not we could always create more Acf Relationship field to cover our need
As a botom line,the way I thought of is is that here the relationship is between the CPT only, but it also need to track when there is a change in the Civi-contact relationship , so the post also get updated (as it is now but diferently).
There is probably an other/better way to set this.
a more advanced on could be to use Acf group/flexible content field, containing one dropdown field to set the type of relation and one acf relationship field. It is more advanced as it would enable the editor to add any any kind of relationship and not only the one for which a relationship field was provided. The machinery behind would also be much more complicated.
Ok here we are
Now what are the pro and con of this (or any other implementation of this feature) ?
Pro :
relationship are truely/fully synced,
no need to navigate between WP and Civi to handle some or some other stuff (I could detail if needed)
let Wp editor only be editor, with no access to Civi, while still be able to set (some selected) relationships
easier to template as it is maintain Acf templating practices
Con :
one more field type means the plugin is harder/costly to maintain
more resource consumption as adding a relationship
any other ?
Ok I'm curious to the what do you think about that, especially if there are downside I haven't perceived
Cheers
The text was updated successfully, but these errors were encountered:
Hi @christianwach
Here is something I had in mind for a while, but haven't shared yet ! The relatively recent arrival of the "participant" syncing ability revive this questioning.
Let me start by recalling what is the situation "at the moment" then provide an use case and finally what could be an enhancement.
At the moment
Civi Only (not considering Acf)
Civi provide for bi-directional relationship, and these relationship are "characterized".
There are built-in "kind of" relationship, that may be or not applied between certain type of Civi-Contacts ; and a given relathioship has different labeling for A-> and B->A ; for instance "Child of" and "parent of".
Acf Only (not considering Civi)
Acf (and some extra module or custom coding within the Acf realm) provide for bidirectional relationship between Post ; theses relationship could be set within the same CPT or across different CPT depending on Acf group location.
To my knowledge, Acf relationship field can't be "characterised", there is no "type" of relationship (beyond mono/bi-directionality)
The UI is quite friendly for the editor, and displaying Acf relationship on frond end means templating within Acf realm.
Civicrm-wp-profile-sync
This plug-in add a type of Acf-field named CiviCRM Relationship field.
As Civi relationship are characterised, the field has an mandatory option to select the "type of" relationship, including the direction A->B or B->A.
In practice when editing posts, the Civicrm relationship field is an auto complete field which gather contact form CiviDB.
I'm not sure how it works, if it create a reationship between the CPT and the related contact, or "just" sync this Acf field with a sort of Civi Field containing one kind of relationship
Anyhow that is super powerfull.
Use case
set up
We have three type of Civi-Contact, and three CPT that are synced togather like this
There are several kind of relationship between individual, institution and lab so I'm not gonna list them all as one example is enough.
An individual may be an employee of and Institution, and an institution may be an employer of an individual.
Within Civi, handling this relationship is built in, and adding it to some contacts requires nothing more than editing a contact relationship.
Within Wp/Acf, handling this requires to create two ACF field group - respectively located in Wp-Cpt-Author and Wp-Cpt-institution - each containing a CiviCRM relationship field set to the proper type of relation and direction.
This is super great !
But there is a but...
Downside/ Limitation
The CiviCRM Relationship field creates a bidirectional-relation between the synced Civi-Contact. There is thus no relationship between the a Wp-Cpt-Author and a Wp-Cpt-Institution.
On the contrary, setting a bi-directional Acf relationship between two CPT wouldn't add this relation into Civi
This is sad for few reasons :
Make ACF/CiviCRM relationship field smartly integrated
I think you start to see where I am heading :)
It would be absolutly awesome that setting an ACF relationship between two CPT that are synced with Civi-Contact, add the relationshp in Civi.
I'm not sure you get my idea but if not, I hope the following explanation of how might clarify my propo.
CiviCRM-Acf Relationship
withdropdown
field to set thetype of relation
, which value are collected from Civitoggle
to enable bidirectional relationship between CPT (or no toggle and forced ON)multi selecf
field to set the Acf relationship field involved in the bidirectional processOn post edit page, we would have a single "Acf relationship like" field where we define the related CPT.
Adding a value/CPT in such field would add a bidirectional relationship field between the two posts, let's say PostA and PostB, as well as add a bidirectional relationship - of the kind set in the CiviCRM-Acf Relationship field setting - between postA-synced-CiviContac and postB-synced-CiviContact
This would keeps relationship between Wp-Cpt and CiviContact neat across both Civi and WP ! Yay !
There is also one interesting extra feature that I may mention : Acf Relationship field can set to be multi-bidirectional-relationship, i mean one Acf relationship field on Cpt-author can be bidirectional with both an Acf Relationship on Cpt-Instutution and an Acf Relationship field on Cpt-Lab (belonging to thus three Acf field groups).
With this feature, author in Wp could have one Acf Relationship field which type of relation is "member of" that would be used for both member of an Institution or/and member of a Lab
Maintaining the synci of Civi relationship with this Acf set up is almost critical if we have to use Civi-Contact-Subtypes of Individual and Organisation synced in wp and having their own Acf field Group. Almost as if not it would probably also fails when sharing Acf Group between CPT, and as if not we could always create more Acf Relationship field to cover our need
As a botom line,the way I thought of is is that here the relationship is between the CPT only, but it also need to track when there is a change in the Civi-contact relationship , so the post also get updated (as it is now but diferently).
There is probably an other/better way to set this.
a more advanced on could be to use Acf group/flexible content field, containing one dropdown field to set the type of relation and one acf relationship field. It is more advanced as it would enable the editor to add any any kind of relationship and not only the one for which a relationship field was provided. The machinery behind would also be much more complicated.
Ok here we are
Now what are the pro and con of this (or any other implementation of this feature) ?
Pro :
Con :
Ok I'm curious to the what do you think about that, especially if there are downside I haven't perceived
Cheers
The text was updated successfully, but these errors were encountered: