WPZylos Hooks

Clean API for WordPress hook integration with context-aware prefixing.

What You Get

HookManager — Fluent interface for add_action/add_filter
Automatic prefixing — Custom hooks prefixed via context
WordPress hooks unchanged — wpAction/wpFilter never prefix
Removal support — Track and remove callbacks cleanly
Type-safe callbacks — IDE autocompletion for parameters

Quick Start

use WPZylos\Framework\Hooks\HookManager;

$hooks = new HookManager($context);

// WordPress hooks (never prefixed)
$hooks->wpAction('init', [$this, 'registerPostTypes']);
$hooks->wpFilter('the_content', [$this, 'appendCta']);

// Custom hooks (always prefixed via context)
$hooks->doAction('settings_saved', $settings);  // → myplugin_settings_saved
$hooks->applyFilter('output', $html);           // → myplugin_output

Documentation

Overview — Hook system architecture
Installation — Setup
Usage — Core patterns
API Reference — HookManager methods
Examples — Real-world usage
Testing — Testing hooks
Security — Security notes
Troubleshooting — Common issues

Why We Did It This Way

WordPress Hooks Never Prefixed

add_action('init', ...) must remain init, not myplugin_init. WordPress core hooks are global by definition.

Custom Hooks Always Prefixed

Your plugin's custom events must be prefixed to avoid collision with other plugins using the same hook names.

// Two plugins both firing 'data_saved' would collide
// WPZylos prevents this by prefixing via context
$hooks->doAction('data_saved', $data);
// Plugin A: plugina_data_saved
// Plugin B: pluginb_data_saved

wpzylos-core — PluginContext for prefixing
wpzylos-security — Nonce verification in hooks

Troubleshooting

Overview