More flexible sidebar and widget management

1 Views

I’d like to have a plugin for a flexible sidebar/widget management. In fact, I want to give a user the possibility to choose which sidebar should be displayed per page/post.

I know there are many sidebar plugins out there. Unfortunately, I haven’t found one which cover all my wishes. So I’d like to code this on my own. Which of the following possibilities do you find is the best and most flexible? Or do you have other approaches?

Read More

Posibilities

  1. Hardcode the register_sidebar calls in a plugin/functions.php and add a metabox for the post_edit.php, post_new.php screens.

    • Not that flexible. If a user has 100 pages and every page should have a different sidebar, the user has to register additional sidebars manually.

  2. Same as Nr.1 but use a generic sidebar template with conditional tags to display the widgets. We could also use the plugin Widget Logic for a more granular filtering in the backend.

    • Good for a programmer or experienced WordPress user, but not for a normal user. The conditional tags must be mapped in a friendly manner. Also is_page(id) could create problems on multilingual sites, where posts of a different language are stored with another id.

  3. A flexible-sidebars Custom Post Type. Every post in this CPT is used in a generic sidebar-template to display the given content. The sidebar is also selected within a custom metabox. The user can add content to the sidebar with the default WYSIWYG editor which is a big plus.

    • Not a „real“ sidebar. Therefore widgets couldn’t longer be added on the widgets-subpage in the admin panel. We have to create an own metabox for widget-assignments.

  4. Modify the widgets-subpage in the admin panel to create/register your own sidebars in WordPress. Also create a generic widget with a default WYSIWYG editor. Content with attachments could easily be added to the widget and draged to the new created sidebar.
    The user could then choose this sidebar with a drop-down field in a custom metabox in the post/page admin screens. To display the sidebar, we need also a generic sidebar-template.

Conclusion

From my point of view, Nr.4 should do the trick. Are there any other possibilities? Or does this already exists in a plugin?

Thanks for your reply

Post Views: 1

Related posts

Leave a Reply

2 comments

  1. There’s a extension called “Widget Logic”. It adds a field to every sidebar widget in admin section where you can add a piece of php code that you can use to archive what you most likely need.

    Its a bit cumbersome but works. For example you mention that for multilanguage site, you can still use “is_page” since you can also pass array for the function, like this: is_page(array(94,71,3)) .. With logic operators (and/or/not/xor) combined with you can archive any combination.

  2. I’ve done some custom stuff that deals with things similar to this. Here are some pointers based on what I’ve learned:

    • First, if your requirements allow WP 5.x, see if you can avoid sidebars entirely and give the user Gutenberg blocks. Most of your coding and management nightmares will go away because that stuff is already written for you by core. They’re not really too hard to write once you’ve done a few.
    • There’s nothing wrong with attaching a metabox to the post types you think your users may want custom sidebars for. You could even let them enter the name of the sidebar they want for that page (or a radio option to select-existing or create-new). Store the results in the _options table (with update_option()) and read it back on page load. I’ve done this and it’s relatively straightforward.
    • The biggest issue you’ll probably run into is complexity to the user. As developers, one-to-many and many-to-many relationships are natural. Many users won’t understand why you need a metabox for this. This is why Gutenberg blocks are so much easier.
    • For something where you’re changing the piping of a WP core function, make sure you’ve got good defaults for everything. Maybe even make a configuration screen where a content admin can select the post types they would want this for (or change the screen options defaults per post type). I’ve done very well with tables on admin screens that show applied posts, with information about them and some simple admin_ajax management options. Most of my users never touch these but they’re invaluable for my own management and debugging.
    • Even with good management tools, this will probably become a management nightmare quickly. If there are 15 pages on your site that have custom sidebars, your Appearance > Widgets page is going to look like an awful mess (plus there’s a fair bit of JS on there so it’ll be laggy).
    • Another reasonable way to deal with this is by using a page template. This only applies to page but the UI’s already there. If there are only a handful of different types of things you want different, consider adding to your theme or child theming with some extra templates. This will save you a lot of code, debugging and maintenance.
    • If it’s got to be complicated because your requirements demand it, consider an approach that is less invasive to the, “WP Way.” There are filters and actions in (for instance) dynamic_sidebar() which you could probably hook into to make existing sidebars act somewhat differently. I would guess rewriting the widget framework with a CPT would make many core devs cringe; nevertheless, if you’ve been working in WP long enough you’ve probably done something like this at some point.
    • I’m not entirely sure (based on what you asked) that what you really want are different sidebars. Take a look at what you can do with different widgets, like contextual awareness. get_option(), get_user_meta() and $_GET[] are available at widget rendering. If it’s i8n, you may be better with location-aware content in a custom widget, then a single, contextually-aware, widget in a single sidebar. I’ve seen this done with shortcodes too but as a developer I’m generally happier with the administration determinism of a widget, if the situation allows. Keep in mind that a widget and a shortcode aren’t really that different with shortcode-widgets and widget-shortcodes.
    • Finally, keep in mind that it’s not terribly difficult to create widgets, or even modify CSS for existing widgets in your style (or custom stylesheet), that don’t appear. Your WP_Term tags show up in the CSS classes (the taxonomy structure can be enabled for any post type fairly easily with existing plugins) so consider a system where every possible widget is in the sidebar as configured, but ones that are not applicable per page load are hidden, possibly based on how the post is tagged. This is slightly less compatible but if you have a modern-browser-only allowance in your requirements, that incompatibility is washed away.

    You asked a thinking question so I gave you a thinking answer. If any of these ideas seem like the direction you want to go, I have a fair amount of code I could draw from for more concrete examples.