Add Customizer context #399
Autocomplete fields in the Customizer are not likely to be visible when `fm.autocomplete.enable_autocomplete()` first fires. Rather than adding another FM-specific event, this triggers `enable_autocomplete()` whenever an uninitialized autocomplete input is focused. Bonus: This affects autocomplete fields in widgets and menu items, too.
These handlers allow contexts (immediately, the Customizer context) or third-party extensions to reinitialize these features after events not relevant to fieldmanager.js.
This helps ensure the UI Datepicker script loads when adding a Datepicker field to the Customizer.
This removes the two event handlers that existed only to enable sortable fields and label macros. Instead, we trigger one event when a Customizer section containing a Fieldmanager control expands, and have those features listen for it. This is a little more consistent with other FM features that listen for FM-related events.
The last round of changes to this PR should have fixed
I've answered this question for now as "yes" and added a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0795c83 updates the behavior in
At the moment, there doesn't seem to be a standard way to alert users to errors while saving changes in the Customizer.
There also doesn't seem to be a great a way to send a message when an error occurs while previewing a setting change. Failing validation will still stop the preview from using invalid values, but it does so silently. Suggestions welcome here, too.
This helps ensure we bind 'fm_customizer_control_section_expanded' to sections that are dynamically added. This also changes the previous behavior of binding to only sections with Fieldmanager controls: If an FM control is dynamically added to a section that had no FM controls, we need to trigger the event when that section expands. Binding to when controls are added, rather than sections, isn't enough because controls can be added without being assigned to sections. Eventually, it might be more efficient to try binding to a section only when a Fieldmanager control is added to it.
Instead, reserialize only those controls containing the changed element.
Adds a check for the `'customize_validation_'` filter in `Fieldmanager_Customize_Setting::_preview_filter()` to avoid an infinite loop, much like the check for the `'customize_sanitize_'` filter.
When the context can use the Customizer's validation framework, and when the default callbacks are added to FM Customizer settings, any invalid submissions will have already been rejected before sanitizing occurs. But, we still need to check for invalid values in the sanitizing callback just in case, for example, the method is called on its own or the validation callback is not hooked to the Customizer setting. If a field value is invalid, we need to reject the update with a Customizer-approved `WP_Error` or `null` before Fieldmanager's native validation routines (such as throwing an Exception or calling `wp_die()`) kick in.
Adds a data provider, `data_field_debug()`, for testing the same method while `Fieldmanager_Field::debug` is `true` or `false`, because the `$debug` property affects Fieldmanager's response to invalid values. These tests currently fail when `$debug` is false.
…ripts()` priority This method was previously hooked to an earlier priority than when it was actually called, which is invalid under `WP_Hook`. See https://core.trac.wordpress.org/ticket/38011.
The proposed Customize context is now available as a standalone plugin that you can use alongside a stable version of Fieldmanager: Check out Fieldmanager Beta: Customize (props @jameswburke for reviewing the initial pull request).
Screenshots, installation instructions, details about how the plugin integrates with Fieldmanager, and steps to activate a demo are all available in the README.
If you're interested in using the Customize context, please try the plugin. Feedback, bug reports, and pull requests are all welcome at the repo.
Plugin development will continue much like a feature plugin in WordPress core. Improvements to the plugin based on testing will, hopefully, strengthen this pull request in turn.