Proposal: Hook Permissions Layer

[namith.jawahar]

Proposal: Hook Permissions and Control System in WordPress Core

Summary

This proposal introduces a system to control how plugins and themes use WordPress hooks (add_action / add_filter).

It will:

• Track which hooks are used
• Group them in a clear way
• Let admins allow or block them
• Show changes when plugins are updated

Problem

Right now, WordPress runs all hooks without any control.

This makes it hard to:

• Understand what a plugin is doing
• Stop unwanted behavior
• Detect changes after updates

Proposed Solution

1. Track Hook Usage

• Record all hooks being registered
• Store:

Hook name
Callback
Priority
Source (which plugin or theme added it)

2. Control Execution

• Hooks can still be registered normally
• Before running a hook:

Check if it is allowed
If not allowed, skip it

3. Permissions System

• Store permissions per plugin/theme:

{
  "plugin-x/plugin.php": {
    "init": true,
    "admin_init": false
  }
}

• New or unknown hooks are blocked by default until approved

4. Group Hooks

Show hooks in simple groups:

• Admin (dashboard related)
• Frontend (site output)
• Content (posts, titles, etc.)
• Database (saving/deleting data)
• Users (login, registration)
• System (core lifecycle hooks like init)

5. Scan Plugins/Themes

When a plugin or theme is activated or updated:

• Scan code to find hooks
• Also track hooks at runtime (for dynamic cases)

6. Permissions UI

• Show a popup on activation/update
• List all hooks used
• Group them clearly
• Let users enable/disable with checkboxes
• Show warning: disabling hooks may break functionality

7. Author Notes (permissions.json)

Plugin authors can include a file:

{
  "init": "Used to start the plugin",
  "wp_footer": "Adds script to page"
}
}

• This helps users understand why hooks are needed

8. Detect Changes on Update

When a plugin updates:

• Check for new hooks
• Block new hooks by default
• Show admin notice asking for approval

9. Existing Plugins (Backward Compatibility)

To avoid breaking existing sites:

• All hooks for already-installed plugins/themes are allowed by default
• These plugins will be marked as "Unreviewed"
• Admins can later review and update permissions manually

When a reviewed plugin is updated:

• Any new hooks will be treated as new permissions
• These new hooks will be blocked until approved

[namith.jawahar]

The proposal implemented as an MU Plugin

[namith.jawahar]

Video of how it works ​https://drive.google.com/file/d/1y3G2tPSK0OU9uYFWejvrDg6p9kIaIJH9/view

[aravindajith]

This is an interesting and well thought out proposal. The problem is real, especially for teams using WordPress as an application platform.

That said, the scope feels quite large for core. It combines tracking, scanning, permissions, UI, and update-time checks into a single system.

A few concerns:

• The main value seems to be in controlled environments (SaaS, enterprise). For typical sites, unrestricted hooks are often a feature.
• Blocking new hooks on plugin updates could lead to unexpected breakages that are hard to debug.
• Static scanning may miss dynamic hooks, while runtime tracking adds overhead.
• The UI and concept of “disabling hooks” may be difficult for non-technical users to reason about.

It might be worth exploring a more incremental approach, starting with better visibility into hook usage and lighter, opt-in controls for sensitive hooks.

Overall, this feels like a strong direction, but possibly better introduced in smaller steps.

[namith.jawahar]

I think tracking ownership changes (going by the recent events) and outgoing http calls and making this passive rather than active (no blocking actions, but blocking auto updates if one of the trigger get hit). Giving easier to understand information in the plugin details popup along with visible traffic light like alerts would make it pretty helpful. More like a gatekeeper rather than an active firewall.