1.3.0 Update caused existing Taxonomy listings to load the homepage

Interesting.

Logically it shouldn’t have an effect since it’d still be using the saved options, and not auto-updating anything from the new UI fields available. So I’m not sure what exactly went on there. The public parameter should have been defaulting to whatever WordPress takes when no specific parameter is provided.

On the flip side, it’s good to know that it was resolved easily enough.

Thanks Michael,

For sure, I’m glad it was just a resave that was needed. Not sure if a note needs to be added to your troubleshooting or an alert. Or maybe during update have it apply the added defaults to the existing taxonomies.

let me know how I can assist.

Cheers

Defaults should get applied inside the WP core registration functions if not explicitly passed in. Regardless if it comes up more, we will investigate deeper and see what may need done differently. Thanks ??

FYI – it happened with all eight of our sites as well. For the benefit of anybody else troubleshooting the issue, go to:

-CPT UI , Add/Edit Taxonomies
-Edit Taxonomies
-Save Taxonomy

That’s it! I assume you should click the drop-down box and click save for each taxonomy you have, if you have more than one defined.

Hmmm, can either of you provide an example setup of how you are querying and displaying these on the frontend so we can test and try to fix. I assume we need more than just some settings for the plugin itself

Same issue for me with two taxonomy templates. One of my taxonomies is named location. The template file is taxonomy-location.php

<div id="primary" class="content-area">
		<main id="main" class="site-main" role="main">
		<?php
		$args = array(
			 'post_type' => 'tour',
			'tax_query' => array(
				array(
					'taxonomy' => 'location',
					'field'    => 'id',
					'terms'    =>  $wp_query->get_queried_object_id() ,
				),
			),
		);
		$query = new WP_Query( $args ); ?>

		<?php if ( $query->have_posts() ) : ?>
			<section>
				<div class="container banner text-center">
					<header class="entry-header">
						<h1 class="entry-title"><?php single_cat_title(); ?> Tours</h1>
						<p><?php the_archive_description('<div class="taxonomy-description">', '</div>'); ?></p>
						<a href="#tour-listings">See the tours that visit <?php single_cat_title(); ?> below</a>
					</header>
		    	</div>
			</section>

			<div id="tour-listings" class="container">
				<div class="row">
					<div class="col-sm-12">
					 	<div id="masonry-loop">
						<?php while ( $query->have_posts() ) : $query->the_post(); ?>
							<?php get_template_part( 'template-parts/content', 'masonry-tour' ); ?>
						<?php endwhile; ?>
						</div><!--/#masonry-loop-->
					</div>
				</div>
			</div>
			<?php //the_posts_navigation(); ?>

		<?php else : ?>

			<?php get_template_part( 'template-parts/content', 'none' ); ?>

		<?php endif; ?>

		</main><!-- #main -->
	</div><!-- #primary -->

<?php get_footer(); ?>

Editing and saving the taxonomy resolved the issue

markkelly, at least in your case…there was issues with the public aspect, during a case of a custom WP_Query running inside the template file for the term archive requested url.

Not saying it’s necessarily wrong, but I am curious why you’re doing the extra WP_Query in this case. Is it to get posts just for the “tour” post type? Wondering if that would have also been possible to do with pre_get_posts.

Regardless, I do have some stuff to work off of here. Waiting to hear back from others in this thread as well.

https://github.com/WebDevStudios/custom-post-type-ui/issues/453

Same issue, pressing save fixed (whew!). Here is the code I used:

<?php
  $terms = get_terms('members-cats', 'orderby=count&hide_empty=0&parent=0');
  if ( !empty( $terms ) && !is_wp_error( $terms ) ){
  foreach ( $terms as $term ) {
     $term = sanitize_term( $term, 'members-cats' );
     $term_link = get_term_link( $term, 'members-cats' );
      echo '<h3><a href="' . esc_url( $term_link ) . '">' . $term->name . '</a></h3>';
  }
  }
?>

I had the exact same issue, saving the taxonomy immediately resolved it for me, too.

Same as the rest – had to re-save, taxonomies were not pulling through, all working now though.

<?php
        $tax = 'topic-category';
        $terms = get_terms($tax);
        if ( $terms && !is_wp_error($terms) ){

            foreach ( $terms as $term ) :
                $count = $term->count;
                $name = $term->name;
                $link = get_term_link($term, $tax);
    ?>

                    <h2><a href="<?php echo $link; ?>"><?php echo $name ?></a></h2>
                    <p><em><?php echo $count; ?> Topics</em></p>

    <?php
            endforeach;
        }
    ?>

Anyone here have a version of your settings from BEFORE you clicked update to fix the issue? I want to test a fix for this but need the public setting not explicitly set yet in the CPTUI options. If you have a test site that hasn’t been updated yet, or a backup of the database that you can fetch the cptui_taxonomies option from, I’d appreciate it.

I do. What do you want me to do?

Carolyn, this copy should have everything you need to test quick: https://github.com/WebDevStudios/custom-post-type-ui/archive/master.zip

It should extract to a folder named “custom-post-type-ui-master” so it can be installed alongside 1.3.0 right now and you could easily switch back and forth long enough to test. Make sure to deactivate the 1.3.0 version first, before activating this new one. Same thing for when switching back. Don’t have them both active at the same time or you’ll get a PHP error that’ll cause access issues.

Done, taxonomies back.