How to List WordPress Hooks: A Practical Developer Guide

When you need to list WordPress hooks — actions, filters, and their callbacks — there are six reliable approaches: read the $wp_filter global at runtime, hook into the special all meta-hook to capture firing order, use WP-CLI, install Query Monitor, run static analysis on the source code, or rely on the WordPress Plugin Handbook reference. Each works in a specific context, and developers who know which to reach for save hours debugging plugin behavior or building auto-generated hook documentation.

The most common use case is debugging: a callback you registered is not firing, or you suspect a third-party plugin is hooking into the same action with higher priority and overriding your work. The diagnostic is “tell me everything attached to this hook.” A close second is documentation: writing a plugin and wanting to enumerate every do_action() and apply_filters() you emit so integrators know what they can hook into. Both are answered by listing hooks correctly.

Quick verdict: use $wp_filter for runtime registration data; use static grep for source-level hook emissions; use Query Monitor for the firing order on a specific request; use WP-CLI for one-off scripted queries. This guide covers all five with working code patterns, plus a custom admin page that lets you browse the entire hook registry visually.

list WordPress hooks: quick reference

If you are evaluating list WordPress hooks for your next project, you are weighing real trade-offs between cost, complexity, ownership, and time-to-launch. The right list WordPress hooks decision depends on a handful of variables — team capacity, scope clarity, and how much ongoing maintenance you can absorb. The summary below is the 60-second version; the rest of this guide unpacks the nuance.

• list WordPress hooks pricing typically ranges based on scope clarity, integration count, and ongoing support requirements.
• list WordPress hooks timelines vary from days (small scope) to months (enterprise scope) depending on complexity.
• The biggest variable in list WordPress hooks is requirements clarity at the brief stage — vague briefs produce vague quotes.
• Vendor selection for list WordPress hooks matters more than tool selection — the right team beats the right stack.
• list WordPress hooks ROI is positive when scope is bounded, deliverables are specified, and success criteria are measurable.

For complementary perspectives on list WordPress hooks, the WordPress Plugin Handbook — Hooks reference and WooCommerce official hooks reference resources cover adjacent angles worth reviewing alongside this guide. They focus on the underlying technology and standards — this post focuses on the list WordPress hooks decision specifically.

When you revisit your list WordPress hooks approach in 12 to 24 months, three signals usually indicate a refresh is justified. First, the original brief no longer matches business reality — product, audience, or operational scope has shifted. Second, the underlying technology has moved forward enough that the list WordPress hooks decision made under previous constraints would be different today. Third, ongoing maintenance overhead has crept up beyond what was forecast at launch. None of these are emergencies on their own; together they signal it is time to revisit fundamentals rather than patch around them.

Why list WordPress hooks?

Real-world reasons developers need to list WordPress hooks:

• Debugging callback ordering — when your callback is overridden by another plugin or theme, you need to know what else is hooked at what priority
• Auditing a third-party plugin — figuring out what a plugin hooks into BEFORE you install it on a production site
• Documentation — auto-generating hook reference docs for your own plugin so integrators know what to hook into
• Compatibility testing — identifying conflicts between plugins that hook the same action with similar priorities
• Performance investigation — finding hooks with hundreds of callbacks (a sign of bloat) that may slow page loads
• Plugin / theme migration — mapping the hooks an outgoing plugin uses so a replacement plugin can re-implement them
• Building developer tools — admin dashboards that show hook usage, like the Query Monitor approach

The $wp_filter global — where WordPress hooks live

$wp_filter is a global associative array WordPress uses internally to track every hook and its callbacks. Understanding its structure is the foundation for listing hooks programmatically.

• Keys — hook names as strings (e.g., init, the_content, woocommerce_after_cart_form)
• Values — WP_Hook objects (since WP 4.7; before that, they were plain arrays)
• WP_Hook->callbacks — keyed by priority (integer), then ordered array of callback definitions
• Each callback definition — array with two keys: function (callable) and accepted_args (integer)
• The function callable — can be a string (function name), an array (object + method, or class + method), or a Closure

Actions and filters share the registry: WordPress does NOT separate actions from filters internally — both live in $wp_filter. The distinction is purely behavioral at the call site: do_action() doesn’t collect return values, apply_filters() does. You can technically hook a callback into a “filter” using add_action() and it works — the function names are convenience aliases for the same underlying mechanism.

Dump the entire WordPress hook registry

The fastest way to see every registered hook on a page load — drop this snippet into your child theme’s functions.php or a small debug plugin, then trigger it with a URL parameter:

// Dump the entire WordPress hook registry to the debug log.
// $wp_filter is a global associative array keyed by hook name.
// Each entry is a WP_Hook object containing all callbacks attached
// to that hook at that priority.

add_action( 'wp_loaded', function () {
    global $wp_filter;

    // Filter to admin + your user only to avoid leaking on the front-end.
    if ( ! is_user_logged_in() || ! current_user_can( 'manage_options' ) ) {
        return;
    }
    if ( ! isset( $_GET['raj_dump_hooks'] ) ) {
        return;
    }

    error_log( '=== WordPress hook registry dump ===' );
    error_log( 'Total registered hooks: ' . count( $wp_filter ) );

    foreach ( $wp_filter as $hook_name => $wp_hook ) {
        $priorities = array_keys( $wp_hook->callbacks );
        error_log( sprintf( '%s — %d priority level(s)', $hook_name, count( $priorities ) ) );
    }
} );

// Trigger: visit any admin page with ?raj_dump_hooks=1 while logged in.

Visit any page with ?raj_dump_hooks=1 while logged in as admin. The hook registry dumps to wp-content/debug.log (requires WP_DEBUG_LOG enabled in wp-config.php).

List all WordPress action hooks programmatically

For a structured list of every registered action with its callback count, build a helper function:

// List every registered action hook + its callback count.
// WordPress doesn't separate actions from filters internally —
// they share the $wp_filter registry. The technical difference
// is purely whether you call do_action() or apply_filters() at runtime.

function raj_list_action_hooks() {
    global $wp_filter;

    $hooks = array();
    foreach ( $wp_filter as $name => $wp_hook ) {
        $callback_count = 0;
        foreach ( $wp_hook->callbacks as $priority => $callbacks ) {
            $callback_count += count( $callbacks );
        }
        $hooks[ $name ] = $callback_count;
    }

    // Sort by name for readable output
    ksort( $hooks );

    return $hooks;
}

// Usage: print_r( raj_list_action_hooks() );
// Output: array( 'admin_init' => 12, 'init' => 47, 'wp_loaded' => 8, ... )

The output is a flat associative array — hook name keys, callback count values — sorted alphabetically. Pipe it into a table, JSON export, or admin page as needed.

List callbacks attached to a specific WordPress hook

When debugging a specific issue, you usually want callbacks for ONE hook — not the full registry. This helper returns priority + callback name + accepted-args count for every callback hooked into a given action/filter:

// Inspect all callbacks attached to a specific hook.
// Use this when you need to find what's hooked into a given action/filter,
// debug why a callback isn't firing, or audit a plugin's behavior.

function raj_get_hook_callbacks( $hook_name ) {
    global $wp_filter;

    if ( ! isset( $wp_filter[ $hook_name ] ) ) {
        return array();
    }

    $output = array();
    foreach ( $wp_filter[ $hook_name ]->callbacks as $priority => $callbacks ) {
        foreach ( $callbacks as $callback ) {
            $callback_name = '';
            $function      = $callback['function'];

            if ( is_string( $function ) ) {
                $callback_name = $function; // plain function name
            } elseif ( is_array( $function ) ) {
                $class  = is_object( $function[0] ) ? get_class( $function[0] ) : $function[0];
                $method = $function[1];
                $callback_name = $class . '::' . $method;
            } elseif ( $function instanceof Closure ) {
                $callback_name = 'Closure (anonymous function)';
            }

            $output[] = array(
                'priority'      => $priority,
                'callback'      => $callback_name,
                'accepted_args' => $callback['accepted_args'],
            );
        }
    }
    return $output;
}

// Usage example:
// print_r( raj_get_hook_callbacks( 'init' ) );

Closures are hard to identify: When a plugin hooks a callback via add_action( 'init', function() { ... } ), the callback is an anonymous Closure that PHP’s reflection can’t name. Other plugins hook closures stored in variables. For deeper inspection, use (new ReflectionFunction( $closure ))->getFileName() + getStartLine() to find where the closure was defined — useful for tracking down which plugin registered it.

Distinguishing actions from filters in WordPress hooks

WordPress core does not distinguish between actions and filters at the registry level. Both live in $wp_filter; both can be inspected the same way. The distinction matters only at call sites and in callback signatures:

// WordPress core has helpers for inspecting hooks, but they don't
// distinguish actions from filters. To enforce the distinction,
// you'd have to inspect every callback site in code, which isn't
// practical at runtime. In practice, the docblock or naming convention
// of the hook signals its type:

// Conventions (not enforced by WordPress):
//   actions  — names typically: 'wp_loaded', 'init', 'admin_menu'
//              callbacks usually don't return anything
//   filters  — names typically end in modifier verbs: 'the_content',
//              'wp_title', 'get_post_metadata'
//              callbacks MUST return the (possibly modified) value

// Built-in helpers:
has_action( 'init', 'my_callback' );      // Returns priority or false
has_filter( 'the_content', 'my_callback' ); // Same behavior

// Check whether ANY callback is hooked (priority returned), or false:
$priority = has_action( 'init' );
if ( false !== $priority ) {
    // at least one callback is hooked into 'init'
}

List WordPress hooks via a custom admin page

For ongoing developer work — not just one-off debugging — a custom admin page that lists every hook with a search filter beats dumping to the debug log. Register a Tools sub-page that displays the registry:

// Build a custom admin page that lists every registered hook.
// Useful for debugging custom plugins or generating documentation.

add_action( 'admin_menu', 'raj_register_hook_list_page' );

function raj_register_hook_list_page() {
    add_management_page(
        'Hook List',
        'Hook List',
        'manage_options',
        'raj-hook-list',
        'raj_render_hook_list_page'
    );
}

function raj_render_hook_list_page() {
    global $wp_filter;

    echo '<div class="wrap">';
    echo '<h1>WordPress hook list</h1>';
    echo '<p>Total registered: ' . count( $wp_filter ) . ' hooks</p>';

    $search = isset( $_GET['s'] ) ? sanitize_text_field( wp_unslash( $_GET['s'] ) ) : '';

    echo '<form method="get">';
    echo '<input type="hidden" name="page" value="raj-hook-list" />';
    echo '<input type="search" name="s" value="' . esc_attr( $search ) . '" placeholder="Filter hooks by name..." />';
    echo '<button class="button">Filter</button>';
    echo '</form>';

    echo '<table class="widefat striped"><thead><tr>';
    echo '<th>Hook name</th><th>Priorities</th><th>Total callbacks</th>';
    echo '</tr></thead><tbody>';

    ksort( $wp_filter );
    foreach ( $wp_filter as $name => $wp_hook ) {
        if ( $search && false === stripos( $name, $search ) ) {
            continue;
        }
        $priorities = count( $wp_hook->callbacks );
        $callbacks  = 0;
        foreach ( $wp_hook->callbacks as $priority => $cbs ) {
            $callbacks += count( $cbs );
        }
        printf(
            '<tr><td><code>%s</code></td><td>%d</td><td>%d</td></tr>',
            esc_html( $name ), $priorities, $callbacks
        );
    }

    echo '</tbody></table></div>';
}

After registering, visit Tools → Hook List. The page shows every registered hook with its priority count and total callback count, plus a search filter that narrows the list by name pattern (e.g., type “woocommerce_” to see only WC hooks). Drop this in a dev-only plugin since the page reveals internal hook structure that’s not useful in production.

List WordPress hooks using WP-CLI

WP-CLI is ideal for scripted hook queries — running them from CI, cron, or one-off terminal sessions without touching code. The wp eval command runs arbitrary PHP against a fully-loaded WordPress, giving direct access to $wp_filter:

# WP-CLI ships with hook inspection commands — fastest way to list
# hooks without touching code or admin pages.

# List ALL registered hooks at runtime
wp eval 'global $wp_filter; foreach ( $wp_filter as $name => $hook ) { echo $name . "\n"; }'

# Count hooks by name pattern
wp eval 'global $wp_filter; echo count( array_filter( array_keys( $wp_filter ), function ( $n ) { return strpos( $n, "woocommerce_" ) === 0; } ) );'

# Show callbacks for a specific hook
wp eval 'global $wp_filter; print_r( $wp_filter["init"]->callbacks );'

# List hooks fired during a request (requires Query Monitor plugin OR
# add the WP_DEBUG_LOG flag and read debug.log after a page load)

WP-CLI requires "wp eval" for hook listing: There’s no built-in wp hooks list command in WP-CLI core. The Debug Bar CLI and a few third-party WP-CLI extensions add it, but for the basic use case, wp eval with a one-liner against $wp_filter works without extra packages.

Capture WordPress hooks as they fire (the "all" meta-hook)

WordPress has a special meta-hook named all that fires for every hook on every request — actions and filters alike. Hooking into all gives you the actual firing ORDER during a specific page load, which $wp_filter alone cannot show. $wp_filter tells you what’s registered; the all hook tells you what actually fires.

// WordPress has a special "meta-hook" called 'all' that fires for EVERY
// hook on the page — actions and filters alike. Hooking into 'all' lets
// you capture the actual firing ORDER on a specific request, which
// $wp_filter alone cannot show (it only reveals what's registered).

add_action( 'all', 'raj_log_fired_hooks' );

function raj_log_fired_hooks( $tag ) {
    static $seen = array();

    // Admin-only guard so this never runs for site visitors.
    if ( ! is_user_logged_in() || ! current_user_can( 'manage_options' ) ) {
        return;
    }
    // Only fire when explicitly requested via URL param.
    if ( ! isset( $_GET['raj_trace_hooks'] ) ) {
        return;
    }
    // De-duplicate — many hooks fire dozens of times per request.
    if ( in_array( $tag, $seen, true ) ) {
        return;
    }
    $seen[] = $tag;

    // Choose ONE: dump inline or log to file.
    error_log( '[hook fired] ' . $tag );
    // echo '<pre>' . esc_html( $tag ) . '</pre>'; // inline alternative
}

// Trigger by visiting any page with ?raj_trace_hooks=1 while logged in
// as admin. Check wp-content/debug.log for the firing order.

Visit any page with ?raj_trace_hooks=1 while logged in as admin. The complete sequence of hooks fired during that page load lands in wp-content/debug.log (requires WP_DEBUG_LOG enabled in wp-config.php). De-duplicating via the static $seen array prevents the log from filling with duplicate entries when hooks fire repeatedly inside loops.

Performance impact: The “all” hook is the heaviest WordPress callback you can register — it runs for every single hook fire, of which there are typically thousands per request. Acceptable for development debugging; never leave it active in production. Always gate with admin capability checks and a URL parameter so it can’t accidentally run for site visitors.

Find hooks emitted by source code (static analysis)

$wp_filter shows hooks that have callbacks registered. To find every hook a plugin or theme EMITS — every do_action() and apply_filters() call site — you need source-level grep. This is the right approach for: (a) listing hooks your own plugin emits, for documentation; (b) auditing what hooks a third-party plugin makes available for extension; (c) discovering undocumented hooks that authors never published.

# Static analysis — grep the source code for do_action() and apply_filters()
# calls to find every hook a plugin or theme EMITS (not just hooks it
# registers callbacks for).

# Find all custom hooks emitted by a plugin
grep -rn "do_action\|apply_filters" wp-content/plugins/your-plugin/ --include="*.php"

# More targeted — extract just the hook names (works for simple cases)
grep -rhoE "do_action\(\s*['\"][^'\"]+" wp-content/plugins/your-plugin/ \
    | sed -E "s/do_action\(\s*['\"]//" | sort -u

# Same for filters
grep -rhoE "apply_filters\(\s*['\"][^'\"]+" wp-content/plugins/your-plugin/ \
    | sed -E "s/apply_filters\(\s*['\"]//" | sort -u

# Count unique hooks emitted by a plugin
grep -rohE "(do_action|apply_filters)\(\s*['\"][^'\"]+" wp-content/plugins/your-plugin/ \
    | sed -E "s/.*\(\s*['\"]//" | sort -u | wc -l

For complex cases — hooks with variable names, dynamic hook names like do_action( "woocommerce_email_subject_{$email->id}" ) — grep misses some patterns. PHP AST tools (php-parser, PHPStan static analysis rules) handle these correctly but require more setup. For 95% of plugins, grep finds the vast majority of hooks emitted.

List WooCommerce hooks specifically

WooCommerce uses a consistent woocommerce_ prefix on all its hooks, making them trivial to isolate from the broader WordPress registry. The pattern is identical to listing all hooks, with a string-prefix filter applied:

// Filter the WordPress hook list to just WooCommerce hooks.
// WooCommerce hooks all start with 'woocommerce_' by convention,
// making them easy to isolate from $wp_filter.

function raj_list_woocommerce_hooks() {
    global $wp_filter;

    $woo_hooks = array();
    foreach ( $wp_filter as $name => $wp_hook ) {
        if ( strpos( $name, 'woocommerce_' ) === 0 ) {
            $callback_count = 0;
            foreach ( $wp_hook->callbacks as $priority => $callbacks ) {
                $callback_count += count( $callbacks );
            }
            $woo_hooks[ $name ] = $callback_count;
        }
    }

    ksort( $woo_hooks );
    return $woo_hooks;
}

// Usage: print_r( raj_list_woocommerce_hooks() );
//
// Output sample:
// array(
//   'woocommerce_add_to_cart' => 5,
//   'woocommerce_after_checkout_validation' => 3,
//   'woocommerce_email_classes' => 12,
//   'woocommerce_order_status_changed' => 8,
//   ...
// )

WooCommerce also maintains an official hook reference at woocommerce.github.io/code-reference/hooks/hooks.html — useful when you need a hook’s parameters and emit location documented, not just its name. Combine both: $wp_filter tells you what’s hooked at runtime; the reference tells you what each hook means.

Query Monitor — list WordPress hooks fired during a request

The two approaches above ($wp_filter + static grep) show REGISTERED and EMITTED hooks. Neither shows the firing ORDER during a specific request. For that, install Query Monitor (free plugin).

• What it shows — every hook fired on the current request, in order, with callbacks attached
• Filtering — by hook name, callback class, accepted args
• Performance data — time spent in each hook, useful for finding slow callbacks
• Component attribution — Query Monitor associates each callback with its plugin/theme so you can see “this slow callback came from Plugin X”
• Admin bar integration — accessible via the WP admin bar at the top of every page

Query Monitor is the right tool for performance investigation. When a specific page is slow, Query Monitor’s Hooks tab points directly at the heavy callbacks. For debugging “why didn’t my callback fire?” Query Monitor also shows when actions fire (or don’t fire) on the current page — sometimes the answer is just that the action isn’t fired at all on this page type.

Auto-generate hook documentation from $wp_filter

For plugins you maintain, auto-generating a Markdown hook reference saves the work of keeping docs in sync with code. The pattern: dump $wp_filter to a structured markdown file, commit it to your plugin repo, regenerate when hooks change.

// Auto-generate markdown documentation listing every hook registered
// during a page load. Useful when documenting your own plugin or
// auditing what a third-party plugin uses.

function raj_generate_hook_docs() {
    global $wp_filter;

    $output = "# Hook reference\n\n";
    $output .= "Generated at: " . current_time( 'mysql' ) . "\n";
    $output .= "Total hooks: " . count( $wp_filter ) . "\n\n";

    ksort( $wp_filter );

    foreach ( $wp_filter as $name => $wp_hook ) {
        $output .= "## `{$name}`\n\n";

        foreach ( $wp_hook->callbacks as $priority => $callbacks ) {
            $output .= "**Priority {$priority}:**\n\n";
            foreach ( $callbacks as $cb ) {
                $function = $cb['function'];
                if ( is_string( $function ) ) {
                    $name = $function;
                } elseif ( is_array( $function ) ) {
                    $class = is_object( $function[0] ) ? get_class( $function[0] ) : $function[0];
                    $name  = "{$class}::{$function[1]}";
                } else {
                    $name = 'Closure';
                }
                $output .= "- `{$name}` (accepts {$cb['accepted_args']} arg(s))\n";
            }
            $output .= "\n";
        }
    }

    file_put_contents( WP_CONTENT_DIR . '/hook-reference.md', $output );
    return WP_CONTENT_DIR . '/hook-reference.md';
}

// Run from a WP-CLI command or admin action:
// wp eval 'echo raj_generate_hook_docs();'

This works best for runtime documentation — hooks WITH callbacks attached at the point of generation. For complete hook documentation (every hook your plugin emits, even ones nobody hooks into yet), combine with the static-analysis grep approach to find every do_action() and apply_filters() call.

Tools comparison: which to use when

Quick decision matrix for picking the right hook-listing tool:

Common mistakes when listing WordPress hooks

Patterns that look correct but cause confusion:

• Listing hooks too early — calling your hook-list function in a plugin’s root file misses hooks registered later in init or plugins_loaded. Run hook-listing at wp_loaded or later for completeness
• Assuming actions and filters are stored separately — they’re both in $wp_filter. Use the callback signature pattern, not the registry, to distinguish behaviorally
• Forgetting that $wp_filter only shows REGISTERED hooks — a hook that’s emitted via do_action() but has no callbacks won’t appear. To find emitted-but-unused hooks, use static grep
• Calling print_r( $wp_filter ) directly — produces megabytes of unreadable output. Always extract just what you need (callback counts, specific hooks)
• Dumping hooks on the front-end in production — leaks internal plugin structure. Always wrap in current_user_can( 'manage_options' ) + explicit URL flag
• Missing dynamic hook names — hooks like woocommerce_email_subject_{$email->id} appear in the registry only when the specific email is being processed. Static grep is needed to enumerate all possible variants

Basics — FAQs

How do I list all WordPress hooks?

Read the global $wp_filter array. Each key is a hook name (action or filter) and each value is a WP_Hook object containing all registered callbacks. The simplest way: global $wp_filter; print_r( array_keys( $wp_filter ) ); dumps every registered hook name. For structured output with callback counts, see the helper function in this guide.

What's the difference between actions and filters in the WordPress hook list?

WordPress core doesn’t distinguish them at the registry level — both live in $wp_filter together. The difference is purely behavioral at the call site: do_action() doesn’t collect return values from callbacks; apply_filters() does. Hook names by convention signal type — verbs like “the_content” or “wp_title” are usually filters; events like “init” or “admin_menu” are usually actions. The handbook is the canonical reference for which is which.

How do I find all callbacks attached to a specific WordPress hook?

Access $wp_filter['hook_name']->callbacks — it’s an associative array keyed by priority, then arrays of callbacks at each priority. Each callback entry has function (callable: string, array of [class, method], or Closure) and accepted_args (integer). See the raj_get_hook_callbacks() helper in this guide for a complete parser.

Tools — FAQs

How can I list WordPress hooks fired during a specific page load?

Install Query Monitor (free plugin). It tracks every hook fired during the current request, in order, with callbacks attached, plus timing data for performance investigation. Access it via the admin bar at the top of any page. Query Monitor adds overhead and shouldn’t run on production sites; install it on staging or dev environments for debugging.

How do I list WooCommerce hooks specifically?

Filter $wp_filter by hook names starting with woocommerce_. WooCommerce uses a consistent prefix on all its hooks, so a simple strpos( $name, 'woocommerce_' ) === 0 check isolates them. WooCommerce also maintains an official hook reference at woocommerce.github.io/code-reference/hooks/hooks.html with documented parameters.

Can WP-CLI list WordPress hooks?

Yes, via wp eval with a one-liner against $wp_filter. For example: wp eval 'global $wp_filter; foreach ( $wp_filter as $name => $hook ) { echo $name . "\n"; }' lists every registered hook. There’s no built-in wp hooks list command; third-party WP-CLI packages add one but the eval approach works without extras.

Practical — FAQs

Why is my hook callback not firing — how do I debug?

Three diagnostic steps. (1) Check that the hook is actually fired on the page in question — use Query Monitor or add an error_log() to the action callback. (2) Check whether your callback is registered at the right priority — list callbacks for that hook with the helper in this guide; verify yours appears. (3) Check whether another plugin removed your callback via remove_action() — search for that pattern in other plugins. Most “callback not firing” issues are one of these three.

How do I generate auto-updating documentation for my plugin's hooks?

Two-step approach. (1) Use static grep (or php-parser for accuracy) to find every do_action() and apply_filters() call site in your plugin source. (2) Use $wp_filter at runtime to see what callbacks the WordPress community has hooked into your plugin’s hooks. Combine the two outputs into a markdown reference, commit it to your repo, and regenerate on each release. The raj_generate_hook_docs() helper in this guide handles the runtime side.

Should I list WordPress hooks on the front-end of my site?

No — never in production. $wp_filter reveals every plugin’s internal hook structure, which can leak plugin presence and version info that aids attackers. Always wrap hook-listing code in is_user_logged_in() + current_user_can( 'manage_options' ) + an explicit URL flag, and remove the code entirely from production builds when possible.