[wp-trac] [WordPress Trac] #42049: Customize Themes: extensibility improvements

[WordPress Trac]

#42049: Customize Themes: extensibility improvements
------------------------------+-------------------------------
 Reporter:  celloexpressions  |       Owner:  celloexpressions
     Type:  task (blessed)    |      Status:  reviewing
 Priority:  normal            |   Milestone:  4.9
Component:  Customize         |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------
Changes (by celloexpressions):

 * keywords:  has-patch needs-refresh => has-patch
 * type:  enhancement => task (blessed)
 * milestone:  Future Release => 4.9


Comment:

 Replying to [comment:3 westonruter]:
 > In extensibility, I don't think we should just yet add a bunch to extend
 when we haven't yet solidified the foundation. I'd rather make sure we
 have the core themes experience in place, and then in a subsequent release
 add extensibility. That way we'd be able to ensure that extensions are
 building off of a solid base. We can add the extensibility in 4.9.x even,
 as part of a v3 of the themes experience.

 You're misinterpreting the point of this ticket, and the way extensibility
 is intended to work in conjunction with future improvements to the feature
 in terms of UI.

 This has nothing to do with the "first pass" UI for browsing themes from
 WordPress.org. In fact, on #37661, we discussed the possibility of third-
 party implementations in the customizer inspiring future improvements to
 the WordPress.org side of things. However, in terms of UI, the foundation
 for extensibility is already in place and unlikely to change based on
 changes to WordPress.org theme browsing in the customizer.

 The installed themes experience is similarly unlikely to change, and this
 is where the majority of the improvements here are made. In addition to
 third-party theme sources, the improvements here make it much more
 feasible to effectively use this feature on large multisite networks, and
 extend the installed themes section as required. For example, large
 networks like WordPress.com can largely make use of the default installed
 themes experience, but may want to add filtering or other features - in
 order to do that without duplicating core logic (and breaking things if we
 change later), we shouldn't be hardcoding checks for the `installed`
 section action and rather introduce a parameter for local remote
 filtering. The changes here are as much for improved future compatibility
 as they are for ease of use in the API, which is how we can set ourselves
 up with the ability to make changes to the overall experience in the
 future without breaking things, if we ever decide to do that.

 Regardless of when we want to encourage third-party implementations, there
 are a number of improvements in [attachment:42049.2.diff] (a refresh) that
 should be made to improve the initial experience and UI (such as the
 searching changes, included here to avoid conflicting patches). And if we
 don't want people to extend the experience, we should explicitly mark
 certain elements as `private` (in a distinct ticket) rather than leaving
 an annoying-but-functionally-extensible API for public use. Punting is not
 the right approach here due to the nature of these changes.

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