Skip Navigation

[Resolved] Nested views with block editor

This support ticket is created 3 years, 11 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

This topic contains 5 replies, has 2 voices.

Last updated by franzG-4 3 years, 10 months ago.

Assisted by: Waqar.

Author
Posts
#1889131

Tell us what you are trying to do?

=> I created a custom user post containg customer's data, which I used to build a user view with BLOCK EDITOR. If a user logs in, the view just shows the data of the logged in user, since query filter is set to post author = logged in user.

=> Every user is assigned to a category or taxonomy, which represents the industrial sector he is coming from. This category is also displayed in the user post and in the user view respectively.

=> On the other side I build a view displaying news about legal developments. All the news are assigned to several industrial sectors, the same as applied for users.

My plan: if user logs in and looks at the news directory, he sees only the news from his industrial sector. I am aware that I could use a front-end filter for users to select their sector, but I would prefer that this is done automatically.

Is there any documentation that you are following?

Based on https://toolset.com/documentation/user-guides/views/filtering-views-by-taxonomy/ I had the idea, that by building a nested view (parent view = user view, child view = news view), the taxonomy term, which is filtering the news view comes from the taxonomy term of the loged in user.

But I did found nothing about building nested views with BLOCK EDITOR (where exactly should I insert the parent view)???? And would this kind of passing arguments be feasible?

Is there a similar example that we can see?

What is the link to your site?

#1889317

Hi,

Thank you for contacting us and I'd be happy to assist.

The nesting of views is only supported when using the classic editor views.
( ref: https://toolset.com/documentation/legacy-features/views-plugin/using-a-child-view-in-a-taxonomy-view-layout/ )

I may have a workaround to suggest for what you're trying, but for that, I'll first need to understand exactly how different components are set up on your website.

Can you please share temporary admin access details, along with the link to a page with the view, where you'd like to apply this taxonomy filtering?

Note: Your next reply will be private and please make a complete backup copy, before sharing the access details.

regards,
Waqar

#1893615

Hi Franz,

Thank you for sharing these details.

Looking at the current setup, I'll recommend to keep using a post view for the news page and then use "wpv_filter_query" hook to programmatically limit the results, filtered by a specific "Branchen" term.
( ref: https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query )

I can share a more specific example, but, I can't seem to understand how "Branchen" taxonomy terms are linked with the user profile posts (Kunden)? The "Branchen" taxonomy is associated with the "Beiträge" post type, but not with the "Kunden".

regards,
Waqar

#1896579

hi Waqar,

many thanks for your answer! Two points are open for me:

- Do the "wpv_filter_query hooks" not correspond to the query filters used in the block editor, when in the view navigator "view" is selected ? (right sidebar)

- The news view may be limited by the branch terms. But "Kunden" / customers are also assigned to branch terms, and my simple plan was: a customer belonging to branch x can see in the view the posts belonging to branch x. But it seems that's not possible.

In the meantime, I tried another approach, which seems to work: based on the plugin "groups", I can subdivide users in groups corresponding to branch terms. I then define access rights to the pages which contain the news views - based on branch terms. If a user belonging to branch term x can access the page belonging to branch term x, and the news view uses the taxonomy coming from the page (query filter), then the user can see exactly the posts corresponding to his branch term automatically.

Is it possible to let this ticket open for a few days, because I am still thinking about alernatives? Or is it better to reopen a new one?

Kind regards

Franz

#1896947

Thanks for writing back.

The hook "wpv_filter_query" is useful when we need to programmatically override the view's main query. This is not dependant on the front-end query filters.

Consider this example, to make it more clear. Suppose you have a view with ID "12345" that shows all posts and there are no query filter/search fields in the view.

To programmatically, limit the results to only posts attached to the term with ID "456" in taxonomy "project-type", the code will look like this:
( ref: https://developer.wordpress.org/reference/classes/wp_tax_query/ )


add_filter( 'wpv_filter_query', 'filter_include_cat_fn', 1000 , 3 );
function filter_include_cat_fn( $query_args, $view_settings ) {

	if ( !is_admin() && ( isset($view_settings['view_id']) && $view_settings['view_id'] == 12345) ) {
		$query_args['tax_query'][0]['taxonomy'] = 'project-type';
		$query_args['tax_query'][0]['field'] = 'id';
		$query_args['tax_query'][0]['terms'][0] = 456;
		$query_args['tax_query'][0]['operator'] = 'IN';
		$query_args['tax_query'][0]['include_children'] = '';
		$query_args['tax_query']['relation'] = 'AND';     
	}
	
	return $query_args;
}

In this example, I've used a static term value "456", but you can imagine that this gives you infinite possibilities to make this filtering dynamic.

The approach that you've shared seems fine and you can keep using it if it is working.

This ticket will remain open for a couple of weeks. If you have a follow-up question after it is closed, you can start a new one and include this ticket's link, so that we know the context.

#1901503

My issue is resolved now. Thank you!