Functionalities Hooks and Filters

  • JNext lesson
  • KPrevious lesson
  • FSearch lessons
  • EscClear search

Every module in Dynamic Functionalities can be changed from outside the plugin. The hooks and filters on this page are the supported way to do that, so a customization written today survives the next update instead of being overwritten by it.

There are more than 50 of them in version 1.6.1, and 44 carry their own description inside the plugin, listed on the settings screen of the module they belong to. Everything below goes in a theme’s functions.php or a small site-specific plugin. Nothing here requires editing plugin files.

How the Hooks Are Named

Every hook starts with functionalities_, so a single search across your codebase finds all of them, and 3 naming patterns cover almost the whole surface:

  • functionalities_{module}_enabled vetoes a module at runtime, per request, without touching its saved setting.
  • functionalities_{module}_{thing} filters a value that module works with, such as a list, a path, or a limit.
  • functionalities_before_* and functionalities_after_* are actions that fire around output.

The _enabled pattern is the one most people reach for first, because it turns a global setting into a conditional one. A module can be on everywhere and quietly skipped on the 1 template where it causes trouble.

The exception filters are the most used hooks in the plugin, because a trusted domain set in code survives a settings reset and a site migration, while one typed into a text box does not.

  • functionalities_exception_domains: the domain list that never receives nofollow
  • functionalities_exception_urls: the same, for individual URLs
  • functionalities_json_preset_path: override the JSON preset file path or URL
  • functionalities_link_preset_ttl: how long a remote preset is cached, 15 minutes by default
  • functionalities_link_update_batch_limit: batch size for the bulk nofollow tool
// Trust a partner domain everywhere, in code, so it survives a settings reset.
add_filter( 'functionalities_exception_domains', function( $domains ) {
    $domains[] = 'partner-site.com';
    return $domains;
});

Content Integrity

Content Integrity compares a post against its own stored snapshot on save, and all 4 stages of that are open:

  • functionalities_content_regression_post_types: which post types are watched
  • functionalities_content_regression_snapshot: the snapshot itself, before it is stored, with the post object as the second argument
  • functionalities_content_regression_warnings: the warnings produced by a comparison, with the post ID as the second argument
  • functionalities_content_regression_snapshot_saved: an action that fires after a snapshot is written
// Watch WooCommerce products the same way posts are watched.
add_filter( 'functionalities_content_regression_post_types', function( $types ) {
    $types[] = 'product';
    return $types;
});

The _snapshot_saved action is the useful one for a team workflow. It is where a Slack notice or an editorial log entry belongs, because it fires with the finished snapshot in hand rather than mid-comparison.

Schema

The Schema module writes microdata into rendered HTML, so its filters govern what type is claimed and whether the module runs at all on a given request:

  • functionalities_schema_site_itemtype: the site-level itemtype
  • functionalities_schema_article_itemtype: the article itemtype
  • functionalities_schema_article_content: the processed article markup, with the original as the second argument
  • functionalities_schema_language_attributes: the language attributes output
  • functionalities_schema_enabled: a per-request veto
  • functionalities_schema_before_buffer: an action that fires before output buffering starts
// Claim BlogPosting instead of Article on the blog, Article everywhere else.
add_filter( 'functionalities_schema_article_itemtype', function( $type ) {
    return is_singular( 'post' ) ? 'https://schema.org/BlogPosting' : $type;
});

Block Cleanup

3 filters cover the module: the class list, the processed content, and the runtime veto.

  • functionalities_block_cleanup_classes: the classes stripped from output
  • functionalities_block_cleanup_content: the content after cleanup runs
  • functionalities_block_cleanup_enabled: a per-request veto
// Strip an extra class everywhere, and skip cleanup on a documentation post type.
add_filter( 'functionalities_block_cleanup_classes', function( $classes ) {
    $classes[] = 'my-theme-helper-class';
    return $classes;
});

add_filter( 'functionalities_block_cleanup_enabled', function( $enabled ) {
    return is_singular( 'docs' ) ? false : $enabled;
});

Snippets expose 2 filters and 4 actions, which together let you decide whether a snippet outputs and put your own markup next to it:

  • functionalities_snippets_output_enabled: whether snippets output on this request
  • functionalities_snippets_ga4_enabled: whether the GA4 tag outputs
  • functionalities_before_header_snippets and functionalities_after_header_snippets
  • functionalities_before_footer_snippets and functionalities_after_footer_snippets
// Keep analytics out of the staging site without editing the snippet.
add_filter( 'functionalities_snippets_ga4_enabled', function( $enabled ) {
    return ( wp_get_environment_type() === 'production' ) ? $enabled : false;
});

Fonts, Components, and SVG Icons

These 3 modules generate CSS or markup, so each one exposes both the source items and the finished output. The items filters are the place to add something, and the CSS filters are the place to change how the output is written.

  • Fonts: functionalities_fonts_items, functionalities_fonts_css, functionalities_fonts_enabled, and the functionalities_fonts_before_output action
  • Components: functionalities_components_items, functionalities_components_css, functionalities_components_enabled, functionalities_components_file_path, plus the functionalities_components_before_output and functionalities_components_updated actions
  • SVG Icons: functionalities_svg_icons_list, functionalities_svg_icons_sanitize, functionalities_svg_icons_enabled

functionalities_svg_icons_sanitize deserves a warning rather than an example. It governs what survives the sanitizer, and loosening it to make one stubborn icon render is how a site ends up serving script inside an SVG. If an icon will not pass, the honest fix is a cleaner icon.

The PWA module has the widest hook surface of the smaller modules, because both the manifest and the service worker are generated:

  • functionalities_pwa_manifest: the manifest array before it is served
  • functionalities_pwa_service_worker_config: the service worker configuration
  • functionalities_pwa_excluded_paths: paths the service worker leaves alone
  • functionalities_pwa_runtime_cache_limit: the cap on runtime cache entries
  • functionalities_pwa_enabled, plus the functionalities_pwa_manifest_output and functionalities_pwa_sw_output actions
  • Editor Links: functionalities_editor_links_post_types and functionalities_editor_links_enabled

Plugin-Wide Hooks

5 hooks sit above the individual modules and are worth knowing even if you never touch a module filter:

  • functionalities_module_enabled: the master veto, receiving the enabled state, the module slug, and the full options array
  • functionalities_data_base_dir: the directory holding redirects, the 404 log, and task files
  • functionalities_admin_dashboard_tools: an action for adding your own tool to the dashboard
  • functionalities_misc_option_{$key}: a dynamic filter on any single Performance & Cleanup toggle
  • functionalities_misc_init: an action fired with the Performance & Cleanup options
// Turn every module off inside the REST API, whatever the saved settings say.
add_filter( 'functionalities_module_enabled', function( $enabled, $slug, $options ) {
    return ( defined( 'REST_REQUEST' ) && REST_REQUEST ) ? false : $enabled;
}, 10, 3 );

functionalities_data_base_dir is the one to handle carefully. The plugin stores its JSON files in a private folder with a randomized name, and pointing that filter somewhere web-readable puts your redirect map and 404 log back on the public internet. Move it only to another directory you know is unreachable over HTTP.

Where the Full List Lives

Each module’s settings screen carries its own hook list with a one-line description for each, which is the copy that ships with the version you are running. That makes it the reference to trust over any page written earlier, including this one, if the 2 ever disagree.

For the constants, option names, file layout, and uninstall behavior behind these hooks, the Technical Reference covers the rest of the developer surface, and the plugin changelog records when each of them arrived.