WP Fusion’s Filter Queries option allows you to modify the results of database queries to exclude content that a user can’t access (based on WP Fusion’s access rules).

When used in Advanced mode, Filter Queries will build up a list of posts a user has access to before the main query is run, and add it to the main query via the post__not_in parameter (in order to exclude any restricted posts).

The wpf_query_filter_get_posts_args filter lets you modify the arguments going into that query.


  • $args (array): WP_Query arguments


To protect the stability of your site, the pre-query will load at most 200 restricted posts. However if you have more than 200 posts of that post type which are protected by WP Fusion’s access rules, this could cause users to see posts they don’t have access to.

The example below extends the pre-query to check the first 1000 restricted posts.

Note that this can cause multiple thousands of extra database queries per page load, so it should be used with extreme caution.

function filter_query_posts_args( $args ) {

	$args['posts_per_page'] = 1000;

	return $args;


add_filter( 'wpf_query_filter_get_posts_args', 'filter_query_posts_args' );

#Activate Ludicrous Mode

By default, the pre-query only looks at posts that have WP Fusion access rules saved to their postmeta.

This provides improved performance, but it means that posts protected by post type rules or taxonomy term rules will not necessarily be excluded from the results, even in Advanced mode.

This snippet removes the meta_query and also sets the posts_per_page to 5000. Effectively this means that every post of the post type will be pre-checked for access before the query is run.

If you have a lot of posts and/or taxonomy terms, this will almost certainly crash your site. Use with caution.

function filter_query_ludicrous_mode( $args ) {

	$args['posts_per_page'] = 5000;
	unset( $args['meta_query'] );

	return $args;


add_filter( 'wpf_query_filter_get_posts_args', 'filter_query_ludicrous_mode' );

This functionality could be made more performant by running it on a schedule (or as content is published) and building up a cache of the access list for every user on the site, ideally in a custom database table. However that is beyond the scope of this article.

Was this helpful?