Get CPT Categories and Archives to show in WP Category and Archive Widgets

This is what I have add in the functions.php file.
When I click on the dropdown menu for the CPT Categories widget, the categories are showing, and when I select any of them the page will not refresh, the URL does not change, the page stays the same.
Recall that I am using this plugin with its Categories widget installed. That is the one where the CPT categories show up in the dropdown menu but when I select one nothing changes on the page. The page just refreshes and stays the same.
Custom Post Type Widgets

//Adding all CPTUI post types to the archives.
function my_cptui_add_post_types_to_archives( $query ) {
	// We do not want unintended consequences.
	if ( is_admin() || ! $query->is_main_query() ) {
		return;
	}

	if ( is_category() || is_tag() && empty( $query->query_vars['suppress_filters'] ) ) {
		$cptui_post_types = cptui_get_post_type_slugs();

		$query->set(
			'post_type',
			array_merge(
				array( 'post' ),
				$cptui_post_types
			)
		);
	}
}
add_filter( 'pre_get_posts', 'my_cptui_add_post_types_to_archives' );

• This reply was modified 5 years, 11 months ago by benjammin.

As I hope I have mentioned previously, the code above is not going to affect the widget at all. It would only be affecting what should be getting queried and displayed when clicking on the category/tag links that the widget displays.

The code above is meant to say “when visiting the archive for this category term, fetch all post posts and all myposttype posts that have this category term assigned to it.

Now, if we’re dealing with a custom taxonomy, then we should probably amend this code to also do that same thing for that custom taxonomy. I believe is_tax() should do it

if ( is_category() || is_tag() || is_tax('mytaxonomy') && empty( $query->query_vars['suppress_filters'] ) ) {

I’m not presently worrying about the widget itself, just where it sends you and what’s requested once there.

I added that ‘if’ statement to the block and it doesn’t change any query behavior, the page refreshes and stays the same. I tried both that CPT Widget plugin and the default WP Categories widget (which doesn’t populate with the custom post type categories btw), and neither widgets does anything for CPTs OR default blog loop. So not even my default WP Categories widget works on the the default WP blog. Odd.

If you go to My Dev Site at this link, and go to the bottom of the right sidebar you’ll see example widgets. The widgets with ‘CPT’ in their title name are the custom CPT widgets, and the ones with ‘WP’ in their title are default WP widgets. Neither of the Category widgets are working. Odd.

Your link isn’t working. Gives me “Tunnel c30bce13.ngrok.io not found” error.

All that the widgets do is create links to term archives, whether it be for a category, a tag, or a custom taxonomy. I’m not worrying about those details or the widgets at all. They’re not where the issues reside.

I don’t presently know why any attempts previously with the query amending hasn’t worked, as I’m not able to actually see what the generated SQL is ending up being for the archives. What I do know is that these pre_get_post filter attempts are the proper way to do it and should be working. The only other answer I can guess right now is that there simply aren’t any posts matching yet.

I’m so sorry, I mistakenly put my apple to sleep, ngrok won’t work then. It’s back up.

Well what would you need to see what’s going on?

• This reply was modified 5 years, 11 months ago by benjammin.

No worries on the sleeping computer detail.

Question. Does this URL show the posts you’re expecting? https://c30bce13.ngrok.io/category/infogov/

Similarly, what about this one? https://c30bce13.ngrok.io/topics/ecm-efss/

Asking because what I’m seeing is that this is the original page you linked to:
https://c30bce13.ngrok.io/information-governance-topics/information-privacy/ and the dropdowns are taking that current URL and appending things like ?topics=regulatory-compliance-news which is simply calling that same Information Privacy page with some extra parameters on the URL. This would be why you’re just seeing the exact same content. You’re not being sent to the actual archive URL.

What the dropdowns SHOULD be doing is sending you to a url like https://c30bce13.ngrok.io/?topics=regulatory-compliance-news which would then get the rewrites triggered and make the URL be https://c30bce13.ngrok.io/topics/regulatory-compliance-news/

Now that we have that established, and know the types of URLs we should be viewing, we can double check that the category/tag/tax archive inclusions are working.

Steps have been taken ??

Yes, I noticed that before this response… that the dropdowns are appending the current URL.

Yes, I agree that the dropdowns should be sending you to the rewrite URL and then to the final URL you showed. If you go to each IG Topic index page you can click on the category links in each post index, they go the right link which would be as you showed.

Well here’s what I have and it doesn’t affect the widgets in the proper way:

//Adding all CPTUI post types to the archives.
function my_cptui_add_post_types_to_archives( $query ) {
	// We do not want unintended consequences.
	if ( is_admin() || ! $query->is_main_query() ) {
		return;
	}

	if ( is_category() || is_tag() || is_tax('ig_topics') && empty( $query->query_vars['suppress_filters'] ) ) {

		$cptui_post_types = cptui_get_post_type_slugs();

		$query->set(
			'post_type',
			array_merge(
				array( 'post' ),
				$cptui_post_types
			)
		);
	}
}
add_filter( 'pre_get_posts', 'my_cptui_add_post_types_to_archives' );

What do you need to see to more effectively help?

• This reply was modified 5 years, 11 months ago by benjammin.
• This reply was modified 5 years, 11 months ago by benjammin.

None of these work:

if ( is_category() || is_tag() || is_tax('ig_topics') && empty( $query->query_vars['suppress_filters'] ) ) {

if ( is_category() || is_tag() || is_tax('topics') && empty( $query->query_vars['suppress_filters'] ) ) {

if ( is_category() || is_tag() || is_tax('ig-topics') && empty( $query->query_vars['suppress_filters'] ) ) {

Ultimately the issue is the widgets are “broken” because they’re not sending you to the right url. This is also why I was requesting that you confirm the urls like the ones below. It’s because those are the actual proper archive URLs for a given terms, where the code I’ve provided would be/should be actually aiding like expected.

https://c30bce13.ngrok.io/topics/ecm-efss/
https://c30bce13.ngrok.io/category/infogov/

That said, I have some new leads for why they’re potentially “broken”. I’ve checked the original widget plugin, and for the dropdown form, it should be having an action value of the base URL. <form action="https://c30bce13.ngrok.io/" method="get"> However, with your page, there’s no action value presented and it appears to be because of cleantalk-spam-protect and some of its javascript. So, if you would be willing, could you try disabling that plugin temporarily and re-try with these widgets to see if the intended URLs are where you’re ending up once selecting a term?

I disabled Clean Talk and now every possible plugin I have without removing BB and B. Themer.

I’ve cleared browser cache, and BB Cache too.

Are you sure it’s because of Clean Talk?

I see where you’re going with this; if you remove this “/information-governance-topics/information-privacy” you’re left with this “/?topics=data-governance,” for example, and that will then redirect to the archive. If I remove the former from the query leaving the latter, then it works as it should. Question is, what is keeping it from leaving this “/information-governance-topics/information-privacy” in the way each time?

• This reply was modified 5 years, 11 months ago by benjammin.
• This reply was modified 5 years, 11 months ago by benjammin.

Nope, not 100% sure that it’s Clean Talk causing things, but it’s the best lead I have right now, because there’s no “action=whatever” attribute on the form when there should be, and that plugin would affect forms like the dropdown has. If the plugin is removing that action value, the form would submit to it the current URL it’s on, which is why you’re staying where you’re at.

Hello.

Thank you for your feedback about CleanTalk.

We will test the plugins together and troubleshoot any conflicts if there are any.

It may take 2-3 work days.

Thank you.

I opened a ticket with the theme developer thinking that might be a cause. This issue is beyond me. I do appreciate all of your help!

@serge00 for what it’s worth, the issue isn’t with Custom Post Type UI, but I am wondering if your plugin has some javascript that is removing the action attribute on a form in @benjino’s site. If it’s not then, there’s no conflict from CleanTalk. Given the view source, there’s no filled in attribute there either, as opposed to browser dev tools, so in the end I may be wrong there.

Just trying to help find solutions as best possible. I ultimately feel confident that I have found the source of the issue, it’s just a matter of helping figure out why ??