One of these things is not like the other

Your system is complex. Managing the complexity is a key pillar to the state of IT these days. You’ve got layers of abstraction that can be hard to diagnosis what is causing what: CiviCRM extensions, WordPress plugins, custom fields, CiviRules, and all the other settings and logic running in the background.

When something breaks, it’s not always one thing. It’s often the interaction between things.

That’s why the first step is reproducing the issue on a copy of production. That means staging, not guessing around in production. Just don’t.

Once you can reproduce it, you at least know where to look next.

Then strip things back to the simplest version that should work. Remove extra fields from forms, turn off user registration, disable unrelated plugins and extensions. Test. Then add things back one at a time.

This is the game I like to call: “one of these things is not like the other.”

Here’s a real example from today

A form submission was ending an active “resident of county” relationship. This traced back to a custom extension built for the client.

The reproduction steps of the issue:

1. Submit a Form Builder form.
2. Include address block with either a county field on the form or geocoding enabled, which was enough to trigger the extension logic.
3. Use a contact with an existing address in Apache County, Arizona.
4. Make sure that contact already has an active “resident of county” relationship to the Apache County organization.
5. Submit the form.
6. Result: the relationship gets an end date and is deactivated (bad behavior)

But it worked fine with this success scenario:

1. Submit a traditional QuickForm donation page instead.
2. Have address fields and county on the profile or geocoder enabled.
3. Use a contact with an existing address in Apache County, Arizona.
4. Make sure that contact already has an active “resident of county” relationship to the Apache County organization.
5. Result: the relationship stays active (expected behavior)

That told me the problem was not just the plugin. It was the interaction between Form Builder and the extension logic.

Root cause: Form Builder was submitting the address without a location type. The extension interpreted that as a location type change and correctly ended the relationship.

One subtle detail: when you add an address block to a form, CiviCRM requires a location type field. That’s unnecessary for some front-end forms, so I removed it, though the required flag doesn’t prevent you from removing it. Frankly, a reasonable fallback would be to use the default location type set in Administer > Custom data and Screens > Dropdown options > Location types if it is not set on the form.

Side tip: you can add field as “hidden” field type, so it sets it in the background. This could have worked around the issue but is error prone for users. Related: you may find this hidden option useful to hide “Country” on the form but still have the state/province field show the right states based on the default and hidden country.

But this is the reality of software: it’s always evolving. Edge cases like this slip through, especially when newish tools (like Form Builder) continue to mature.

Main point: Until a problem is reproduced and isolated, no one can fix it for you.

Here’s the deal:

So, reproduce it, strip it down to avoid conflating variables, and add things back one at a time. The scientific method never fails, though you will need some patience.

That’s how you go from “something is broken” to taking the next steps for you or your preferred CiviCRM partner to shepherd through the CiviCRM core issue queue, an extension’s issue queue and provide a fix.