Docs/Advanced Topics/Extensibility
Extensibility
The plugin's public surface — the filters, the read helpers, the field-definition shape — is a stable contract. Build against it from a theme or another plugin rather than editing plugin files directly.
Extend, don't modify
Add new fields, panels, metaboxes and post types from your own theme or a small companion plugin using tp_meta_boxes, tp_user_meta, and TPMeta_Options — all covered in the Developer Guide. This keeps your customizations intact across a Pure Metafields update, since nothing you wrote lives inside the plugin's own files.
React to saves instead of polling
Use tpmeta/options/saved (or the per-panel variant) to trigger side effects the moment a panel is saved — clearing a cache, regenerating a static CSS file, syncing to an external service. See Hooks & Filters.
Adjust sanitization instead of disabling it
Two extension points cover most customization needs without touching plugin internals:
sanitize_callbackon an individual option field — see Validation.- The
tpmeta_allowed_svg_tagsfilter, if your theme needs a specific SVG tag/attribute allowed through the default sanitizer — see Hooks & Filters.
Field types themselves aren't a public extension point
Each field type is a template file bundled with the plugin (under metaboxes/fields/ and options/templates/fields/) — there's no documented filter for registering an entirely new field type from outside the plugin. If a project needs a field type that doesn't exist, the supported paths are: compose it from a group of existing fields, add a sanitize_callback to shape an existing type's value, or open a request with ThemePure rather than patching the plugin's core files.
Isolate the change in its own file or a clearly separated section, so it's deletable without side effects when the plugin updates. Never change the public function/filter names listed throughout this guide (tpmeta_field(), tpmeta_get_option(), tp_meta_boxes, tpmeta/options/saved, …) — real themes depend on them.