[wp-trac] [WordPress Trac] #37661: A New Experience for Discovering, Installing, and Previewing Themes in the Customizer
WordPress Trac
noreply at wordpress.org
Sun Feb 12 00:22:39 UTC 2017
#37661: A New Experience for Discovering, Installing, and Previewing Themes in the
Customizer
-------------------------------------+-------------------------------------
Reporter: celloexpressions | Owner: westonruter
Type: feature request | Status: reopened
Priority: high | Milestone: 4.8
Component: Customize | Version: 4.2
Severity: normal | Resolution:
Keywords: has-patch has- | Focuses: ui, accessibility,
screenshots has-user-testing has- | javascript
ux-feedback commit |
-------------------------------------+-------------------------------------
Changes (by celloexpressions):
* keywords:
has-patch has-screenshots needs-testing has-user-testing has-ux-
feedback commit
=> has-patch has-screenshots has-user-testing has-ux-feedback commit
Comment:
Thanks for doing that research and updating the documentation @folletto.
I agree that we should have much more flexibility than previously believed
in how we use the API (and there will be similar possibilities in pure JS
for installed themes). However, I still think that we need to separate the
the browsing UI improvements from the initial change here.
Let's get what we had back into core and fix the obvious bugs so that we
have the foundation to build off of. Once the technical base is there -
with fully fleshed-out objects for theme panel, sections, and controls in
PHP and JS, and with an initial browsing UI to test against, we'll be able
to prototype alternative approaches and test them much more easily (likely
even with plugins). That base functionality has proven very difficult to
test due to the magnitude of the patch and the technical changes to
support theme installation in the first place.
With that being said, can you start coordinating some new mockups for
alternative UIs, @folletto? And maybe we can bring that to the design team
to discuss, along with how the theme filters/tags could be reworked to
improve the experience?
At the same time, if a committer can take care of the first few steps in
[comment:139], we'll be ready to start building those in a way that's
easily testable so that we can work toward an improved flow. As a
reminder:
> 1. Revert [39153] (so that revert will be clean), then revert [39140],
closing this ticket and #34843 as fixed.
> 2. Reopen #38365 and #38663 and commit the previously-supplied patches
for both.
> 3. Reopen #38626 and work on/commit a patch.
I'm happy to then take care of the patch for 4.:
> 4. Patch and commit #38666.
And we'd already have a start on 5.:
> Open a new ticket to specifically improve the theme browsing experience
in the customizer. The customizer was intended to reuse the admin
experience and have that part be out of scope for this ticket, but ended
up changing and ultimately being the primary reason that this was deemed
unready to ship. With the base functionality and the related pieces in
trunk, and the bugs fixed, this aspect will be much easier to iterate on
and re-polish well within the 4.8 timeline.
Once themes are fully supported by the customize API, we have several
exciting opportunities for rethinking the role of themes in both site
setup and site redesign flows. With a frontend bootstrapping for the
customizer API, we can open the new theme browser directly from the
frontend. On site setup, a walkthrough could start with some site-type
selections that lead to recommending relevant themes, in turn leading to
theme and site customization and content creation. We need to get this
framework for themes into the customize API ASAP so that this missing
functionality can be integrated with these new flows without hitting
technical blocks.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/37661#comment:146>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list