Refresh Customizer implementation with WP 4.4 + 4.5 changes
sc0ttkclark opened this issue · 6 comments
- WP_Customize_Manager
- WP_Customize_Control
- WP_Customize_Setting
- WP_Customize_Section
- WP_Customize_Panel
- Additional classes related to the above
- phpunit passes against core tests
Closing this right now as maybe later, not going to focus on the Customizer implementation for the initial proposal, given how complicated it can make this and how much extra testing/review it will require.
I don't know if the fields API would be accepted into core without at least a solid exploration of how it relates to the customizer. @helenhousandi?
The Fields API is currently a fork of the Customizer API codebase. It generalizes markup, adds support for multiple object types / names, and makes it pretty easy for people who have developed with the Customizer to develop for the Fields API. There are things that still belong directly in the Customizer API, but also a main concern is backwards compatibility.
I was able to get the WP Core unit tests passing for our Customizer implementation which bases it on the Fields API for the main abstracted areas, while keeping other areas inside of the Customizer. But there's still the potential for things that aren't covered in the tests to not be working quite right.
We solicited feedback from @celloexpressions and he also chimed in as against implementing this into the Customizer at first:
my vote would be NOT to make any changes to the Customizer API, at least for now. Let the fields API be inspired by it, but start fresh and evolve as needed for other uses. If we want to adjust the Customizer API to extend the Fields API at some point, we could revisit that, but based on the fields API spec I saw, it seemed like it would be better to keep them separate for now as there are some key foundational differences.
I'm not entirely sure there are major foundational differences besides the fact that the Fields API is meant to extend all the way across WordPress as a whole, while the Customizer is just one feature set, one specific set of data structures.
@nacin I think a pretty solid exploration has already been done and is not worth continuing to pursue as initial usage/implementation case.
And to clarify my comment, the big difference I saw was in the distinction between setting and control objects that seemed de-emphasized in the fields API relative to the customizer API, although that may have changed since I last looked at it.
The Fields API as it currently stands, contains the same Control / Setting (field) structure as the Customizer, with the added convenience of being able to create/assign the control when creating a field. It adds a 'control' key to settings arguments, which will auto-create and assign the control arguments passed in there, which in turn reduces overall arguments needed to create a control, while maintaining the implicit structure definitions that keep Controls and Settings separate.