Feature Request: Custom IDs for widgets

To an extent you can do this.

If I look at the source code for my site, I see this for my search sidebar widget:

<div id="search-3" class="widget search widget-search"><div class="widget-wrap widget-inside"><h3 class="widget-title">Search</h3><div class="search"> [search stuff] </div></form></div></div></div>

So I can use those ids and classes to customize.

Hi @ipstenu,

Thanks for taking the time to respond.

I don’t think I explained myself very well. I know there ARE classes and IDs for all widgets – these differentiate the type of widget. I also know it’s possible to set (for Text Widgets) an inner HTML element with permanent class/ID.

My suggestion is that it’d be really useful to be able to attribute a specific widget (preferably the containing li you haven’t included here) with a specific class or ID that can then be used to manipulate the site.

E.g. a text widget has a containing li like this:

<li id="text-14" class="widgetcontainer widget_text">

But, the ID changes depending on what order it was generated in the WP CMS, and the classes cannot be set either (except if you create your own custom widget).

Say I want to hide that li if I’m on a particular page (e.g. a call to contact if one is looking at the contact page already). Now, if I only have one text widget in that aside, this is easy, I just say body.this-page .widget-text {display:none;} in my CSS.

But, if it’s this specific text widget in a list of several that I want to hide, I must rely on id="text-14" as the only differentiator. Now, if I accidentally delete that widget and have to recreate it, I have to go into the CSS and change #text-14 to whatever the new widget ID is.

If I could add a custom class, or define a custom ID e.g.

<li id="my-custom-ID" class="widgetcontainer widget_text or_my_custom_class">

Then if the original widget dies, I can just define the new widget as being the same as the old one by adding that custom ID or class.

Is that clearer?

Thanks again…

Say I want to hide that li if I’m on a particular page (e.g. a call to contact if one is looking at the contact page already). Now, if I only have one text widget in that aside, this is easy, I just say body.this-page .widget-text {display:none;} in my CSS.

Ah. I would do it differently ?? Enter Widget Logic: https://www.ads-software.com/extend/plugins/widget-logic/

Which is what I use to do EXACTLY that!

Hi @ipstenu,

I use and <3 widget-logic too.

But:

• Sometimes widget logic isn’t as powerful as Thematic for conditional requirements. E.g. if I want to make a page and all its sub-pages show/hide a particular widget, widget logic can’t do that as it only uses WordPress conditionals, for which there is no child/ancestor condition (as far as I can find).
• Showing and hiding isn’t everything one might want to use a DOM identifier for. How about styling text in a particular way? Or setting a widget to have a different coloured title?

I know there are workarounds for all of this, and I’ve tried them all. I still think this would be of value to me, and I suspect to other WP devs too.

Great job on support, thanks ??

divydovy

From the plugin page ??

The text field lets you use WP’s Conditional Tags, or any general PHP code

You can test for subpages by the way: https://codex.www.ads-software.com/Conditional_Tags#Testing_for_sub-Pages

Showing and hiding isn’t everything one might want to use a DOM identifier for. How about styling text in a particular way? Or setting a widget to have a different coloured title?

I’d probably get a PHP widget plugin and put the code check in there for things, but you may be at the point where you need to make your OWN widgets. Justin Tadlock has a good post on that: https://justintadlock.com/archives/2010/11/08/sidebars-in-wordpress

And in a comment says:

Take a look at the WP_Widget_Links class in wp-includes/default-widgets.php. It has an example of how to add in a custom ID, which is basically the same as adding a custom class.

Hi Ipstenu,

Thank you so much. Really appreciate your knowledge and time.

I’m sure I can achieve what I want to with these tools now, thanks.

Happy Christmas and all that,

divydovy

I, like many of us, have been scratching my now bald head trying to find a solution that will allow Widget Logic to play nicely with ANY plug in that adds Custom Class/ID to Widgets. I tried asking Andy (ZigWidgetClass) and got impatient waiting for a response (yes, he answered within a decent amount of time <12 hours, being a coder and impatient anyway I dove in looking to find the problem). He and I both discovered that the issue is caused by the fact that WL needs to rewrite the callback array in order to function in the way that it does and in doing so keeps any other custom widget class plugin from visibly working.
No biggie, just need to test to see if Widget Logic is active then if it is use the callback_wl_redirect instead of callback.
Since Andy’s fix was shorter and cleaner than mine I will show you his solution and all thanks should go to him:
This is from his plugin; ZigWidgetClass
This:
$option_name = get_option($widget['callback'][0]->option_name);

Gets replaced with this:
if (!($widgetlogicfix = $widget['callback'][0]->option_name)) $widgetlogicfix = $widget['callback_wl_redirect'][0]->option_name; # because the Widget Logic plugin changes this array $option_name = get_option($widgetlogicfix);
Notice that depending on which plugin you have chosen to ad custom class/id’s to your widgets the $widget variable could be $widget_obj or something along those lines. You might find it easier to Search the plugin code for ['callback'][0]->option_name) as this should be standard.
ZigWidgetClass has already update the plugin to work with Widget Logic.
KC Widget Enhancements should be next.
If you are using a different plugin than the two mentioned then you should alert them to this.