Component: Pro Forms → Webhook Action
File: includes/elements/pro-forms/actions/webhook.php
Tested on: BricksForge 2.2 / WordPress / PHP 8.x
Bug 1 — Fatal Error: explode() receives array when checkbox field is used
What happens
Submitting a Pro Forms form that includes a checkbox field and a Webhook action causes a PHP fatal error and a 500 response from the REST API endpoint (/wp-json/bricksforge/v1/form_submit), preventing the form from submitting entirely.
Error log
PHP Fatal error: Uncaught TypeError: explode(): Argument #2 ($string) must be of type string, array given
in …/bricksforge/includes/elements/pro-forms/actions/webhook.php:82
Root cause
Line 82 calls get_form_field_by_id() on $d[‘key’] — the webhook mapping key:
$keys = explode(‘.’, $form->get_form_field_by_id($d[‘key’], null, null, null, null, false));
get_form_field_by_id() resolves the key as if it were a form field ID, returning its current value instead of the literal key string. When the key matches a checkbox field, the returned value is an array, which causes explode() to fatal error.
How to reproduce
Create a Pro Forms form with a checkbox field (e.g. field ID options)
Add a Webhook action with a data mapping where the key is options and the value is {{options}}
Submit the form → 500 Internal Server Error
Bug 2 — Webhook mapping keys resolved as field values instead of used as literals
What happens
Even without a checkbox field, webhook mapping keys are incorrectly resolved through get_form_field_by_id(). This means the key name gets replaced by the current value of whatever field shares that ID, resulting in a completely garbled payload sent to the webhook endpoint.
Example
Given this webhook mapping:
KeyValuecategory{{category}}full_name{{full_name}}email{{email}}The payload actually sent becomes:
electronics=electronics
John Smith=John Smith
john@example.com=john@example.com
Instead of the correct:
category=electronics
full_name=John Smith
Root cause
Same line 82 — get_form_field_by_id() should only ever be called on values ($d[‘value’]), not on keys ($d[‘key’]). Keys in the webhook data mapping are literal destination field names and should never be looked up as form field references.
Fix
Replace line 82:
// Buggy
$keys = explode(‘.’, $form->get_form_field_by_id($d[‘key’], null, null, null, null, false));
With:
// Fixed — keys are always literal strings, never field ID lookups
$keys = explode(‘.’, (string)$d[‘key’]);
This single change fixes both bugs simultaneously:
Keys are always used as-is from the webhook mapping config
No array is ever passed to explode() regardless of field type
Additional note — single-element arrays in form-data mode
When using content_type: form-data, radio button and single-selection checkbox values are serialised by http_build_query() as field_name[0]=value instead of field_name=value, because field values are stored internally as arrays. This can be addressed by flattening single-element arrays to their scalar value before the payload is built, e.g:
$webhook_data = array_map(function($value) {
if (is_array($value) && count($value) === 1) {
return reset($value);
}
return $value;
}, $webhook_data);
Environment
Multi-step Pro Forms form with conditional wrappers
Checkbox field with multiple options
Radio button field
File upload field
Webhook action with form-data content type
External webhook receiver (e.g. n8n, Make, Zapier)