Open dreamwhisper opened 5 years ago
I spent some time with this and it doesn't seem possible with a pure-PHP/JS method using official WP APIs at the moment. The issue is that:
We need the widget's location when it's initially added to a widget area in order to check what widget-area-specific icon color and size defaults to use. (I envisioned a separate filter for simple_social_widget_area_styles
that would trump simple_social_default_styles
if the widget is added to a widget area that has area-specific defaults.). In the constructor:
/**
* Allow override of the above defaults for specific widget areas.
*
* For example, set the default icon color to red only for widgets
* added to the Footer 1 widget area with this filter:
*
* ```
* <?php
* add_filter( 'simple_social_widget_area_styles', function(){
* return array(
* 'footer-1' => array(
* 'icon_color' => '#ff0000',
* ),
* );
* } );
* ```
*
* @since 2.1.0
*/
$this->widget_area_defaults = apply_filters( 'simple_social_widget_area_styles', array() );
The widget's location isn't stored and available until after it's first saved (I tested the Appearance → Widgets area).
Because the widget effectively has no stored location until it's saved, this code to get the widget location added within the form()
method returns false instead of the widget area the widget currently appears in. (It returns the widget area name once the widget is saved, but that's too late because defaults need to be set and displayed when the widget is first placed):
is_active_widget( false, $this->id, $this->id_base )
I can think of other ways to do this with JS, but they are hacks, rather than methods that use official APIs. We'd also need an alternative JS method for the Customizer.
I'll leave this open for now, though, in case others have new ideas or I think of something else.
I looked into this a bit too, and I agree with your assessment. There are ways to make it happen, but they do feel like hacks.
Under Appearance > Widgets, when you drop a widget into a widget area, an AJAX POST request runs. It contains the new widget's ID and sidebar location. We could tie into that and populate the form dynamically, and as you noted it would require something different in the Customizer.
I love the idea and think setting default values intelligently as @dreamwhisper describes would be a very nice user experience and set us apart from others in this area. I think it's worth exploring deeper as time allows.
Thanks for taking the time to look into this too @mindctrl, and for your notes. Leaving as needs-research for now in the hope we can revisit at some stage.
We previously added the ability to set defaults for widget settings so themes could specify the expected settings rather than add custom CSS.
However, different widget areas may need different defaults depending on background color, space, etc.
This issue is to investigate the feasibility of adding defaults for different widget areas.
Preferably: