[wp-trac] [WordPress Trac] #65117: Proposal: Hook Permissions Layer

[WordPress Trac]

#65117: Proposal: Hook Permissions Layer
-----------------------------+---------------------------------------
 Reporter:  namith.jawahar   |      Owner:  (none)
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Plugins          |    Version:
 Severity:  normal           |   Keywords:  has-screenshots has-patch
  Focuses:                   |
-----------------------------+---------------------------------------
 = 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

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65117>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform