WordPress.org

Make WordPress Core

Opened 12 months ago

Closed 2 months ago

Last modified 2 months ago

#38652 closed enhancement (fixed)

Introduce singular capabilities for activating and deactivating individual plugins

Reported by: johnbillion Owned by: johnbillion
Milestone: 4.9 Priority: normal
Severity: normal Version:
Component: Role/Capability Keywords: has-patch has-unit-tests granular-capabilities needs-dev-note
Focuses: Cc:

Description (last modified by johnbillion)

As we did in #35614 for taxonomy terms, singular capabilities should be introduced for managing individual plugins.

This would allow fine-grained cap checks such as current_user_can( 'activate_plugin', $plugin_file ).

This ticket covers activating and deactivating plugins.

Attachments (1)

38652.activate-deactivate.diff (10.3 KB) - added by johnbillion 6 months ago.

Download all attachments as: .zip

Change History (12)

#1 @johnbillion
12 months ago

  • Keywords needs-unit-tests added; has-unit-tests removed

This ticket was mentioned in Slack in #core-multisite by johnbillion. View the logs.


10 months ago

#3 @johnbillion
6 months ago

  • Description modified (diff)
  • Keywords has-patch has-unit-tests added; needs-patch needs-unit-tests removed
  • Milestone changed from Future Release to 4.8
  • Owner set to johnbillion
  • Status changed from new to accepted
  • Summary changed from Introduce singular capabilities for managing individual plugins to Introduce singular capabilities for activating and deactivating individual plugins

#4 @johnbillion
6 months ago

I decided to split this up a bit to avoid huge patches. This ticket now only addresses activating and deactivating plugins, and we can open other tickets for plugin editing, deletion, installation, etc, as necessary.

Patch attached.

#5 @johnbillion
6 months ago

38652.activate-deactivate.diff covers the following situations:

  • Activate/Deactivate links on the Plugins listing screen.
  • Actual activation and deactivation cap check, including bulk activation and deactivation.
  • The 'Activate' link shown after a shiny plugin installation.
  • The 'Activate Plugin' link shown after a non-shiny (ie. fallback) plugin update.
  • Plugin error scraping.

It does not cover network activation/deactivation. This can be handled separately.

#6 @johnbillion
6 months ago

For clarity, the newly introduced activate_plugin, deactivate_plugin, and deactivate_plugins meta capabilities all map to the existing activate_plugins primitive capability, so there is of course no change in existing behaviour.

#7 @johnbillion
5 months ago

  • Milestone changed from 4.8 to Future Release

#8 @flixos90
3 months ago

  • Keywords granular-capabilities added

All of these are part of a larger goal.

#9 @johnbillion
3 months ago

  • Keywords changed from has-patch, has-unit-tests, granular-capabilities to has-patch has-unit-tests granular-capabilities
  • Milestone changed from Future Release to 4.9

#10 @johnbillion
2 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 41290:

Plugins: Introduce singular capabilities for activating and deactivating individual plugins.

This introduces the following meta capabilities:

  • activate_plugin
  • deactivate_plugin
  • deactivate_plugins

The singular activate_plugin and deactivate_plugin capabilities are used along with the corresponding plugin name when
determining whether or not a user can activate or deactivate an individual plugin.

The plural deactivate_plugins capability is used in place of the existing activate_plugins capability when determining
whether a user can deactivate plugins.

Each of these new meta capabilities map to the existing activate_plugins primitive capability, which means there is no
change in existing behaviour, but plugins can now filter the capabilities required to activate and deactivate individual
plugins.

Fixes #38652

#11 @johnbillion
2 months ago

  • Keywords needs-dev-note added
Note: See TracTickets for help on using tickets.