Posts loop inside a taxonomy loop

I have set a taxonomy term loop and added an accordion to it as the loop item then set the accordion title to be dynamicly loaded from the term name , so filnally I got a term loop which each item is an accordion .

Now I need to add a quiry to the content of the tab to load posts in that category , so each tab content must have a list of items related to the category which is the tab title.

any suggestion how can implement that .

@Louis is listing posts inside of a taxonomy loop possible?

If you have a simple taxonomy query on a page like this:

It will show the list of taxonomies, but nesting a Query block causes a critical error (even if you haven’t changed any of the query settings).

If trying to do this in an archive template, the critical error doesn’t happen, but I don’t think it’s possible to get the current term ID?

Hi @sunny,

Could you possibly let me know the error that appears in the browser console? Definitely shouldn’t be happening.

As for accessing the current taxonomy and term:

No console error, just a 500 Server Error when saving, and a critical error on the front-end.

Here’s what the server log says:

2023/02/17 03:34:45 [error] 1451516#1451516: *211283 FastCGI sent in stderr: "PHP message: PHP Warning:  Undefined array key "videoType" in /var/www/mydomain.com/htdocs/wp-content/plugins/cwicly/core/includes/dynamic/query/cc-query-templater.php on line 977PHP message: PHP Fatal error:  Uncaught Error: Call to undefined method WP_Term_Query::have_posts() in /var/www/mydomain.com/htdocs/wp-content/plugins/cwicly/core/includes/dynamic/cc-helpers.php:526
Stack trace:
#0 /var/www/mydomain.com/htdocs/wp-content/plugins/cwicly/core/includes/dynamic/render.php(218): cc_query_front_maker()
#1 /var/www/mydomain.com/htdocs/wp-content/plugins/cwicly/core/includes/dynamic-blocks/query-template/query-template.php(52): cc_render()
#2 /var/www/mydomain.com/htdocs/wp-includes/class-wp-block.php(256): cc_query_template_render_callback()
#3 /var/www/mydomain.com/htdocs/wp-includes/class-wp-block.php(242): WP_Block->render()
#4 /var/www/mydomain.com/htdocs/wp-includes/class-wp-block.php(242): WP_Block->render()
#5 /var/www/mydomain.com/htdocs/wp-includes/class-wp-block.php(242): WP_Block->render()
#6 /var/www/mydomain.com/htdocs/wp-content/plugins/cwicly/core/includes/dynamic/cc-helpers.php(501): WP_Block->render()
#7 /var/www/mydomain.com/h" while reading response header from upstream, client: 99.123.456.19, server: mydomain.com, request: "POST /wp-json/wp/v2/pages/677/autosaves?_locale=user HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php81-fpm-mydomain.com.sock:", host: "mydomain.com", referrer: "https://mydomain.com/wp-admin/post.php?post=677&action=edit"

Oh wait, I definitely wasn’t using a Taxonomy Terms element. Just a nested query. Will need to play around with it tomorrow to see if that’s the secret unlock.

This is interesting. I think using a Taxonomy Terms element with a Query nested inside will work (instead of Query → Query), but there may be a bug?

Works perfectly on the backend:

But nothing on the frontend:

This is the case when trying in both a page and archive template.

Thank you for the log, @sunny, I was able to reproduce this on my side and will investigate further.

1 Like

That should definitely work.

Just to make sure: Frontend Rendering isn’t toggled on?

1 Like

It was on. Turning it off just fixed it :no_mouth:.

I probably don’t fully understand frontend rendering - what are the main differences between having it toggled on and off?

:+1:

With Frontend Rendering, all blocks (and queries) are rendered (created) on the user end instead of server end. This allows us a lot more freedom when manipulating data (Filter block) since we have access to all the context, and helps the server performance wise when dealing with similar/repeater layouts.

What is happening here is that the Taxonomy Terms block is rendered on the server but your Query block is rendered on the user side, essentially they’re not communicating with eachother.

We will be extending Frontend Rendering to the Div block so that you can have one context box instead of limiting it to the Query and Filter Block.

2 Likes

Ah, that makes a lot more sense. Thank you for clarifying!

That seems to be related to this bug report as well: Taxonomy terms don't show on front-end if wrapped in div

If I turn off frontend rendering on the main query, those taxonomy terms show up on the frontend.

What makes less sense though is that the terms show up on the frontend if they’re not wrapped in a div - even with frontend rendering still enabled.

Do you think that’s a bug, or should I reconsider putting taxonomy terms inside of a frontend rendered-query for the time being?

Araminta seems to have confirmed it, but I will take a look and confirm on my side. But it does sound like a bug.
If so, we should have this fixed in the next update → Monday.

Normally, anything inside a frontend rendered block should work as if rendered on the server. Sorry for the inconvenience on this one!

No problem - luckily I’m not ready to launch the site yet today anyways :slight_smile:

So just to confirm 100%:

  • anything inside a frontend rendered block should work as if rendered on the server, including queries with frontend rendering off
  • anything inside a non-frontend rendered block needs to have frontend rendering off as well

Is that correct?

Nested queries are on their way, but currently not supported within a Frontend Rendered block (requires a few fixes for the filtering logic and parent context).

Not quite :slight_smile: If you want to inherit some context from the parent block (term ID, post ID), then the parent will have to have frontend rendering active if your child has frontend rendering.