User sections (PRO)

Custom fields on the MODX user form: a phone number, a company, a business role, anything the standard profile does not have.

The mechanism is the same as for resource fields — a section with fields in it — with the context set to the user.

A section

Setting	What it does
Name	The caption of the tab or panel
Context	pbUser — this section belongs to the user form
Placement	tab, panel or default
Description	Text above the fields
Position	Order among the sections
Permissions	Which users and groups see it
Published	An unpublished section is not rendered

Where the values live

In modx_user_attributes.extended — the profile's JSON column, the same place MODX itself uses for extended profile data.

Read user fields through the profile, not the user

In MODX the user row holds little more than the username. email, fullname and every custom field live in the profile:

$user->email;              // empty
$user->profile->email;     // the value

This catches everyone once. A user list that renders blank cells is almost always this and not a missing value.

Saving happens after the core, deliberately

The fields are written on OnUserSave — after the MODX processor has run.

The order is not incidental. The processor rewrites extended wholesale from what the form sent it; writing first would mean writing into something the core then overwrites. Running afterwards is the only point at which the value survives.

Do not "optimise" this to an earlier event

OnBeforeUserFormSave looks like the natural place and silently loses every custom field. If you add your own handler for user data, hook the same event and for the same reason.

Fields on the front end

A profile form on the site is an ordinary controller and form: validate, then write through the profile. The section on the manager form and a form on the site are two views of the same storage — there is no separate front-end field mechanism to learn.