Settings extension

POM Events owns its settings page and exposes its definition through a filter, so an integration can add sections, tabs or fields.

The filter

add_filter( 'pom_events_settings', function ( $settings ) {
    // Inspect or extend the settings definition.
    return $settings;
}, 20 );

The definition is an array of sections, each with tabs and settings, in the shape POM Framework renders. The plugin's own License section is added through this same filter, which is a good indication of what it supports.

The existing sections

Key area Contains
General Whether attendee functionality exists
Archive Page size, dates, images, error message
Single event Header, title, calendar link, go-back, form clause, related content
License The subscription key

Add your own section rather than modifying an existing one where you can — it survives updates better and keeps your fields identifiable.

Adding a section

add_filter( 'pom_events_settings', function ( $settings ) {
    if ( ! is_array( $settings ) ) {
        return $settings;
    }

    $settings['my_events_extras'] = array(
        'title'         => __( 'Extras', 'my-plugin' ),
        'allowed_roles' => array( 'administrator' ),
        'tab'           => array(
            'my_events_extras_tab' => array(
                'title'       => __( 'Extras', 'my-plugin' ),
                'description' => __( 'Additional event options.', 'my-plugin' ),
                'settings'    => array(
                    'my_events_extras' => array(
                        'title'                   => __( 'Options', 'my-plugin' ),
                        'requires_initialization' => true,
                    ),
                ),
            ),
        ),
    );

    return $settings;
}, 30 );

The fields for a setting are provided by a fields.php returning an array of field definitions, in the framework's own format, located in the settings directory the definition points at.

Reading a value

Settings are stored in the pom-events namespace:

use POMFramework\POM_Framework_Settings;

$value = POM_Framework_Settings::get_setting_value(
    'pom-events',
    'events_archive',
    'posts_per_page',
    'number'
);

The four arguments are the page slug, the setting group, the field name and the field type. Pass the same type the field was declared with, so the stored value is re-sanitized on read.

Reading POM Events' own values

The identifiers you are most likely to need:

Group Field
events_general disable_events_attendees_functionality
events_archive posts_per_page, hide_events_date, events_list_loader, events_list_default_thumbnail, events_error_message
events_single single_event_disable_subheader, single_event_display_title, single_event_hide_add_to_calendar, single_event_display_go_back, single_event_form_clause, single_event_form_privacy_policy_link, single_event_header_image, single_event_display_featured_image_in_content, single_event_related_content_label

Checkbox values read as 'yes' or 'no', which is worth remembering when writing conditions.

The settings page works without the POM theme

Unlike the event runtime, the settings screen, the license section and the updater load regardless of the active theme.

An integration that only extends settings therefore does not need the theme guard. An integration that touches events does.

Do not store settings in the theme namespace

POM Events deliberately keeps its values under its own namespace. Adding event settings to the theme's options would break on a theme change and is not supported.