Make WordPress Core

Opened 8 years ago

Last modified 6 years ago

#40451 new feature request

Customizer: Introduce plugin management

Reported by: lukecavanagh's profile lukecavanagh Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.7.3
Component: Customize Keywords: needs-patch ux-feedback dev-feedback
Focuses: ui Cc:

Description

There is currently not a way to discover or upload plugins in the customizer, the only way is in WP Admin.

https://codex.wordpress.org/Managing_Plugins#Automatic_Plugin_Installation
https://codex.wordpress.org/Managing_Plugins#Manual_Plugin_Installation

Themes already have #37661 and #40278.

Change History (10)

#1 @celloexpressions
7 years ago

Themes should be managed within the customizer because they are the most fundamental aspect of a site's appearance. Plugins are much less likely to be so prominently relevant that it makes sense to install them from the customizer. Is the preview useful for installing/managing plugins?

I'd think that this is lowest priority and potentially not something we should consider at all unless we're looking to eliminate a separate administration interface entirely.

#2 @celloexpressions
7 years ago

  • Focuses ui added
  • Keywords needs-patch ux-feedback dev-feedback added
  • Milestone changed from Awaiting Review to Future Release
  • Summary changed from Customizer: Introduce plugin uploading to Customizer: Introduce plugin management
  • Type changed from enhancement to feature request

Broadening the scope here to consider plugin management in addition to uploading, there are some potential benefits. In particular, the ability to live-preview a plugin activation/deactivation could be extremely useful, especially for simple option-less plugins that make changes to the front end.

I did an initial implementation exploration as a plugin here: https://wordpress.org/plugins/customize-plugin-manager/. Unfortunately, while live-previewing plugins is probably relatively easy to implement in core, it doesn't seem possible via a plugin because the plugin code would need to hook into an action that happens before any plugins are loaded. So for now, the plugin gives us an experimental UI and most of the code we'd need. Plugin activation and deactivation does work once you save and published, and nothing is prematurely published to the live site.

While the main plugin activation previewing functionality is relatively straightforward, there are a few bigger-picture items that will need to be worked out:

  • How should plugin-added options in the customize pane be handled? I'm thinking a supplemental Ajax call when an activation/deactivation is triggered that runs the customize_register action, does a diff with the previously-registered objects, and adds/removes items accordingly in JS could be feasible. This could also eventually be used to allow theme switches without a full customizer reload.
  • To what extent should plugin management be handled in the customize context? Beyond managing which plugins are active, are updates useful with a live preview context (considering that the updates wouldn't be previewed)?
  • To what extent should plugin addition and deletion be possible here? We probably shouldn't ship anything before plugin addition is possible, as we've been stuck with a poor new user experience for themes here for a long time (see #37661). Since we don't need the preview aspect when browsing plugins, should that happen in a modal, slide-out panel, or full preview overlay of some sort? We should prioritize a simpler interface that allows the preview to remain beside the controls for the primary activation/deactivation process.
  • Can we sandbox plugins before activating them, like the old plugin manager does?
  • What do we need to do with plugin activation and deactivation hooks for back-compat?
  • What new hooks do we need to provide so that plugins can successfully hook into the customize experience when they're activated without full page loads (for the preview and customization panes)?

Our next steps will be to discuss those questions and come to decisions on UI/UX and dev goals for what should be in core. Then, depending on the agreed-upon scope, we can continue working on pieces in that plugin or directly here. The plugin will be useful for testing things with users, but the limitations on live previewing plugins while the code is in a plugin likely prevent that approach from being great for feedback.

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.


7 years ago

#4 @westonruter
7 years ago

  • Priority changed from normal to low

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.

This ticket was mentioned in Slack in #core by westonruter. View the logs.


7 years ago

#6 @celloexpressions
7 years ago

  • Priority changed from low to normal

I was also initially uncertain about the usefulness of this. However, there are many good plugins that do one thing and do not require configuration beyond being activated - those plugins benefit significantly from live preview. And really, it should be a goal long-term to allow plugins to be fully live-previewed along with any other aspect of managing a site.

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.

For both plugins and themes, the long-term idea is that rather than reloading the customizer entirely, the customize controls pane can be selectively updated via an ajax call that essentially provides a diff between customize objects (and enqueued scripts/styles, by running the customize-specific hooks) that were available before and after the theme switch/plugin activation. Any added objects could be added and any removed ones removed via the JS API, and JS-templated controls particularly lend themselves to this approach (this is also the sort of behavior that #30741 aims to eventually enable). Additional scripts and styles could also be loaded. The preview would be the only thing requiring a refresh. Plugins could potentially also opt-in to additional hooks to facilitate this behavior or prompt the user to do a full reload if absolutely necessary (this would likely be limited to plugins modifying the customizer itself).

The 4.1-era thought was that this functionality was a prerequisite to customize-based theme switching; in 4.2 we implemented an intermediate approach that matinains the full page load for now. Eventually, that should be implemented for both themes and plugins, allowing full live previews without page loads.

#7 @johnjamesjacoby
7 years ago

#42584 was marked as a duplicate.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


6 years ago

#9 @karmatosed
6 years ago

This ticket was looked at during the triage session this week for design. It would be great to know a little more how common the need is for this flow.

#10 @celloexpressions
6 years ago

This project would re-imagine the plugin management experience to parallel the theme management experience in the customizer. Essentially, centering the plugin management experience around live preview.

An approach to "un-block" this project from a potential future customizer iteration that automatically detects registered-control changes would be to add an intermediate loading (re-loading) screen when a plugin is activated. This could match the theme-switch loader in the customizer and would match the behavior of plugins in wp-admin.

Noting again that an initial approach is in this plugin: https://wordpress.org/plugins/customize-plugin-manager/. It would be great to get more people involved in this project if anyone else is interested.

Note: See TracTickets for help on using tickets.