distinct

Hi Kevin,

Thank you for your quick reply! I have indeed tried to toggle the checkboxes of the other fields, but unfortunately to no avail. I will use a custom class to hide the ‘hidden’ fields.

Thanks again!

Best, Lauren

I agree that we should use WP_Query, but this was code build by someone else that we now maintain. Anyway, WP_Query is not really any different from query_posts with regards to query_vars as far as I know. So that has nothing to do with this problem.

I think I have a better understanding of the problem now. The label of the ‘public’ parameter to register_taxonomy has some conflicts between what WordPress will do and what your plugin mentions (or at least the Dutch translation). It says that a non public taxonomy will be hidden from the admin. But this is not really the meaning of public according to the codex. It is whether the taxonomy will be publicly queryable.
Setting this to false while expecting your description (only hide it) will therefor also disable the query var.

The behavior we want would therefor be leaving public to true and setting show_ui and other flags to false. This leaves the taxonomy queryable, but hides it from admins.

So maybe you should change the label for the ‘public’ setting?

Yeah, Aaron, I didn’t know if you would find this topic. Should have mentioned it there. But you made your way here anyway.

I don’t completely agree that the security issue should not be detailed. Security through obscurity is not a good practice. But I guess you don’t want to make it too easy for attackers to exploit unupdated sites (though those would probably have a lot more security holes). If the reason not to explain the security problem is because the current changes to the shortcode system still don’t fix it, we might have a more serious problem ??

But details aside, I don’t see how breaking a lot of sites without a way (filter or define) to revert to old behaviour for sites that don’t have the security problem is a good thing. You should at least keep feature parity.
Of course such filters or defines should come with a big WARNING, but that comes with the territory.

I’m a bit scared about the future of the shortcodes, but for now I have circumvented my problem by preprocessing the post_content with ‘<!– [shortcode] –>’ to become ‘[shortcode]’
This of course only works for certain cases, but at least it keeps the Visual editor from wrapping it in paragraphs and breaking the table. And should still work with the current shortcode status.

This looks like the beginning of a templating engine, so I might search for some lightweight variant that might give me what I need here. No need to reinvent the wheel.

aaroncampbell was kind enough to go into more detail after I posted this forum thread. But I do not agree with your point about comments. As far as I know shortcodes are not processed in comments.

And I do think not all sites have the security risks he mentions about contributors. Some sites are well organized with only a few allowed authors/administrators who do know what they are doing. And disallowing them previously functioning features is to big of an impact in my opinion. At least give a way for those sites to keep working the way they were.

Without more information on the real security issues I don’t know whether my use of the nested content in shortcodes is really a problem in certain situations. So now I don’t really have any incentive to go look for alternatives for any real reason other than that you forced me too.

I’m still on the fence whether I should start using another type of templating engine for my requirements. But the way shortcodes used to function did not give me any reason to look into this.

I encountered a similar error, where parameters to previous_post_link were ignored. I traced it to the following filters in post-type-order.php:

add_filter('get_previous_post_where', 'cpto_get_previous_post_where', 10, 3);
add_filter('get_previous_post_sort', 'cpto_get_previous_post_sort');
add_filter('get_next_post_where', 'cpto_get_next_post_where', 10, 3);
add_filter('get_next_post_sort', 'cpto_get_next_post_sort');

I added the extra parameters “10, 3”, they are needed to get extra information.

After that the functions “cpto_get_previous_post_where” and “cpto_get_next_post_where” need some fixes to support arrays for $excluded_categories. I copied code from wordpress original ‘get_adjacent_post’ function

if (isset($in_same_cat))
        if ( $in_same_cat || !empty($excluded_categories) )
            {
                $join = " INNER JOIN $wpdb->term_relationships AS tr ON p.ID = tr.object_id INNER JOIN $wpdb->term_taxonomy tt ON tr.term_taxonomy_id = tt.term_taxonomy_id";

		if ( $in_same_cat ) {
			if ( ! is_object_in_taxonomy( $post->post_type, 'category' ) )
				return '';
			$cat_array = wp_get_object_terms($post->ID, 'category', array('fields' => 'ids'));
			if ( ! $cat_array || is_wp_error( $cat_array ) )
				return '';
			$join .= " AND tt.taxonomy = 'category' AND tt.term_id IN (" . implode(',', $cat_array) . ")";
		}

		$posts_in_ex_cats_sql = "AND tt.taxonomy = 'category'";
		if ( ! empty( $excluded_categories ) ) {
			if ( ! is_array( $excluded_categories ) ) {
				// back-compat, $excluded_categories used to be IDs separated by " and "
				if ( strpos( $excluded_categories, ' and ' ) !== false ) {
					_deprecated_argument( __FUNCTION__, '3.3', sprintf( __( 'Use commas instead of %s to separate excluded categories.' ), "'and'" ) );
					$excluded_categories = explode( ' and ', $excluded_categories );
				} else {
					$excluded_categories = explode( ',', $excluded_categories );
				}
			}

			$excluded_categories = array_map( 'intval', $excluded_categories );

			if ( ! empty( $cat_array ) ) {
				$excluded_categories = array_diff($excluded_categories, $cat_array);
				$posts_in_ex_cats_sql = '';
			}

			if ( !empty($excluded_categories) ) {
				$posts_in_ex_cats_sql = " AND tt.taxonomy = 'category' AND tt.term_id NOT IN (" . implode($excluded_categories, ',') . ')';
			}
		}
            }

I hope that the plugin can be fixed with this information.