lzb.editor.control.updateValue
Changes a control value on its way out, after the control component reports a change and before setAttributes or setMeta stores it. This is the mirror of lzb.editor.control.getValue, so a pair of handlers can keep one shape in the editor and another in the database.
Attributes
| Name | Type | Description |
|---|---|---|
val | Mixed | the value the control just produced |
control | Object | control settings: type, name, default, label, child_of, save_in_meta and the rest |
childIndex | Number | Boolean | row index inside a repeater, false outside one |
Additional Filters
| Name | Description |
|---|---|
lzb.editor.control.CONTROL_TYPE.updateValue | specific controls only |
The type-specific filter runs first and the generic one runs on its result.
For a control inside a repeater, both arguments have already been swapped before the filters run. control is the parent repeater, val is its whole array of rows with the new value written into row childIndex, and control.type is therefore the repeater's type rather than the child's. A type-specific handler registered on the child's type never fires for it.
Usage
wp.hooks.addFilter(
"lzb.editor.control.updateValue",
"my.custom.namespace",
function (val, control) {
if (control.type !== "my_json") {
return val;
}
return typeof val === "string" ? val : JSON.stringify(val);
},
);The return value is stored as it is, with no coercion on this side. A normal control goes through setAttributes({ [name]: val }), a meta control through setMeta under save_in_meta_name or the control name. That is also the value PHP reads on the front end, so a shape only the editor understands needs handling there too. Values are read back through lzb.editor.control.getValue, and checked before save by lzb.editor.control.validate.