# Potential bug where data in custom fields is cleared if certain fields change

**URL:** https://meta.discourse.org/t/potential-bug-where-data-in-custom-fields-is-cleared-if-certain-fields-change/410050
**Category:** Bug
**Tags:** events, fixed
**Created:** [August 14, 2026, 5:59am UTC](https://meta.discourse.org/t/potential-bug-where-data-in-custom-fields-is-cleared-if-certain-fields-change/410050 "2026-08-14T05:59:42Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![zogstrip](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/zogstrip/32/512781_2.png) [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [August 14, 2026, 11:20am UTC](https://meta.discourse.org/t/potential-bug-where-data-in-custom-fields-is-cleared-if-certain-fields-change/410050/3 "2026-08-14T11:20:23Z")

</div>

Thanks for the report, it’ll be fixed by

> <https://github.com/discourse/discourse/pull/42624>
>
> Previously, values typed into the event builder's custom fields were cleared as …soon as another field changed (location, image, name, …), and toggling between the compact and advanced screens could permanently revert them to stale values.
> 
> This change commits custom field values through the form's \`set\` (a field's \`@onSet\` replaces FormKit's default write, so skipping it left the typed value out of the form data), replaces the \`customFields\` reference on every write (mutating inside the object never invalidated \`compactInitialState\`, so the compact screen served stale values back), and tracks \`formData\` (untracked, the advanced screen always reinitialized from the modal's construction-time snapshot).
> 
> Reported in https://meta.discourse.org/t/potential-bug-where-data-in-custom-fields-is-cleared-if-certain-fields-change/410050

---

_[View the full topic](https://meta.discourse.org/t/potential-bug-where-data-in-custom-fields-is-cleared-if-certain-fields-change/410050)._
