WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#41239 closed feature request (maybelater)

Add filter in dynamic_sidebar() to allow changing the index before rendering

Reported by: jantank Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9
Component: Widgets Keywords:
Focuses: Cc:

Description

Hi

I'm currently working on a plugin to build Microsites in a WordPress site. This allows to apply a different look and feel on a per page basis instead of having to create a new site in a Multisite setup or using CSS to overwrite values. For this the Customizer is utilized. In there for every Microsite the whole options for the normal theme setup is cloned. Menus, Widgets and all of the Settings.
This works in 4.7 and with themes, that only use the Customizer, pretty well except for widgets. In the function dynamic_sidebar() in widgets.php there is no filter, that allows the change of a dynamic registered widget, as the index can not be changed before render.

A demo of this plugin can be loaded at: http://plugins.th1nktank.net/microsites.zip

Microsites can be added under Options -> General (you have to currently hit "Save Changes" after adding a Microsite)
Then go into the customizer and change Menus, Widgets and Options for your Microsite (after applying this patch)
After doing that, go into the options of a page a select a Microsite for that page.

This is currently work in progress and a more polished version will follow.

Some sample pages:
http://plugins.th1nktank.net/
http://plugins.th1nktank.net/about/
http://plugins.th1nktank.net/contact/

Attachments (1)

41239.diff (444 bytes) - added by jantank 4 years ago.
Add filter in function dynamic_sidebar()

Download all attachments as: .zip

Change History (9)

@jantank
4 years ago

Add filter in function dynamic_sidebar()

#1 @westonruter
4 years ago

  • Keywords reporter-feedback added

@jantank there is the sidebars_widgets filter which can be used, right? If not, then if you want to change the argument passed into dynamic_sidebar() then I suggest your theme add a custom filter there which you can then leverage to modify the $index that is passed in from the template.

#2 @jantank
4 years ago

@westonruter it is true, that there is that 'sidebars_filter'. But it is not about registering widgets, it is about replacing widget 'footer' with 'microsite_footer' at render time. So that instead of the normal widget the microsite widget is rendered.
As Twenty Seventeen is using 'dynamic_sidebar' to render the widgets, I do not see another way. Maybe I'm wrong, as the Microsite Plugin is my first work with WordPress Hooks and Filters, but so far I haven't found a different way.

Also I wrote a Plugin and not a Theme, so that option does not exist. The Plugin is aimed at working with every template, that uses the WordPress Customizer in a normal way. That is a bit rough right now, but I just started developing it as a prove of concept and stumbled about this blocker. Everything else has already filters to replace Theme Options, Menus, Blog Info and what not. Just Widgets currently do not work. At least, with what I tried.

#3 @westonruter
4 years ago

@jantank my thoughts on how to implement this with the sidebars_widgets filter would be to use it to swap out the widgets used for a given sidebar at runtime. This may actually not work with how widgets are managed in the Customizer, but the idea is that you could have something like this:

<?php
add_filter( 'sidebars_widgets', function( $sidebars_widgets ) {
    if ( myplugin_is_microsite1() ) {
        $sidebars_widgets['footer'] = $sidebars_widgets['microsite1_footer'];
    }
    return $sidebars_widgets;
} );

And then in your template you still have just dynamic_sidebar( 'footer' ) but then depending on which URL you are currently on you see different widgets in the footer sidebar.

Again, this probably won't work at the moment in the Customizer because the microsite1_footer sidebar would never be directly used and thus its customizer section would never appear, but that would change with #40432 when inactive sidebar sections are displayed.

#4 @jantank
4 years ago

@westonruter I read about #40432 and had the same feeling with my Plugin, that the UX experience is not great currently. With that change it might get better. And also it might fix my problem.

Thing is, that thread is only talking about what changes could/should be made. Is there a plan to fix it in the next release? I guess, that there is more work involved than just a one line fix!?

I just tested your proposed solution in the last comment. Had to change it a bit, but now it works. Thanks!

I guess, that I was so fixed on changing the index, that changing the whole sidebar_widgets array didn't came to my mind. Now I just need to make my code efficient, as "wp_get_sidebars_widgets" is called more often than "dynamic_sidebar". But from the look of it, that might get tricky as other Plugins/Themes could also try to alter that list. Changing just the index seems to be less overhead.

Still I think, that it might be a good idea to add that filter or are there other reasons not to do so?

#5 @westonruter
4 years ago

  • Keywords close added

@jantank I think #40432 could indeed come soon. Perhaps 4.8.2.

As for whether or not to add an additional filter, I think the rule of thumb is to be conservative and only add filters when they are absolutely needed. Since it seems we can leverage the sidebars_widgets filter to have the same result, then I'm thinking it's not ultimately required.

#6 @jantank
4 years ago

  • Resolution set to invalid
  • Status changed from new to closed

@westonruter "only add filters when they are absolutely needed" seems to be contradictory to the idea of hooks and filters. I thought, one would want as many as possible (reasonable) to allow for flexibility.

I get, that this can be solved different and therefor a filter is not required, still I think, that WordPress would benefit from some more filters. Eventually I will send in another one around theme mods.

But I accept, that my case is solved and the ticket can be closed.

#7 @westonruter
4 years ago

  • Resolution changed from invalid to maybelater

@jantank the more hooks we add the more we have to maintain and add backwards-compatibility for as things change.

I'll change the resolution to maybelater so that if more use cases arise this can be reconsidered.

#8 @westonruter
4 years ago

  • Keywords reporter-feedback close removed
  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.