Profiles, tabs and photos
The profile is the screen your members see most after the feed. It renders your Ultimate Member profile form, its tabs, and the photos attached to the account.
What a profile shows
Section titled “What a profile shows”- A cover photo and an avatar, both uploadable in the app.
- Profile fields from your Ultimate Member profile form, in the order the form defines.
- Tabs, including any contributed by extensions.
- Badges for user tags and verification, where those plugins are active.
Profile tabs
Section titled “Profile tabs”Tabs come from your site rather than from the builder, so a tab you added in Ultimate Member appears in the app without being configured twice.
Ordering follows your site. If you use Ultimate Member - Profile Tabs and reorder tabs there, the app follows.
Counts appear on titles. Follower and following tabs show live counts beside the tab name.
Tabs paginate. Long tab content loads more as the member scrolls, rather than truncating.
A Remote link tab configured in Profile Tabs opens the target natively where it points at a WordPress post or page, rather than opening a browser.
Avatars and cover photos
Section titled “Avatars and cover photos”Members can upload, reposition and delete both.
Repositioning keeps the original. The uncropped upload is retained, so a member who repositions a cover twice is working from the original each time rather than from a previously cropped copy.
Uploading needs the Uploaders endpoint group.
Uploading and repositioning an avatar and cover photo
record → src/assets/media/profile-photos.mp4
Editing a profile
Section titled “Editing a profile”The Edit Profile action renders your profile form’s fields as native controls. Supported field types include text, textarea, select, radio, checkbox, multiselect, date, and user location.
User location fields use the device’s location and show a static map, which needs a Google Maps API key set under Memberside → API Keys. See Connection and API keys.
Conditional fields work as they do on the web: a field configured to show or hide based on another field’s value does the same in the app, on both the profile and registration forms.
Field visibility
Section titled “Field visibility”The app respects the same privacy rules as your site. A field restricted to the profile owner is not returned for other members, rather than being returned and hidden — the data does not leave your site.
User tags
Section titled “User tags”Where user tag fields are configured, they render as badges on the profile. Tapping one opens the member directory filtered to that tag, so tags become a way to browse rather than decoration.
This needs a Directory feature placed, since that is where the tap goes.
When it does not work
Section titled “When it does not work”| Symptom | Cause | Fix |
|---|---|---|
| The profile is empty | The profile form has not opted into the API | Forms and directories |
| Fields are missing | They are restricted by privacy, or the form has several versions | Check the form’s field visibility |
| Editing saves nothing | The form the app writes to differs from the one it reads | Mark exactly one profile form visible to the API |
| Avatar upload fails | The Uploaders group is off | Enable it |
| A location field shows no map | No Google Maps API key is set | Set one under Memberside → API Keys |
| A tag badge goes nowhere | No Directory feature is placed | Place one |
| Tabs are in the wrong order | Ordering comes from Profile Tabs on your site | Reorder there |