[Geschlossen] Automating a link between Toolset Relationships and BuddyBoss/bbPress Forums

[Author]

Artikel

[NickC8880]

Note: I expect that this will require a lot of back and forth communication, so I'd like to please request the assistance of Shane or Christian, ideally, or Jamal or Nigel as a backup, given the time-zone proximity.

---

I am using the BuddyBoss platform, which is derived from BuddyPress and bbpress, and I would like to create a Toolset View to provide more comprehensive searching to the Forums component. The forums are structured as Forums -> O2M -> Topics -> O2M -> Replies.

In addition to the basic search field, I'd like to have search filters that allow you to select results based on which Forum they belong to (parent for topic, grandparent for reply), and decide whether to return results as Topics or individual Replies from within the Topics. I'd also like to be able to present fields from each of the levels in the view results (at a minimum, Forum Title/URL, Topic Title/URL, and Topic/Reply Content and Date, Author, Date/Time)

I should note that these are all custom post types that are stored within wp_posts, using the post_parent field to identify their relationships as follows:

- Forum "Countries" has ID of 10.
- Topic "Canada" has ID 11 and post_parent 10.
- Reply "Canada is a nice country" has ID 12 and post parent 11.
- A reply to that reply "I agree!" has ID 13 and post_parent 11 - its important to note that all replies use their respective TOPIC as the post_parent, and the reply nesting is stored in the field "reply_to" in wp_postmeta. This is fine with me, because the search results do not need to reflect any nesting.

Does it make sense to leverage these existing relationships with some custom code that drives the Toolset View, or would it be advantageous to hook into the BB topic/reply creation code and integrate/sync them with Toolset Relationships?

Either way there will be some custom coding, but I don't have a conception of which would be easier to achieve. Difficulty aside, my true priorities are to be able to use as much of Toolset's GUI as possible for View creation, and to ensure high performance by minimizing the amount and complexity of any database queries made by the View and its search filters. As such, my suspicion is that it would be best to figure out how to populate the Toolset relationships upon Topic/Reply creation, but I will go with whatever you think is best.

Do you have any advice on which route to pursue? Once that is selected, I will be happy to dig into the BB code to identify the relevant templates, functions and hooks to make this possible. It is well structured and documented code, so I'm confident that it shouldn't be terribly difficult to achieve this goal with a bit of guidance on how to tie into Toolset.

Thank you!

[NickC8880]

Another thought: I have this Automator plugin (versteckter Link) which allows for creating all sorts of trigger/action recipes, including when a BB topic or reply is created. If you could instruct me as to which fields should be updated in order to register a Toolset Relationship between posts, I could see if I can use this to do it. Of course, if you have some code that will do this instead, it would be more efficient and future-proof (should I cancel that subscription) than going through this Automator-middleman.

[NickC8880]

Ignore my previous message - it appears that Toolset relationships are stored in their own database tables and I don't believe that Automator can access anything beyond wp_posts.

[NickC8880]

I may have figured it out on my own... I found two hooks that run after wp_insert_post is run for a topic or reply. They are defined as follows:

do_action( 'bbp_new_reply', $reply_id, $topic_id, $forum_id, $anonymous_data, $reply_author, false, $reply_to );
do_action( 'bbp_new_topic', $topic_id, $forum_id, $anonymous_data, $topic_author );

So, how does this code look? Is there any need to make use of the other variables that are available from those hooks?

function create_topic_reply_relation($reply_id, $topic_id) {
	return toolset_connect_posts('discussion-reply', $topic_id, $reply_id);	
}
add_action( 'bbp_new_reply', 'create_topic_reply_relation', 10, 2);

function create_forum_topic_relation($topic_id, $forum_id) {
	return toolset_connect_posts('forum-discussion',$forum_id, $topic_id);	
}
add_action( 'bbp_new_topic', 'create_forum_topic_relation', 10, 2);

[NickC8880]

Regardless of whether this code is mostly correct, I now realize there are other complications. Topics and replies can have a variety of actions performed on them - in addition to delete, you can split a topic in two, merge two topics, move a reply to a different topic, and extract a reply into its own topic.

Relationships records in the database delete just fine when I delete a reply or topic, but what would be the mechanism for updating/changing a relationship? I don't see anything in the Relationships API for this. Would I use toolset_disconnect_posts and then toolset_connect_posts for the new relationship?

Whatever the case, I do worry that I would not sufficiently handle all outcomes and I'd end up with bad relationship data. So, if I just ignore Toolset Relationships and filter the View based on the post_parent field (which is assured to be accurate) would I lose significant functionality in terms of being able to create and populate views with fields from child, parent and grandparents, and perhaps even suffer from a performance standpoint if it would be a less efficient query mechanism?

[Jamal]

Hello and thank you for contacting Toolset support.

If I understand well, you want to build an advanced search for forums, topics, and replies, and you would like to have relationships and other fields in the search filters. Your initial idea is to synchronize the built-in BuddyBoss/bbPress relations(based on the post_parent) to Toolset O2M relationships, in order to use them on the search filters. right?

First, let me explain how views work, so you can have more insights and better decide what to do.

A view is, somehow, just a wrapper around a WP_Query instance. It offers search filters, converts them into arguments for the WP_Query instance, and then displays the results. It also leverages sorting and pagination. In addition to that, it can also offer conditional displaying, and relationship-based search.

The relationships are stored in separate tables. Toolset performs a search based on the relationships first. Then it passes the results to the post__in argument of the WP_Query. Then, it delegates the search to WordPress, and it displays the results(with some additional work, for example, updating the filters to include only the options that will produce results).
https://developer.wordpress.org/reference/classes/wp_query/#post-page-parameters

Views offer a text-based search, that is based on the post's title or the title+excerpt+content. Integration with the Relevanssi plugin allows performing text search on custom fields too. This means, that you can't really integrate views' searches in the default BoddyBoss/bbPress search. You must use a view.

This being said, let me answer your question about syncing the links between replies, topics, and forums. The code that you shared in your reply(#2131191) seems correct to me. And you are right about your last reply. You may need to use toolset_disconnect_posts and toolset_connect_posts when those additional actions are performed(split, move, merge, extract). Maybe not for all actions. For example, I don't think you will need special treatment for split, as I assume that it will call wp_insert_post and trigger a bbp_new_topic and a bbp_new_reply actions. Bottom-line you are right, that may need more custom code, and may create inconsistencies in the database.

Assuming that you have built the view, and you want to implement a search filter where the user chooses what posts to return(replies, topics, forums). This filter cannot be generated by Toolset. It has to be built using HTML, and some custom code to alter the post_type argument of the view(underlying wp_query). https://developer.wordpress.org/reference/classes/wp_query/#post-type-parameters
Check these threads for similar cases:
- https://toolset.com/forums/topic/filter-by-post-type/#post-539185
- https://toolset.com/forums/topic/post-type-filter/#post-486216

Regarding your idea about using the built-in post_parent links that BoddyPress/bbPress use. It could be a good solution candidate, but it may need some custom code that will perform additional wp_query(ies) and modify the view's query arguments.

I am aware, this is not a straight answer to your question, but I am not sure if I fully understood it. I wonder if you can provide a sketch or a blueprint of how do you want to have the search filters. Maybe that could help me understand better what you want to achieve.

[NickC8880]

Wow, what a fantastic answer! This sort of conceptual explanation is what I tend to find lacking in the otherwise wonderful documentation. I, and surely many others, don't really understand how Toolset (or even WP) works, so we're forever looking around (or bugging support) for partial, adhoc solutions for our immediate problems.

To put it another way, typically you're giving us fish, rather than teaching us to fish. So, I very much appreciate you giving me a fishing rod here! But, rather than asking you to teach me how to use it, I will spend some time reading up on WP_Query (there appear to be endless wonderful resources on the net for this) to get a better understanding of how it works.

I'll come back with a blueprint and specific questions when I'm ready, and perhaps you could then help map out what I will need to do. To the extent that I will have many different questions about building out this entire feature, I'll open new tickets for them as it becomes necessary.

Finally, I will also forward this feedback on to management about how I think your reply/this example should serve as the basis for some developing some essential documentation on how Toolset works conceptually.

Thanks again for your help! You gave me far more than I came for! I'll leave this ticket open for now.

[Jamal]

Thank you very much for these kind words. It's always amazing and rewarding to get such feedback.

I'll set this ticket as waiting for a reply, which should keep it open for 2 weeks. And you will receive notification emails a couple of days before it gets closed by the system. Just reply here, and if it is already closed, either open a new ticket or send me an email to jamal.b(at)onthegosystems.com and I'll reopen it.

Once again, thank you for your kind words.

[NickC8880]

Thanks again for the insights about wp_query Jamal, I have been learning a lot in the past week about it and many other aspects of WP and am feeling considerably more confident not just with this task, but my project in general.

Here are some links to excellent information about WP_Query for the benefit of others who might see this ticket later (there's also some very advanced information the final 3 links that you and others might even find helpful).

• versteckter Link;
• https://code.tutsplus.com/series/mastering-wp_query--cms-818
• versteckter Link;
• https://wordpress.stackexchange.com/questions/1753/when-should-you-use-wp-query-vs-query-posts-vs-get-posts/1755
• versteckter Link;

As for my ticket, I'd just like to give an informative update on where I'm at.

Given that I already planed to use SearchWP for advanced searching and document indexing on my site, I'm now reading up on how I can integrate it with Toolset. It shouldn't be too difficult since SearchWP uses one of two mechanisms, both seemingly compatible with wp_query, for its searches (versteckter Link). It also has the ability to consider the post_parent field (versteckter Link), and moreover has an integration for bbpress that should offer a lot of important functionality, such as attributing child reply match weights to the parent topic results (versteckter Link).

So, I think I will ignore Toolset Relationships in this case and use the built-in BuddyBoss mechanisms for updating the post_parent field. It will avoid creating extra database entries for the Toolset Relationship, should reduce the query complexity and load by staying withing wp_posts, and, perhaps most importantly, will reduce the likelihood of any errors/corruption in the relationships. However, it was useful to learn a bit about how to programmatically create and change Toolset Relationships and I'll surely make use of this for other aspects of the site.

I have submitted a ticket to SearchWP to learn more about how I can build their searches as well as use some front-end filters (ideally created with a Toolset View) to modify their search Engines in order to allow the user to filter results based on Forum and select whether Topics or Replies are returned. I will wait until I figure out things from their end to ask for further help here. But I'll probably need a bit of guidance about how to display the search results object/array within a Toolset View that I can create and style with your GUI.

[Jamal]

Thank you for sharing those links about WP_Query and SearchWP. Hopefully, the SearchWP support will provide you with useful information.

Regarding the last paragraph, I'd like to note that a view will enforce a few things. For example, it will build it's own WP_Query instance. So, if you are going to programmatically perform the search using SearchWP, you will need to integrate it with the view's query.

And regarding styling the results, you will most probably use a content template. A content template, by design, is meant to display ONE post. You can use it inside the loop of a view, and it will display each post from the view's results. You can use a content template using a shortcode:

[wpv-post-body view_template="Name or slug of the view"]

https://toolset.com/documentation/programmer-reference/views/views-shortcodes/#wpv-post-body

I'll remain at your disposal for any further questions.

[NickC8880]

Thank you. I'm still working on some other things but a couple more questions for now.

Do you have any documentation or other tickets that you could point to for integrating SearchWP's results with/overriding a Toolset View's query? Or, is there another way to use Toolset's capabilities to create a custom search with filters, pagination and stylized loop results, without using a View?

Could you please elaborate on why I would use a content template in the loop of a view? I was under the impression that when using a view, I could style how each result will appear. Is it simply that if I create a content template for these results, the same template/styling could be seamlessly used in another view on the site?

[Jamal]

Sure. I'll try to answer those questions. Keep in mind that a view is meant to display a list of post, where a content template is meant to display only one post. A view does not only display a list of posts, it can query them from the database too. It also offers search and pagination. When a content template is used inside a view's loop it will display each post of the view's query results.
- https://toolset.com/glossary/view/
- https://toolset.com/glossary/template/
Content templates are not used exclusively to display single post pages, for example(versteckter Link "watson" being a post in the custom post type "members"). They can be reused inside views, archive templates or even content templates them selves.

This being said, I'll start by answering the last question why I would use a content template in the loop of a view?
The answer is to reuse the same design(also logic if you use conditions, or views inside content templates) in different views. For example, you want to have the featured image at the left, and the title, taxonomies and custom fields on the right. You can put that on a content template and reuse that content template(design) in different views.

Regarding the first question, is there another way to use Toolset's capabilities to create a custom search with filters, pagination and stylized loop results, without using a View?
No. Because the view is the core element to have search and pagination. However, you can hook into the view's processing steps and change how it will act. For example, if you can perform a SeachWP search programmatically, you can pass the results into the post__in argument of the view's query.
As an example, Nigel has used Toolset Relationship API to pass a set of results to the view's arguments https://toolset.com/forums/topic/wpv_filter_query-filter-by-post-relationship/#post-1197193
Luo is passing the products that have been ordered by the user in this example https://toolset.com/forums/topic/wpv_filter_query-not-triggered-on-search/#post-573136

Read more about the views hooks here https://toolset.com/documentation/programmer-reference/views-filters/

If SearchWP can provide search filters and display the results, you may want to a content template to style each post. Either using a shortcode like I suggested in my previous reply:

[wpv-post-body view_template="Name or slug of the view"]

Or using PHP code with the render_view_template function
https://toolset.com/documentation/programmer-reference/views-api/#render_view_template

[NickC8880]

As always, thanks very much for the thoughtful reply.

I think what you've described is what I already suspected regarding Views and Templates. I'll probably make a content template then for displaying the results as I'll probably provide a similar - but slightly different - search feature for the main forum directory and within each forum and it would be helpful to have a reusable template.

Thanks as well for the information about how to use post__in. I assume that it will not be difficult to pass SearchWP's results to it - it takes various arguments and creates a search object that will surely include a post_id array for its results. I'll finally start experimenting with it today and should be able to get something to work well enough to share with you for some polishing, if thats ok.

Two questions:
1. where/how do I use something like

[wpv-post-body view_template="Name or slug of the view"]

. Just insert a Fields and Text Block or a Shortcode Block into the View Loop?
2. Similarly, to use a function and filter (such as those included in the tickets you linked to), I just have to specify the View_ID in the 4th argument of the filter? And for the 3rd argument, I can't find any documentation for $view_settings. It generally appears to be 99, but I've also seen 30 used. Is there a link you can provide that describes this?

Thanks again for your help!

[Jamal]

1. Yes, you can put the shortcode inside a Fields&Text block. Or you can use it in a shortcode block. Or you can use the Content template block. The only difference between using the content template block, and using the content template with a shortcode is the ability to suppress filters. It is an argument that can be added, only, to the shortcode. Read more about the shortcode here https://toolset.com/documentation/programmer-reference/views/views-shortcodes/#vf-153372

2. Check the hook's documentation here https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_query
For example this:

add_filter( 'wpv_filter_query', 'my_callback_function', 99, 3 );

99 is the priority. It will depend on the use case. 3 is the number of arguments that WordPress will pass to the "my_callback_function" function. Please check this article on how WordPress offers and uses hooks https://codex.wordpress.org/Plugin_API

Of course, whatever question you have, I'll be very glad to help with it.

[NickC8880]

Thanks. Sorry, I had visited that documentation for wpv-filter-query, but I clearly misread/misunderstood it. I generally understand filter and action hooks, so it is clear now. I'll follow up later when I have something tangible to share.