[wp-trac] [WordPress Trac] #40451: Customizer: Introduce plugin management (was: Customizer: Introduce plugin uploading)
WordPress Trac
noreply at wordpress.org
Fri Jul 7 22:56:03 UTC 2017
#40451: Customizer: Introduce plugin management
-------------------------------------------------+-------------------------
Reporter: lukecavanagh | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: Future
Component: Customize | Release
Severity: normal | Version: 4.7.3
Keywords: needs-patch ux-feedback dev- | Resolution:
feedback | Focuses: ui
-------------------------------------------------+-------------------------
Changes (by celloexpressions):
* keywords: => needs-patch ux-feedback dev-feedback
* focuses: => ui
* type: enhancement => feature request
* milestone: Awaiting Review => Future Release
Comment:
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.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/40451#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list