Unable to hide the No [taxonomy name] option

Hi, I retested the following this morning and it appeared to still be working for me:

add_filter( 'radio_buttons_for_taxonomies_no_term_post_tag', '__return_false' );

Does your taxononomy have a _default_ term? (see the params of register_taxonomy) Pretty sure my plugin cannot get rid of that… for example the “uncategorized” term in post categories.

That code didn’t work for me either.

I don’t know where to set up a default option. The unwanted No {taxonomy name} option is selected as the default. If I knew how to do it, I would make my own “No” option the default for this taxonomy. This taxonomy is created using the Toolset plugin.

Note that I *could* just delete my own “No” option and use your “No {taxonomy name} option to indicate a negative selection. Our query filter for the Toolset View we’re using this on is running on a positive Yes selection, so it really doesn’t matter what the other field is called. I just would prefer to have “Yes” and “No” as the two options, not “Yes” and “No Add To Ride Maps Page”. I thought the fix for this would be simple and that I was just doing something incorrectly.

Please advise if you have something else to try. But I’m thinking you should make generating this additional option something that can be chosen in settings rather than automatically adding it and forcing a custom code workaround in the functions.php file.

Thanks for the assistance regardless.

• This reply was modified 2 years, 1 month ago by wildlife77.

Default terms are configured in register_taxonomy(). Whether or not that is supported via Types is a question for their support team, but in my cursory test it looks like it is not part of their UI.

I set up a taxonomy using their plugin
https://i.imgur.com/3KFThk0.png

I enabled RB4T for this new taxonomy and added my snippet via the Code Snippets plugin:
https://i.imgur.com/rFXrmLR.png

add_filter( 'radio_buttons_for_taxonomies_no_term_add-to-ride-maps-page', '__return_false' );

“No term” is not present for posts

https://i.imgur.com/1Y4ojnH.png

So I cannot reproduce your error… I would need exact steps from you in order to dig further. It is going to sound pedantic, and I don’t mean it to, but double and triple check your slug matches exactly with the snippet. I get caught all the time by typos, especially with dashes versus underscores.

Also make sure you snippet is enabled everywhere and not limited to frontend/admin.

https://i.imgur.com/1Y4ojnH.png

I will note your feature request, but this plugin is mostly in a permanent holding pattern as it takes a much lower priority compared to paid work. I am happy to review a pull request from anyone who would like to contribute.

• This reply was modified 2 years, 1 month ago by HelgaTheViking.

I’m confused. Where are you seeing that? Is that on your end with testing using my same taxonomy name?

I’ve since disabled this plugin because I found that there was also a problem with setting up a query filter in Toolset based on another taxonomy that I had previously set up to use radio buttons as well. I’d set the query filter to use any Ride that had Yes selected on the radio button for that taxonomy (one called Add To News Ticker), but it wasn’t saving/applying it properly. I disabled the plugin and the query filter worked fine with it as a checkbox field.

I can enable it again to get this extra option field gone and then hopefully figure out the problem with the Toolset query filter with this plugin enabled if you’re willing to look at that. But when I saw that additional problem, I temporarily reached a point of thinking this is more difficult than it is worth. If we have to use checkboxes, that won’t be so bad. But again, I’m OK with debugging what I’m seeing with your assistance if you’d like to do it. I don’t know why what I’m doing isn’t working.

Yes. I downloaded Toolset and set up a test taxonomy that matches what you told me. It appears to function as I expect.

your other issue sounds like a potential conflict and I am not going to be able to debug that. Since it sounds like you rely on Toolset, you might not be able to use RB4T.

I have no idea why I can’t get rid of the additional unwanted term. I’m sure that is user error on my part somewhere in the process. That one is more of a cosmetic problem though than something that would impede functionality. I just preferred to fix it and thought it would be an easy fix. Consider it a feature request that you make the addition of that field a setting choice that can be selected instead of it happening automatically without functions.php code intervention. I can see where it might be beneficial to some, but not to everyone.

But the problem with the Toolset Query Filter makes this plugin a no go for our needs. The reason we set up this taxonomy in the first place was to give Toolset something to filter on so we could limit the output that gets displayed. If that functionality is broken, then that defeats the purpose of having the taxonomy. I’ll bring this conflict up to Toolset support because they were the ones that steered me to your plugin as a potential solution. I had asked them if they have a way to make the custom taxonomies created with their plugin use radio buttons instead of checkboxes. Let me know if you’d be willing to assist if they take it up.

Can you share screenshots of your taxonomy setup in Toolset and then also your snippet implementation?

I set up a “view”
https://i.imgur.com/fpYTrei.png

And output that view in a block
https://i.imgur.com/spH12jT.png

And it shows me my posts that currently have “yes” as the term for “Add To Ride Maps Page” taxonomy I created yesterday. Changing the terms with RB4T changes the output as I would expect (and the same as without using radios).

RB4T limits the number of terms you can select by using radios, and also the number of terms returned when you query the terms for a specific post, but RB4T has no capacity to interfere with a WP_Query by taxonomy.

Can you check with Toolset support that your view is set up properly?

The view is definitely set up correctly. I found another plugin that does this and it is working fine. I’m still OK with resolving the issues with your plugin though. Please give me a bit to reach a point where I have some time. I’ll reply here when I’m able. It should be within a few days.

I’ll provide screencaps when I do so, but a quick description of what I saw on the Toolset side was when I tried to set up the Query Filter to only display items when Yes was the option selected on this taxonomy and saved that Query Filter, it saved, but it didn’t include the Yes option as the term it was filtering on. It just stayed blank. When I disabled your plugin and set it up again and saved, the Yes option did show.

Query Filter to only display items when Yes was the option selected on this taxonomy and saved that Query Filter, it saved, but it didn’t include the Yes option as the term

So you could not save the term for the Query filter? I can’t really see how my plugin would be interfering there but stranger things have happened. If I am understanding you correctly, it sounds like some kind of PHP error/notice might be preventing the Toolset save routine from completing.

If you can turn on WP_DEBUG and WP_DEBUG_LOG you might see some useful errors/notices in the debug.log. See debugging in WordPress. Right now we’re shooting entirely in the dark.

When I save the Query filter trying to set it to only display items where the Yes option is selected with that taxonomy, it should say the following:

Select posts with taxonomy:Add To Ride Maps Page?in?one?of these:?Yes

But with your plugin, when I saved it, it said

Select posts with taxonomy:Add To Ride Maps Page?in?one?of these:

the Yes option wouldn’t save. Then I found another plugin to convert taxonomies to radio buttons and it worked with that one. But now for testing purposes, I deactivated that plugin and reinstalled your’s, and the Toolset View is still working with your’s.

So I have to delete the Query Filter in the Toolset View and try to set it up again. I just did this and it is doing the same thing. It doesn’t save the Yes option. If you can’t replicate the issue on your end, I can see about doing the debugging request to help. But please see if you can get it to do the same on your end first. If the problem is something you feel is solely on this end and not something you see that’s happening with your plugin, then I’d rather just use the other plugin that works for me since that would be easier than debugging whatever is going on here.

Here’s a screen cap. Look at the bottom of this.

screen-cap-scaled.jpg (2560×937) (floridafreewheelers.com)

In looking again at the Views plugin source, I see that Views has a custom terms walker class called WPV_Walker_Taxonomy_Checkboxes_Flat

And that when RB4T is active, it hijacks this walker (A Walker is how WordPress iterates over a list of terms and displays them) and replaces it with my radio walker… that’s how I am able to replace the meta box inputs with radio buttons.

So I am interfering in that specific area a bit more than I thought (but in the same way as usual). However, the input names have *my* plugin’s custom input names, which could be interfering in the Views’ save routines.

It’s come up before that I might want to revert to using core’s input names for broader compatibility. Would you want to give it a test run:
https://github.com/helgatheviking/Radio-Buttons-for-Taxonomies/releases/download/2.5.0-beta.1/radio-buttons-for-taxonomies-2.5.0-beta.1.zip

I would definitively recommend testing this on staging though.

This whole site is still in development, so no problem using it to test. Give me a bit to download/install/test. More in my next reply.

Hmm… I’m not sure that’s the solution. the views plugin has their input names with different names than I expected (not exactly like core).

Another option would be to add some compat code and disable my radio walker in Views’ queries.