One screen, several jobs

Open a screen to edit it in Mobile App Manager → App Setup and you won’t find one long list of options. Instead you’ll see a row of sub-tabs across the top of the panel — General Settings, Layout Settings, and, depending on the screen type, Content Sections, Tab Bar Manager, and Add Item Form. Each one is a different layer of the same screen.

Here’s why the split makes sense: a content screen in a MAM app is juggling several jobs at once. It decides what data to show and how the screen behaves (General). It decides how each row in the list looks (Layout). If the screen groups its data, it decides which groups appear and in what order (Content Sections). It may carry its own mini navigation bar along the bottom (Tab Bar). And it may let users create new content from inside the app (Add Item). Cramming all of that into one giant form would overwhelm anyone — splitting it into sub-tabs lets you focus on one layer at a time.

Here’s what each sub-tab controls, why editing is divided this way, and which screens show which sub-tabs.

Why the sub-tabs are not always the same

Not every screen shows all five sub-tabs — what you see depends on the screen’s content type (its content class). Two rules drive this:

1. General Settings, Layout Settings, and Add Item Form show up for list-style content types — screens that render a scrollable list of items (list, off-directory, and calendar screens, for example). Simpler content types (a Web URL button, a Phone Call button, a Login button) have no list to lay out and nothing to group, so they skip the sub-tab UI altogether and show a single general settings form.
2. Content Sections and Tab Bar Manager appear only when the content type actually supports them. The builder simply asks the content class whether it has any content sections and any tab-bar buttons to offer — if the answer is no, that sub-tab stays hidden instead of showing up empty.

So the sub-tab row simply reflects what this kind of screen can do. If one is missing, nothing’s broken — that screen type just has nothing to configure on that layer.

The active sub-tab is tracked in the page URL (a subtab parameter) — open any screen and General Settings is what loads first.

The five sub-tabs

General Settings

This is the default sub-tab, and the one every editable screen has. It holds the screen’s core behavior and data wiring — the settings that decide what this screen is and how it acts: its title, its content source, role and visibility options, theming colors that fall through the settings cascade, and whatever screen-type-specific options the content class contributes. In the code, “general settings” means everything that isn’t specifically a list layout, a section grouping, a per-screen tab bar, or an add-item form.

For most screens, General Settings is the only sub-tab you’ll ever need. The rest are there for list-heavy screens that need finer control.

Layout Settings

Layout Settings controls how each row in a list looks — not the data itself, but how a single cell presents it. A layout defines a small grid of fields (several body fields plus a top-right field), an optional image (and whether that image is square), and a set of presentation toggles such as showing the distance to a location, removing left spacing, using a variable row height, setting an explicit row height, hiding the map marker, and a background color for the cell.

The key idea is separation: General Settings decides what items appear, and Layout Settings decides what one of those items looks like once it’s on screen. Pick a layout once and every row in the list inherits it — that’s also why the same layout definition gets reused across both the list and map presentations of the same screen.

Content Sections

Content Sections shows up only on screens whose content type groups its items into named sections. It controls which sections show and in what order. The content class supplies a default set of sections, and this sub-tab lets you turn them on or off and arrange them — with an implicit “All Sections” grouping standing in until you narrow things down.

Think of it as the table-of-contents layer: General Settings decides the data source, Content Sections decides how that data gets carved up and ordered on screen. If a screen type has no sections to offer, this sub-tab simply doesn’t appear.

Tab Bar Manager

Some screens carry their own small navigation bar — a set of action buttons specific to that screen (Favorites, Map, Email, Phone, Website, for example). The Tab Bar Manager sub-tab is where you configure those per-screen buttons, and it shows up only when the content type actually offers any.

Don’t confuse this with the app’s main tab bar at the bottom of every screen — that’s the app’s primary navigation, and it’s configured elsewhere. The Tab Bar Manager sub-tab here is scoped to this one screen, configuring only the contextual actions that belong to it. (See Related for the article that lays out the full navigation model.)

Add Item Form

Add Item Form lets a screen offer an in-app “create new item” flow — configure it, and users can add content from inside the app instead of just viewing it. The sub-tab wires up:

• Add Form — which form (a Gravity Forms form, when the forms manager is available) collects the new item’s data.
• Create status — whether items created this way are Published immediately or land In Review for moderation.
• Post Type — which WordPress post type the new item is created as.
• An icon for the add action (a plus icon).

This is the layer that turns a read-only list screen into a contribution surface. If you’d rather users not create content, just leave this sub-tab unconfigured.

How the layers fit together

The easiest way to keep all five sub-tabs straight is as a stack of concerns — from “what this screen is and how it behaves” down to “what a row looks like” and “what users can add”:

Each sub-tab saves independently — the form on one doesn’t carry the others’ values along with it — but all of them write into the same per-screen, per-role settings that the rest of the suite reads through the settings cascade. So a value you set on the Layout sub-tab for one role and one screen behaves exactly like any other per-screen setting: most specific wins, with global and code defaults standing behind it.

Because the sub-tab row is computed from the content type, it’s also an extension point: a sibling plugin can register a new screen type that contributes its own sub-tabs, following the same filter-driven pattern the rest of MAM Suite uses. For you as the admin, the takeaway is simpler: the sub-tabs you see are a faithful menu of what this screen can do, and editing one layer never silently disturbs another.

Related

• The settings cascade & theming: global theme, per-screen overrides — how a value set on any of these sub-tabs is resolved at build time.
• Content source vs. global settings: where a button’s data comes from — the General Settings sub-tab’s two kinds of inputs.
• Add a button: the content-type picker explained — why the content type is chosen first, and how it decides which sub-tabs appear.
• Tab bar vs. left menu vs. home buttons: the navigation model — how the per-screen Tab Bar Manager differs from the app’s main tab bar.
• Role-based settings: per-button, per-role, global — how each sub-tab’s values are stored per role.