Overview

WPZylos Hooks provides structured WordPress hook management with automatic prefixing for custom hooks.

Purpose

The hook manager solves a critical problem in WordPress plugin development: hook naming collisions. When multiple plugins use the same hook names, conflicts occur. This package provides:

1. Split Hook API - WordPress core hooks vs custom plugin hooks
2. Automatic Prefixing - Custom hooks are always prefixed with plugin prefix
3. No Core Hook Prefixing - WordPress hooks remain unchanged
4. Hook Tracking - Registry of all registered hooks

The Split API Pattern

WordPress Core Hooks (Never Prefixed)

Use wpAction() and wpFilter() for WordPress core hooks:

$hooks->wpAction('init', [$this, 'onInit']);
$hooks->wpFilter('the_content', [$this, 'filterContent']);

These are passed directly to WordPress—no modification.

Custom Plugin Hooks (Always Prefixed)

Use action(), filter(), doAction(), applyFilter() for custom hooks:

// Register listener (actual hook: myplugin_settings_saved)
$hooks->action('settings_saved', [$this, 'onSettingsSaved']);

// Fire custom action
$hooks->doAction('after_sync', $syncData);

// Apply custom filter
$value = $hooks->applyFilter('format_output', $rawValue);

Why This Matters

Without prefixing:

// Plugin A
do_action('settings_saved');

// Plugin B (conflict!)
do_action('settings_saved');

With WPZylos:

// Plugin A fires: plugina_settings_saved
$hooksA->doAction('settings_saved');

// Plugin B fires: pluginb_settings_saved
$hooksB->doAction('settings_saved');

Key Features

• One-time Hooks - once() auto-removes after first execution
• Hook Removal - removeAction(), removeFilter() with tracking
• Registry Access - getRegisteredActions(), getRegisteredFilters()
• Prefix Helper - prefix() returns prefixed hook name