Using Copy Styles to transfer styling from a Bricks Form element’s ID to a global class also copies the form’s field definitions into that class. When the global class is subsequently applied to another form with different fields, Bricks generates field-specific CSS based on the original form’s configuration.
This causes unintended styling on the second form and is difficult to identify or correct through the builder interface.
Steps to Reproduce:
-
Create a Bricks Form element containing Name, Email, Phone, and Message (textarea) fields.
-
Set the Message textarea height to
150px. -
Configure additional styling on the Form element’s ID, such as input borders, backgrounds, and padding.
-
Use Copy Styles to copy the Form element ID’s styles to a new global class (e.g.,
ndig-form). -
Apply the new global class to the original form.
-
Create a second Form element with a different field configuration, where the fourth field is not a textarea.
-
Apply the same global class to the second form.
-
Save and inspect the second form’s frontend CSS.
Actual Result:
Bricks stores the original form’s entire fields array in the global class, including the textarea’s height: 150 setting.
When applied to the second form, Bricks generates:
.ndig-form.brxe-form .form-group:nth-child(4) {
height: 150px;
}
This incorrectly applies a 150px height to the fourth field of the second form, even though that field is not a textarea and has no height setting.
Removing the global class from the second form immediately resolves the issue. Removing the height setting from the second form does not, because the configuration is stored in the global class.
Expected Result:
Copy Styles should transfer reusable styling properties without copying the Form element’s field definitions or other content/configuration data into the global class.
Field-specific settings should not be inherited by unrelated form fields based solely on their position.
Workaround:
Export the global classes JSON, locate the affected class, and manually remove the fields array from its settings object while preserving the intended styling properties.
Additional Notes:
The issue persisted after switching to external CSS and regenerating styles. Examination of the exported global classes JSON confirmed the unwanted field definitions were stored in the global class.
This may affect other Bricks elements if Copy Styles similarly transfers content or structural configuration into global classes, but I have not run into that anywhere else yet.
