Can a custom Content Editor selector update two properties at once?

Question

Can a custom Content Editor selector update two properties at once?

Answer

Yes. A selector renders a single property, but it is not limited to writing one. Content Editor builds its form with Formik, and a selector can set any field in that form.

Jahia does this itself: editing jcr:title with the ordinary Text selector also updates the system name.

The supported way: register a selectorType.onChange

registry.add('selectorType.onChange', 'myEditorSync', {
    targets: ['MyEditorSelector'],
    onChange: (previousValue, currentValue, currentField, editorContext) => {
        const sibling = /* look it up in editorContext.sections */;
        editorContext.formik.setFieldValue(sibling.name, derivedValue);
        editorContext.formik.setFieldTouched(sibling.name, true, false);
    }
});

targets names the selector type this fires for. The fourth argument carries formik (the whole form bag), sections (the form definition), client (Apollo) and the editor context.

This is exactly the shape Jahia's own system-name sync uses - it targets Text and writes a different field entirely.

The alternative: useFormikContext() in the component

A selector component renders inside the Formik provider, so the hook works directly:

const {setFieldValue, setFieldTouched} = useFormikContext();

Jahia's built-in Picker selector does this. Use it when the second write is driven by something inside your component rather than by a value change.

Your component receives exactly these props: id, name, value, field, editorContext, inputContext, onChange, onBlur. Call the injected onChange for your own field and setFieldValue for the other one.

The field key is not the JCR property name

Formik keys are <fieldSetName>_<jcrPropertyName> - for example jnt:myComponent_mySvgProp - where the prefix is the declaring node type or mixin.

Do not hardcode it. Look the sibling field up in editorContext.sections and use its .name, which is what Jahia's own handlers do.

Three things that will silently lose your second value

The save path iterates every Formik value and matches it against the form definition, so:

1. The second property must be a field in the form. If it is not in the definition, the save loop never finds it and the value is dropped without error.
2. It must not be readOnly. Read-only fields are filtered out of the save.
3. visible: false is fine. Hidden fields are still saved. That is the clean way to carry a generated value - such as an SVG rendered from a JSON edit - without showing a second input. Hidden is not the same as read-only, and the difference decides whether your value survives.

On the common "it is not supported" answer

It is sometimes said that selectors map one-to-one to a property and cannot write more. That is true of the value a selector renders - value comes from formik.values[field.name] - but not of what it can write. The onChange registry is a first-class extension point: core uses it, and at least one shipped Jahia module registers one for its own custom selector.

What is genuinely rare is the specific case of writing two ordinary JCR properties. Jahia's own uses write the node name or manipulate mixins. The mechanism is the same; you would just be the first to point it at two plain properties.

This article was drafted with AI assistance, then reviewed and curated by Jahia Customer Support engineers before publication.