Extending the course metabox

Adding your own fields to the course and lesson editors.

The filter

add_filter( 'pom_lms_course_metas', 'my_course_fields' );

function my_course_fields( array $metas ): array {
    // Add or adjust field definitions.

    return $metas;
}

pom_lms_course_metas receives the full definition of the course and lesson editor fields — the tabs, their groups and the fields inside them — and must return it.

What the structure contains

The definition covers both post types. Courses have the Configuration, Sections and Lessons tabs; lessons have their own set of fields. Each field carries a label, a type, and whatever the type needs — options for a select, a description, whether the value is stored as its own post meta.

Add to the structure rather than rebuilding it. Returning a structure that omits the plugin's own fields removes them from the editor, which is how a site loses its access configuration.

Field types

The fields use the theme's form types — text, select, toggle, rich text, repeaters and the rest — so anything the theme's other metaboxes can render is available here.

Match an existing field of the same kind rather than inventing a shape: copy how the plugin defines a select, and change the label, name and options.

Naming

Prefix every field you add with something of your own. pom_lms_ is the plugin's namespace, and a collision means one of you silently overwrites the other's value.

What to add here, and what not to

Good candidates — anything that belongs to the course as a thing you sell or teach:

• A difficulty level or duration for your catalogue cards.
• An instructor other than the WordPress author.
• A code for your own reporting.
• Related-course links.

Bad candidates — anything that decides access:

Do not add a field that your own code then treats as an access condition. Access precedence lives in the helpers, and a second mechanism outside them is exactly the situation that leaks content when the order changes. If you need a different access condition, express it as a permission rule.

Reading your values

$metas = pom_lms_get_post_metas( $course_id );
$value = $metas['my_prefix_difficulty'] ?? '';

Fields declared to be stored as their own post meta are additionally readable with get_post_meta(), which is what you want for anything you need to query or sort by.

Displaying them

The editor stores your field; nothing displays it. Render it from your theme, using the template hooks — see Template integration.

Ordering and placement

Fields appear where you place them in the structure. Adding to an existing group puts your field among the plugin's; adding a group of your own keeps it separate, which is usually clearer for editors.

Give any group of your own a label naming your integration, so an editor who wonders where a field came from can find out.

Compatibility

The filter is stable. The exact contents of the structure are not — new releases add fields and may reorganize groups.

Write your filter so it survives that: locate what you need by key, add what you need, and return the array. Code that assumes a fixed number of tabs, or a field at a particular index, will break.