This seems SO basic. I have two actions for a newsletter signup: make user, and add role. The issue is, I also have Surecart running, which will make users if they buy anything from the store. So, if someone has bought something on the store, signing up for the newsletter will fail because the user already exists.
I want the form to check if a user already exists, and if they don’t, make the user and give them the “newsletter” role. If the user already exists, DON’T FAIL, just add the “newsletter” role.
So I’ve spent a week and a half trying to get this functionality, and I’m deep into PHP programing, but hitting a wall trying to get the form field data into the snippet (I’m able to import the correct array for the form, but have no idea how to actually see what’s inside so I can match up the variables.) After a full day of blindly trying everything I can think of, and getting the feeling that I must be the only person in the history of the interned to ever try to accomplish this task…
I’m taking a step back and just asking simply: Is there an easy way to just skip making a new user and continue on with the rest of the form’s submission actions if the user already exists?
thanks for the detailed description, and sorry for the wall you hit. Short answer first: no, the User Registration action has no “skip if the user already exists” option. The action validates username and email up front, and if either one already exists it stops the whole submission with an error, so none of the other actions run.
So for your case (create the user only if needed, always add the newsletter role) the clean way is to drop the Registration action and do both steps in the Custom action. The Custom action fires the hook bricksforge/pro_forms/custom_action and hands you the form object, which is exactly the piece you were missing. Here is a complete snippet:
add_action('bricksforge/pro_forms/custom_action', function ($form) {
// Optional: only run for this form (Pro Forms element ID)
if ($form->get_form_id() !== 'abc123') {
return;
}
// "email" is the Custom ID you gave the email field
$email = $form->get_form_field_by_id('{{email}}');
if (!is_email($email)) {
return;
}
$user_id = email_exists($email);
if (!$user_id) {
$user_id = wp_insert_user([
'user_login' => $email,
'user_email' => $email,
'user_pass' => wp_generate_password(),
'role' => 'newsletter',
]);
if (is_wp_error($user_id)) {
return;
}
}
$user = new WP_User($user_id);
$user->add_role('newsletter');
});
Two things that should save you the guessing:
To see what is inside the submission, log the raw fields once: error_log(print_r($form->get_fields(), true)); and look at wp-content/debug.log (WP_DEBUG_LOG has to be on). The keys are form-field-, so a field with the Custom ID “email” arrives as form-field-email.
You do not need to touch that array directly. $form->get_form_field_by_id(‘{{email}}’) resolves the same {{field_id}} syntax you already use in the email action and gives you the plain value. Same for any other field, e.g. {{first_name}}.
With this setup an existing SureCart customer just gets the extra role and the rest of your actions (email, redirect and so on) continue as normal.
Ah, yes. I was finally able to get this functionality this morning and was about to make a followup post about it… but your snippet is SO much cleaner than mine! I’m totally using it.
So instead of sharing the code I came up with, (which is much less polished), I’ll just share a few things that will hopefully save some other people with my experience level a little time. This will also serve as a self-imposed test, to validate or correct what I’ve learned through this experience. So anyways, here are some basic things that were surprisingly hard for me to figure out:
First, where does the custom code even get put?
As it turns out, Wordpress websites operate like a bell choir. The choir director holds up a card (the webhook) and the choir members respond by ringing the bell they’re holding if it’s a match (running the code snippet).
So that’s why the form’s custom action doesn’t have any settings to specify where the custom code is: The custom code runs continuously in the background of the site, watching, and performs its action when the submit button activates the hook.
The easiest way to make this happen is to use a code snippet manager (I settled on FluentSnippets).
And again, the Snippet manager itself doesn’t need to be told where to look for the form’s action trigger; that’s done in the “add_action” section of the snippet code itself. The conditional logic in the snippet manager just controls under what conditions the entire snippet is active or inactive.
Next, in what format is the form information transferred to the to the snippet, and how can I see what’s being sent?
The snippet itself is written in a programming language called “PHP,” and the form data is packaged into “associative array.” That’s what you need to look up to understand what’s going on.
To see the actual contents of the array, you have to write it to a file on the wordpress server. This is done with the “print_r” command, and needs the “true” option to print the actual contents of the array. The file can then be read by accessing the server via a terminal or web-based file browser.
However, as Daniele so helpfully pointed out, you don’t need to reference the actual key names like I did. Being able to reference fields by ID is very nice (thanks!)
This one wasn’t an issue for me, since I’ve done a lot of bash scripting, but I can see it tripping up other beginners. So lastly, those parts of the code that start with “$” are called variables. You NEED to understand how they work if you’re going to get anything done, so take the time to read up on them if you aren’t already familiar with how they work.
Hopefully this saves a bit of time in knowing what to research for those of us who don’t just like to be told what to do, but also understand why it works.
