The activity pub plugin sets some defaults for those fields on the client (here).
All category custom field changes are logged as category setting changes in core (here).
“1” (setting category custom field defaults on the client) seems to be the best way to work with the category custom field pipeline at the moment as the update category action will automatically save them, and you want to ensure the defaults are being set if the custom fields are interdependent (as they are in the AP plugin).
Note that it’s not currently possible for a plugin to selectively serialize custom fields to the server (without monkey patching).
Given the above, I’m wondering whether “2” makes sense? As David points out, given the current configuration of the pipeline, a change in a custom field doesn’t necessarily indicate a change in the settings configuration of the category (i.e. going from nil to the default).
Curious to hear others’ takes on this. Perhaps I’m missing a better way of handling category custom field defaults.
@david Just bumping this up your list again. Where is your gut on this? If you think a change to how category custom field saving might be needed in core I can give that shot. Or perhaps I’ll see if I can find a new way of setting defaults for custom fields. Or perhaps we leave it for now?
Yeah this is tricky. I suppose most plugins don’t run into this because their ‘default’ for the category setting is a null value.
Did you have an idea for a core API change which could help improve the situation?
Totally untested, but I think we might be able to swing something right now by using a raw HTML input field (note lowercase input instead of Ember’s two-way-bound <Input component).
With that strategy, we have control over how values are read/written to the model instance. So, if a value is set to the default in the UI, we can write that as ‘null’ in the custom fields: