The rewrite of custom fields on the JavaScript side broke several
aspects of text-based fields, causing rendering glitches and bad data
stored in extra_data. The following issues were found:
-
The registered field ID was often being used instead of the JSON
field name, preventing some fields from being looked up in any
payloads.
-
Similarly, a <fieldID>RichText
boolean was being looked up (and
saved) for custom fields, instead of using the
<json_field_id>_text_type
value.
-
These values were always being pulled out of extra_data, which
resulted in corrupted displays, as we were requesting HTML renders of
the values. raw_text_fields
should have been used instead.
-
The new dirty handling wasn't noticing changes to the Enable Markdown
checkbox, due to race conditions in calculation.
Fields now have mandatory jsonFieldName
and jsonTextTypeFieldName
(for text fields) attributes, which are guaranteed to be set. These are
used or provided wherever we may be working with extra_data
or
raw_text_fields
.
setDraftField()
and getDraftField()
now assert for required values.
getDraftField()
also now accepts some options for working with
raw_text_fields
.
Value loading for fields has been centralized in a _loadValue()
function, preventing some copy/paste for non-trivial calls. Same with
loading rich text booleans for text fields.
Unit tests have been introduced for custom fields to check all the
various states, preventing regressions in the future.