This is based on the following Toolset documentation.
NOTE: I had to add 'suppress_filters' => true, to get this to work, otherwise Bricks outputs Error: error and doesn't render anything in the builder itself. It will render the correct result on the fornt end. The only problem with 'suppress_filters' => true, is that while it does render in the backend, it will load every instance of the post type in the back end. That was a lot in my case with 216 prints to look at. The solution here, if you need to do any extra layout work, beyond the archive view is to set suppress filters to false and just ignore the Error: error message.
Attached the result which very much matches what's on my live site.
There are a few more loop scenarios I need to check, but that's for another day.
If anyone has any insights into wasy to deal with the Error: error messgae, it woulf be much appreciated.
Without knowing Bricks very well I can't say why the error might be occurring on the back end.
Rather than having to modify the query arguments to include or not include the suppress_filters argument, and dealing with errors or a large number of posts, can you set up your custom query such that it will work on the front end, and then while editing in the back end temporarily change to a standard Bricks query for your post type and set a limit of 10 or whatever is appropriate.
Then when you are done editing, switch back to select your custom query.
Thanks Nigel, great suggestion. A little more sanity returned as I venture through the optimal solution of being able to run and style queries directly in Bricks. I also figured out how to refactor all this down to just returning the args in Bricks's new PHP query Loop Editor. So no need for the more comples set up as per the Bricks Lab's longer solution.
I suggestd to your colleages, in earlier versions of this ticket, that there would be merit in Toolset running a series of tutorial posts expaling how all these complex queries in via php woulf benefit in promoting Toolset, which is very powerful compared to the other CPT/Custum filed offerings out there. It's like Toolset is hiding its light under a bushel and I think the documentation, now under the legacy category, should be updated to expose what can be done for developers who won't necessarily be using the block edirtor.
I checked the server logs and it didn't report anything but when I activate Query monitor it reports deprications on Toolset Blocks. They may not have any bearing on this exact problem but I attach a screenshot in any event.
In the changelog for the latest version of TS Blocks it states that deprication warnings have been fixed?
The site is running on PHP 8.1.28. Might I need to switch to a differnt version?
Some deprecation notices we discover through scans and automated testing, others only surface in real-world uses and we fix them as we learn about them.
If you are seeing those with the latest updates installed then it looks like new ones we haven't come across before.
What is the context for when they appear?
Am I right in understanding they only appear in Query Monitor, not the debug log?
That's odd. Query Monitor is running code, so it's not inconceivable that it is implicated. In any case, they are innocuous, they won't have any functional effect for now.
Could I ask you to share the text of the messages? It's inaccessible in the images.
Just so you know, I've made some great strides in the last week with resolving the build of query loops directily in Bricks builder using the PHP editor that they offer there. I managed to get a related brother view, sans the current child post currently viewed. Using this. The trick is to first query in the parent and then run the related query in anouther loop nestred within.
It would be great if betweeen Toolset and Bricks some of the errors could be removed and also see some more documentation and post on the configurations that work.