Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to set per widget area defaults #87

Open
dreamwhisper opened this issue Oct 3, 2018 · 3 comments
Open

Add ability to set per widget area defaults #87

dreamwhisper opened this issue Oct 3, 2018 · 3 comments

Comments

@dreamwhisper
Copy link
Contributor

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:

  • maintain a way to specify it site-wide
  • add ability to specify a different default for specific widget areas
@nickcernis
Copy link
Contributor

nickcernis commented Oct 3, 2018

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.

@mindctrl
Copy link

mindctrl commented Oct 4, 2018

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.

@nickcernis
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants