Native Content Fields for Posts and Pages

Content Fields let you add first-party custom data fields to posts, pages, lessons, modules, resources, events, taxonomy terms, and other content managed by BricksMembers. Post values save as normal WordPress post meta, and term values save as normal WordPress term meta, so they remain easy to read, easy to migrate, and compatible with the places where WordPress and Bricks expect content data.

Since version 1.3.0.

The goal is simple: if your membership, LMS, or community site only needs content fields for course metadata, lesson details, resource cards, catalog filters, or template conditions, you should not need a separate field plugin just to store that data.

This guide explains what Content Fields are, how they differ from profile fields and ACF-compatible fields, where you can edit values, and how to use them in Bricks Builder without cluttering the builder interface.

What Content Fields Are For

Content Fields are custom fields for content objects. They are useful when the data belongs to the lesson, course, page, event, resource, article, category, topic, or term itself.

Course metadata: duration, difficulty, course level, estimated study time, certificate type, or content format.
Lesson details: summary, instructor note, downloadable worksheet label, prerequisite note, resource URL, or internal review status.
Catalog filters: level, topic, format, language, cohort, or category-like values that should appear in Bricks Filter elements or Query Loop controls.
Template decisions: fields that decide whether a section, badge, warning, download block, or CTA should be shown in Bricks conditional logic.
Structured display data: repeatable rows, galleries, relationship fields, or grouped values that can feed Bricks query loops and dynamic tags.

They are not user profile fields. If the data belongs to a member, instructor, student, or customer, use Profile Fields. If the data belongs to a post or page, use Content Fields.

Content Fields vs ACF-Compatible Fields

BricksMembers can still work with ACF-compatible custom field runtimes in the Structure Content Editor. Those fields are owned by the external field plugin. Content Fields are different: they are owned by BricksMembers.

ACF-compatible fields: useful when a site already depends on ACF, SCF, or another compatible runtime. BricksMembers can show assigned groups in the Content Editor when that runtime is active.
Content Fields: useful when you want BricksMembers to own the field definitions, value sanitization, Bricks integration, headless exposure, AI/MCP catalog access, and future membership/LMS-specific workflows.

ACF is treated as a migration source, not as a runtime bridge. BricksMembers does not pretend to be ACF and does not register fake ACF field groups. If ACF is installed, it remains its own system. Content Fields are the native BricksMembers system.

Enable the Module

Go to BricksMembers -> Modules.
Enable Content Fields.
Open BricksMembers -> Content Fields.

The Content Fields page is where field groups are defined. A field group decides which post types, specific posts, taxonomies, or specific taxonomy terms should receive a set of fields.

The field group list stays compact, similar to the Profile Fields screen. Click Add Group or Edit to open a popup for the group. Inside that popup you can set the group label, status, description, location rules, and the fields that belong to the group.

Fields are also edited in a popup. This keeps the admin page usable when a site has many fields. Dynamic tags are always available for defined fields, while Structure Quick Edit, Bricks Filter element, Bricks Query Loop control, and Bricks condition exposure are separate switches that only appear as useful options for supported field types.

Field Groups and Field Keys

A field group contains one or more fields. Each field has a key, a label, a type, and optional settings.

The key is important because it is the real meta key. If your field key is course_level, the value is saved under the course_level meta key on the matching post or term.

Because the key is the live storage key, BricksMembers treats field keys carefully:

Field keys must be unique across all Content Fields groups.
Field keys are locked after the first save.
Field keys must not start with an underscore, because underscore meta keys are private in WordPress and are not suitable for normal Bricks custom-field output.
If you need to rename a field key, use the rename migration flow. Do not silently change the key in the definition.

The rename migration dry-runs first, then copies values from the old key to the new key and deletes the old key intentionally when you commit the migration.

Supported Field Types

Content Fields support practical field types for membership, LMS, and content-heavy sites:

Text fields: text, password, textarea, rich text, email, URL, oEmbed, number, range, true/false, select, button group, checkbox, radio, date, time, date/time, and color.
Media fields: image, file, and gallery. Values are stored as attachment IDs.
Compound fields: link. Link fields store URL, link text, and target together.
Relationship fields: post object, relationship, taxonomy, and user. Values are stored as IDs.
Structured fields: group and repeater.

The WordPress post editor, WordPress term editor, and Structure Content Editor use the native Content Fields value UI, so editors can work with scalar fields, links, media pickers, galleries, relationship selectors, taxonomy/user selectors, groups, and repeaters without editing JSON.

Editing Content Field Values

Once a field group matches a post, BricksMembers can show the fields in the places where content editors already work.

WordPress post editor: matching fields appear in a Content Fields meta box with the right control for each field type.
WordPress term editor: field groups targeted to a taxonomy appear on that taxonomy’s add/edit screens and save as normal term meta.
Structure Content Editor: matching fields appear in their own Content Fields section below the post body, using the same controls as the post editor.
Structure hierarchy Quick Edit: supported fields appear in the quick edit popup only when you enable Show in Structure Quick Edit for that field. This keeps the popup compact for fast edits.
Bricks Forms: use the BRM Update Content Fields form action when a frontend form should update fields for the current post, a configured post ID, or a mapped hidden Post ID field. Instructor Frontend Builder edit forms can use the mapped Post ID setup so scoped instructors can update Content Fields for the item they are allowed to edit.
AI/MCP abilities: when AI Abilities are enabled, agents can read the Content Fields catalog and prepare guarded value update plans through the BricksMembers ability layer.

Required fields are enforced on the server, not only in the browser. If a required field is missing during a save, BricksMembers returns an error instead of quietly storing incomplete data.

Using Content Fields in Bricks Builder

Content Fields are designed to be useful in Bricks without making the builder menus noisy.

Dynamic Tags Are Always Available

When the Content Fields module is active, dynamic tags are always available for defined fields. You do not have to opt a field into dynamic tags.

{brm_cf:course_duration}
{brm_cf:course_level}
{brm_cf:course_level:label}
{brm_cf:resource_group.resource_note}

Because scalar values are saved as normal post meta, Bricks native custom-field dynamic data can also read a field when you know the key. The BricksMembers {brm_cf:...} tags are still helpful because they are explicit, support nested group access, and can output readable choice labels with :label when a select, button group, radio, or checkbox field stores a separate value.

Repeater, Group, Gallery, Relationship, Taxonomy, and User Loops Are Always Available

Structured, media, and relational Content Fields can feed Bricks query loops. This is useful when a lesson has several resources, a course has a small gallery, or a template needs to loop through related lessons, instructors, topics, or users selected in a field.

Group fields can provide one structured row of values.
Repeater fields can provide one loop item for each row.
Gallery fields can provide one loop item for each selected image.
Relationship fields can provide one loop item for each related post.
Taxonomy fields can provide one loop item for each selected term.
User fields can provide one loop item for each selected user.

Inside a repeater or group loop, use {brm_cf_loop:subfield_key} to output the current row’s subfield value. For normal fields outside a loop, use the regular {brm_cf:field_key} dynamic tag.

Filter Element Exposure Is Optional

Bricks menus can become messy if every field appears everywhere. For that reason, Content Fields use separate opt-ins for Bricks Filter elements, actual Query Loop controls, and Bricks Conditions.

In the field popup, enable Show in Bricks Filter elements only for fields that should be used as visitor-facing filters. A course level select field, a language checkbox field, or a content format radio field are good examples.

Only field types that make sense as filter choices can be enabled for Bricks Filter elements. Do not turn every text field into a visitor-facing filter just because it exists. Most fields are better used as dynamic tags or Query Loop controls, while a smaller set of well-planned choice fields should become Filter element options.

Conditional Logic Exposure Is Optional

Bricks condition menus follow the same rule. Dynamic tags are always available, but condition options are opt-in per field.

In the field popup, enable Show in Bricks Conditions when a field should control template visibility. This keeps the Bricks condition picker focused on the fields you actually use for layout decisions.

When enabled, the Bricks condition key uses the field key, for example brm_content_field__course_level. This is useful for showing a badge only when a course is advanced, showing a resource block only when a true/false field is enabled, or hiding a section when a summary field is empty.

Public and Headless Exposure

Content Fields have a separate public/headless exposure setting. This controls whether a supported field can appear in public REST or headless output.

Dynamic tags are not the same as public REST exposure. A field can be available to your Bricks template while still staying out of headless API responses. Treat this as an external-exposure decision and leave it off for private notes, internal workflow fields, staff-only labels, or anything that should not be returned to an external client.

Migrating from ACF

Content Fields include an ACF migration path so existing sites can move data into BricksMembers-owned fields when that makes sense.

The migration tool scans the existing ACF field groups when ACF is available.
It prepares matching Content Field groups and destination keys.
It reads values by field type so IDs, relationships, media fields, groups, and repeaters are converted intentionally.
Dry-run manifests let you review matched posts and converted sample values before committing.

ACF migration does not mean ACF compatibility mode. After migration, the destination values are BricksMembers Content Fields stored as native post meta.

A Practical Course Catalog Example

Create a Content Fields group for lessons and course pages.
Add course_level as a select field with choices such as Beginner, Intermediate, and Advanced.
Enable Show in Bricks Filter elements so the field appears as a visitor-facing Bricks Filter element source.
Enable Show in Bricks Query Loop controls if the same field should appear as a native control on actual Bricks Query Loop elements.
Enable Show in Bricks Conditions if templates should show conditional badges or sections based on the same field.
Add course_duration as a text field. Leave Filter element exposure off, but enable Query Loop controls or conditions if you need those builder-side options.
Use {brm_cf:course_duration} and {brm_cf:course_level} in your Bricks card template.
Add a Bricks Filter element with source BricksMembers: Content Field and choose course_level.

The result is a cleaner Bricks interface: the field still works everywhere it should, but only the fields you chose appear in Filter element pickers, Query Loop controls, and condition pickers.

Quick Checklist

Use Content Fields for post, page, course, lesson, resource, event, category, topic, and taxonomy-term data.
Use Profile Fields for user/member/instructor data.
Choose field keys carefully before saving.
Use the rename migration flow instead of changing a saved key by hand.
Leave Bricks Filter element, Query Loop control, and condition exposure off unless the field should really appear in those builder menus.
Leave public/headless exposure off unless the field should be returned to headless or REST clients.
Use {brm_cf:field_key} for direct output and Content Field query loops for repeaters, galleries, and relationships.