Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Add Customizer context #399
This is a work-in-progress PR to add a Customizer context. If you want to take it for a spin, try the standalone plugin: https://github.com/dlh01/fieldmanager-beta-customize/.
What's included so far covers most of Fieldmanager's fields and their features, but questions about the implementation and known bugs are below.
Suggestions and feedback are appreciated!
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.
Moves the initialization logic to a function so it can be called during 'fm_customizer_control_section_expanded'.
The last round of changes to this PR should have fixed
I've answered this question for now as "yes" and added a
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.
This follows other FM error messages, e.g. "You may be able to use your browser's back button" and "Please check your code and try again."
- After dropping a sortable field, pass the available element directly to reserializeControlsContainingElement() - Call reserializeEachControl() after removing fields or values, because they no longer exist and so the control doesn't contain them.
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.
Moves the logic for converting the `jQuery.serialize()`'d string of a field value into the array or string to save.
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.
Adds a handler to the Customizer context that intercepts `wp_die()` and throws it as an exception which the default validation callback can catch.
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.