Functionalities Technical Reference

This Functionalities developer reference collects the constants, option names, file layout, and hooks you need to extend or debug the plugin. Everything on this page describes version 1.6.1.

If you only remember one thing: every module stores its settings in exactly one option, every module is filterable, and nothing here requires touching plugin files.

Requirements and Constants

The plugin requires WordPress 6.3 or newer and PHP 7.4 or newer, and it is tested up to WordPress 7.1. The 6.3 floor is there so the SVG Icon block can use Block API v3 consistently; WordPress 7 features are feature-detected rather than required. Four constants are defined at load:

• FUNCTIONALITIES_VERSION: current plugin version
• FUNCTIONALITIES_FILE: absolute path to the main plugin file
• FUNCTIONALITIES_DIR: plugin directory path
• FUNCTIONALITIES_URL: plugin directory URL

File Structure

functionalities/
├── assets/
│   ├── blocks/svg-icon/   # SVG Icon block metadata
│   ├── css/               # admin styles
│   ├── js/                # admin + editor scripts
│   └── vendor/prism/      # bundled syntax highlighter
├── includes/
│   ├── admin/             # router + per-module controllers
│   │   ├── class-admin.php
│   │   ├── class-admin-ui.php
│   │   ├── class-module-docs.php
│   │   ├── class-settings-portability-controller.php
│   │   ├── class-site-health-controller.php
│   │   └── trait-admin-*.php
│   ├── core/
│   │   ├── class-module-registry.php      # lazy module registry
│   │   ├── class-upgrader.php             # version migrations
│   │   └── class-wordpress-7-integration.php
│   ├── features/          # one class per module, 16 of them
│   ├── storage/
│   │   ├── class-atomic-json-store.php
│   │   └── class-data-directory.php
│   └── traits/            # shared CSS sanitizer
├── languages/
├── uninstall.php
└── functionalities.php    # bootstrap + constants

Classes autoload from the Functionalities\ namespace, and Functionalities\Core\Module_Registry decides what loads. A frontend request with every module disabled loads no feature class files at all, and enabling one module loads only that feature and its shared dependencies. The admin bootstrap is a small router that hands module pages, settings portability, and Site Health to dedicated controllers.

There is no separate DOM-parser trait any more. Link Management, Block Cleanup, and Schema all edit attributes in place through the WordPress HTML API, so the only shared trait left is the CSS sanitizer.

Where Settings Live

One option per module, all prefixed functionalities_:

• functionalities_misc (Performance & Cleanup), functionalities_snippets, functionalities_link_management, functionalities_redirect_manager, functionalities_schema, functionalities_block_cleanup
• functionalities_login_security, functionalities_content_regression, functionalities_assumption_detection
• functionalities_fonts, functionalities_components, functionalities_meta, functionalities_editor_links, functionalities_svg_icons, functionalities_pwa, functionalities_task_manager

functionalities_svg_icons is written with autoload off on purpose, because the icon library holds full SVG markup and an autoloaded option is read on every request.

A second group holds runtime state rather than settings, and it is the group worth knowing about when you are debugging rather than configuring:

• functionalities_login_lockouts for the lockout log
• functionalities_assumption_audit, functionalities_assumption_scan_summary, functionalities_assumptions_last_run, functionalities_assumptions_detected, functionalities_assumptions_ignored and functionalities_inline_css_baseline for scan state
• functionalities_link_preset and functionalities_link_preset_last_good for a resolved JSON preset and its fallback copy
• functionalities_redirect_hit_buffer and functionalities_redirect_flush_buffer for hit counts waiting to be written
• functionalities_data_key, the random directory segment described below
• functionalities_version for upgrade routines, and functionalities_delete_data_on_uninstall, the opt-in uninstall flag

Where the Files Live

File-based data sits under wp-content/functionalities/, inside a per-site subdirectory whose name is 20 random characters generated on first use and stored in functionalities_data_key. That folder holds redirects.json, the opt-in 404-log.json, and a tasks/ directory with one JSON file per Task Manager project.

The randomized segment is the real protection, and the rest is defense in depth. Both the outer and the inner directory get an index.php, an .htaccess carrying deny rules for Apache 2.2 and 2.4, and an IIS web.config. A Site Health check then requests the folder over HTTP and reports what it actually gets back, rather than assuming the rules were honored, which is the only way to catch a server that quietly ignores all three.

The base directory is filterable through functionalities_data_base_dir. Point it only at somewhere you know is unreachable over HTTP, because a redirect map is a complete list of every URL you have retired and where each one now goes.

Redirect and task JSON writes go through an atomic store that takes a file lock, writes to a same-directory temporary file, and swaps it in. Other file writes use the WP_Filesystem API.

The Filter Surface

The plugin fires more than 50 hooks, and 44 of them carry a description inside the plugin itself, on the settings screen of the module they belong to. That in-plugin list is the one to trust, because it ships with the code you are running. These are the ones I reach for, by module:

• Link Management: functionalities_exception_domains, functionalities_exception_urls, functionalities_json_preset_path, functionalities_link_preset_ttl, functionalities_link_update_batch_limit
• Snippets: functionalities_snippets_output_enabled, functionalities_snippets_ga4_enabled, plus before and after actions on each of the header and footer
• Schema: functionalities_schema_site_itemtype, functionalities_schema_article_itemtype, functionalities_schema_article_content, functionalities_schema_language_attributes, functionalities_schema_enabled
• Block Cleanup: functionalities_block_cleanup_classes, functionalities_block_cleanup_content, functionalities_block_cleanup_enabled
• Content Integrity: functionalities_content_regression_post_types, functionalities_content_regression_snapshot, functionalities_content_regression_warnings, and the functionalities_content_regression_snapshot_saved action
• Assumption Detection: functionalities_assumption_detection_enabled (per detector) and functionalities_assumption_detection_warnings
• Fonts and Components: functionalities_fonts_items, functionalities_fonts_css, functionalities_components_items, functionalities_components_css, functionalities_components_file_path
• SVG Icons: functionalities_svg_icons_list, functionalities_svg_icons_sanitize
• PWA: functionalities_pwa_manifest, functionalities_pwa_service_worker_config, functionalities_pwa_excluded_paths, functionalities_pwa_runtime_cache_limit
• Meta and Editor Links: functionalities_meta_licenses, functionalities_meta_standalone_schema, functionalities_editor_links_post_types
• Redirects and Performance: functionalities_redirect_buffer_threshold, functionalities_misc_option_{$key}, functionalities_misc_feeds_disabled_message, and the functionalities_misc_init action

Three more sit above the modules. functionalities_module_enabled is the master veto and receives the enabled state, the module slug, and the full options array. functionalities_data_base_dir moves the data directory. functionalities_admin_dashboard_tools is an action for adding your own tool to the dashboard. Every module also respects a functionalities_{module}_enabled filter, so you can disable behavior per request without touching settings.

A Worked Example

The pattern is the same for every filter: small function, one decision, return the value:

// Trust a partner domain everywhere, set in code so it survives resets.
add_filter( 'functionalities_exception_domains', function( $domains ) {
    $domains[] = 'partner-site.com';
    return $domains;
});

The hooks and filters lesson works through the rest of them module by module, with the arguments each one receives.

Uninstall Behavior

By default, uninstalling leaves all options and files in place. If “Delete all plugin data when uninstalling” is checked on the dashboard, uninstall.php removes every option listed above, post metadata, transients, and the wp-content/functionalities/ directory. For the change history behind any of these APIs, see the plugin changelog.