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.