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}_enabledvetoes 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_*andfunctionalities_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.
Link Management
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 nofollowfunctionalities_exception_urls: the same, for individual URLsfunctionalities_json_preset_path: override the JSON preset file path or URLfunctionalities_link_preset_ttl: how long a remote preset is cached, 15 minutes by defaultfunctionalities_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 watchedfunctionalities_content_regression_snapshot: the snapshot itself, before it is stored, with the post object as the second argumentfunctionalities_content_regression_warnings: the warnings produced by a comparison, with the post ID as the second argumentfunctionalities_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 itemtypefunctionalities_schema_article_itemtype: the article itemtypefunctionalities_schema_article_content: the processed article markup, with the original as the second argumentfunctionalities_schema_language_attributes: the language attributes outputfunctionalities_schema_enabled: a per-request vetofunctionalities_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 outputfunctionalities_block_cleanup_content: the content after cleanup runsfunctionalities_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;
});Header and Footer Snippets
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 requestfunctionalities_snippets_ga4_enabled: whether the GA4 tag outputsfunctionalities_before_header_snippetsandfunctionalities_after_header_snippetsfunctionalities_before_footer_snippetsandfunctionalities_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 thefunctionalities_fonts_before_outputaction - Components:
functionalities_components_items,functionalities_components_css,functionalities_components_enabled,functionalities_components_file_path, plus thefunctionalities_components_before_outputandfunctionalities_components_updatedactions - 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.
Progressive Web App and Editor Links
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 servedfunctionalities_pwa_service_worker_config: the service worker configurationfunctionalities_pwa_excluded_paths: paths the service worker leaves alonefunctionalities_pwa_runtime_cache_limit: the cap on runtime cache entriesfunctionalities_pwa_enabled, plus thefunctionalities_pwa_manifest_outputandfunctionalities_pwa_sw_outputactions- Editor Links:
functionalities_editor_links_post_typesandfunctionalities_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 arrayfunctionalities_data_base_dir: the directory holding redirects, the 404 log, and task filesfunctionalities_admin_dashboard_tools: an action for adding your own tool to the dashboardfunctionalities_misc_option_{$key}: a dynamic filter on any single Performance & Cleanup togglefunctionalities_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.