[wp-trac] [WordPress Trac] #40451: Customizer: Introduce plugin management

[WordPress Trac]

#40451: Customizer: Introduce plugin management
-------------------------------------------------+-------------------------
 Reporter:  lukecavanagh                         |       Owner:
     Type:  feature request                      |      Status:  new
 Priority:  low                                  |   Milestone:  Future
Component:  Customize                            |  Release
 Severity:  normal                               |     Version:  4.7.3
 Keywords:  needs-patch ux-feedback dev-         |  Resolution:
  feedback                                       |     Focuses:  ui
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * priority:  normal => low


Comment:

 I think that previewing plugin activation would be cool, but I am
 uncertain as to the level of user desire for this or how much it would be
 used. Since plugins are normally adding functionality, there would
 inherently be less that could clearly be previewed in comparison to
 previewing the activation of a theme.

 Each time that a plugin activation is toggled on, it would need to refresh
 the entire customizer (as is done for themes) so that any customizations
 can be done, as a plugin could be doing a lot of script enqueues and style
 enqueues as well as any other number of arbitrary templates getting
 printed to the page, and so on. It would not be reliable to just try to
 look at differences to which panels/sections/controls/settings are
 registered.

 As to how to implement sandboxing, that could be done by adding a
 `option_active_plugins` filter in a `mu-plugin` which looks to see if
 there is a `customize_changeset_uuid` present in the current request, and
 if so, to then load the changeset and inspect early if there are any
 plugins being activated or deactivated and update the `$active_plugins`
 array accordingly. A feature plugin could potentially install such a
 "helper" plugin to `mu-plugins` in a similar way that Query Monitor does
 via symlink for the `db.php` dropin: https://github.com/johnbillion/query-
 monitor/blob/3b6e1ab45569d0e7fcfcbe2ef6e8ad782399dd7d/classes/Activation.php#L40-L42

 This would not work in all environments, so there might have to be a
 manual step to activation of such a feature plugin.

 In the case of a fatal error causing the Customizer to fail to load after
 a refresh with the plugin activation/deactivation previewed, the changeset
 would need to contain with the plugins activated/deactivated an auto-
 incrementing counter (perhaps), and then if there is a fatal error upon
 activation there could be `shutdown_handler` that perhaps has a link back
 to the Customizer with that counter present and then the aforementioned
 `option_active_plugins` could bypass loading the plugins with that counter
 value present. Something like that.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40451#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform