Christian Wach

I can’t be sure without digging into it, but it sounds like FormBuilder isn’t firing the usual pre/post hooks. Assuming it fires equivalent hooks, then yes, it would be possible.

Just to add that there would be additional complexity if you use separate CiviCRM “domains” per WordPress site – these can be very useful for more granular permissions when domains have been mapped to sites. If you don’t need different behaviours per site, then you should be fine as is.

I would recommend reading the activation docs for further information.

Does Profile Sync makes new users for site 2?

No, there is (by default) only one user table in WordPress.

Okay, that sounds like a multisite install to me… my question is really what you want this plugin to achieve in that multisite context? Is it just the First Name, Last Name and Email sync?

Hi Evelyne, it depends on what you want to do. I may be able to give a better response if you provide more details.

—

• This reply was modified 7 months, 3 weeks ago by Christian Wach. Reason: Replied by mistake

Also FYI in the previous issue, when I said “sounds like they’ve missed calling the appropriate actions on successful registration”, I meant that the User Registration plugin may not be firing the WordPress actions for this plugin to react to. Hard to tell since it’s paywalled.

• This reply was modified 9 months ago by Christian Wach.

Hi @entropea There is no official documentation as such – the code is self-documenting since all hooks and filters have appropriate docblocks. Your developer should be able to search for do_action and apply_filters to see everything that is available.

FWIW what you describe sounds like default CiviCRM behaviour for the WordPress-to-CiviCRM sync process, but CiviCRM Profile Sync behaviour for the CiviCRM-to-WordPress sync process.

Thanks for the report @megaphonejon – it seems to me that there should be proper checks for an existing CMS user in CiviCRM-Core before creating one. It shouldn’t be blindly creating a user.

You could try BP Groups CiviCRM Sync for groups. I can’t say for sure if this will work with BuddyBoss since it’s not free open source software – but BuddyBoss is allegedly compatible with BuddyPress plugins, so it’s worth trying.

For BuddyBoss Profiles, you could try the experimental code in this plugin by setting this constant to true in your wp-config.php file as test if it works the way you expect it to.

@patriciaclemente 0.6.1 is released.

@patriciaclemente Yes, that feature is coming in version 0.6.1 which I will release very soon.

Hi Konrad,

Thanks for looking at this – I’ll take a look at the updated forms-helpers.php code and assess.

Modules (including forms) will be actually fully rewritten from scratch in a coming new version. The issue stated here isn’t present on the new version.

I have written a number of custom Form Actions in various plugins, e.g. here for example. It would be great to be able to see what to expect in the upcoming version so I can prepare my plugins for the changes ahead – but I can’t find a development repo on GitHub or elsewhere. How can I go about doing so?

Cheers,

Christian

Hi Konrad,

Sorry if I misunderstood your initial request.

No worries – you’re amazingly responsive to support requests on here!

To make things more clear, can you please tell me where exactly do you need to read the uploaded attachment ID? In which ACFE Form hook?

It’s not just my custom Form Actions, it’s any Form Action that needs the WordPress Attachment ID during the make process when acfe_form_map_field_value() has been called during validation. This is why my “steps to reproduce” above use only built-in ACFE Form Actions to demonstrate the problem ??

So, for example, the “Email Action” fails to find a File ID at this point when the “User Action” has called acfe_form_map_field_value() during validation. This means that an uploaded File will not be added as an Attachment to the Email sent when a User is created.

The reason is that the acfe/form store data is only set once and, if this happens during validation, it will not contain the WordPress Attachment IDs from File Fields in make() methods. My suggestion for a fix is at the end of my original post.

Cheers,

Christian

Hi Konrad,

Thanks for the code but I am not trying to validate uploads – I want to read the ID of a WordPress Attachment that is the result of an upload:

• This is possible when there is no call to acfe_form_map_field_value() during validation.
• This is not possible in the situation that I described in the steps to reproduce above.

What seems to be required is a refresh of the ACF Extended acfe/form store after the validation process ends and before the make process starts – but there seems to be no hook available for me to do this independently, so I am asking for either:

1. A hook in ACF Extended after the validation process ends and before the make process starts.
2. A fix in ACF Extended that ensures that WordPress Attachment IDs are included in the acfe/form store data during the make process.

Edit: To put the problem another way… I can see that ACF updates the $_POST array with the WordPress Attachment ID(s) of any uploads once they are successful – but those changes are not ported to the acfe/form store data for retrieval with acfe_form_map_field_value() if that function has been called before the uploads have happened.

Cheers,

Christian

• This reply was modified 2 years ago by Christian Wach. Reason: Clarify problem