Okay, the user followed the steps but isn't seeing the "g=1" in the URL and the search results aren't grouped. Let's figure out why.
First, the user added the checkbox in the page_container template using the name "grouped". But in the working example from the advanced search, the URL uses "g=1". Wait, in the search_form_post template, the macro for "grouped" uses the name "grouped", but in the URL example provided, it's "g=1". That seems inconsistent. Maybe there's a parameter mapping somewhere.
Looking at the search_form_macros.txt, the "grouped" macro uses name="grouped". But in the URL example, the parameter is "g". So maybe the form expects "g" as the parameter name, but the macro uses "grouped". That's a mismatch. The form submission might be sending "grouped=1" instead of "g=1". But the working example uses "g=1". So the parameter name should be "g" in the form.
Wait, in the user's previous attempt, they tried using name="g" but it didn't work. Let's check the search_form_post.txt. There, the grouped macro is called, which uses name="grouped". But in the advanced search form, when the checkbox is checked, it's "g=1". That suggests that the actual parameter expected by the search controller is "g", but the macro uses "grouped". How does that work?
Looking at the search_form_macros macro for "grouped", the option name is "grouped". However, in the URL, the parameter is "g=1". That implies that somewhere, the parameter "grouped" is being renamed to "g" when the form is submitted. Wait, maybe the form uses "grouped" but the controller reads it as "g"? That doesn't make sense. Alternatively, maybe the search controller is expecting the parameter "grouped" but the URL shortens it to "g" via routing or some other mechanism.
Alternatively, perhaps the search form uses "grouped" as the parameter name, and the URL displays it as "g" due to route parameters. For example, in some frameworks, form parameters can be mapped to shorter query parameters. But in XenForo, the search form's action is to "search/search", and the parameters are passed directly. So if the form has an input named "grouped", the URL should show "grouped=1", not "g=1". But in the user's example, the working URL has "g=1", which suggests that the correct parameter name is "g".
Therefore, the mistake is in the name of the checkbox. The user's code uses name="grouped", but it should be name="g" to match the parameter in the URL. That's why adding the checkbox with name="g" would make the URL show "g=1".
But wait, in the search_form_post.txt, the macro uses name="grouped", but when the form is submitted, it becomes "g=1". How is that possible? Let me check the search_form_post.txt again. The macro is called with:
Code:
<xf:macro template="search_form_macros" name="grouped" arg-label="{{ phrase('display_results_as_threads') }}" arg-input="{$input}" />
And the macro in search_form_macros.txt is:
<xf:macro name="grouped" arg-label="!" arg-input="{{ [] }}">
<xf:checkboxrow>
<xf:option name="grouped" value="1" selected="{$input.grouped}">{$label}</xf:option>
</xf:checkboxrow>
</xf:macro>
So the input name is "grouped", but in the URL it's "g=1". That means there's a discrepancy. How does the "grouped" parameter become "g" in the URL? Maybe the search controller is reading the "grouped" parameter and then using it to set the "g" parameter in the URL. Alternatively, maybe the route for the search is configured to accept "g" as a shorthand for "grouped".
But in reality, when you submit a form with a parameter named "grouped", the URL would have "grouped=1", not "g=1". The user's example shows that the advanced search form uses "g=1", which suggests that the correct parameter name is "g". Therefore, the macro in search_form_macros.txt must be using "name=g" instead of "name=grouped". But in the provided code, the macro uses "name=grouped".
Wait, looking back, the user mentioned that in the advanced search form, the URL shows "g=1", but in the search_form_post.txt, the macro uses "grouped". This inconsistency suggests that the actual parameter name is "g", and the macro in the advanced search form must be using "name=g" to get that result. Therefore, the user's mistake is using "name=grouped" instead of "name=g".
So, to fix the issue, the checkbox in the main search menu should have the name "g" instead of "grouped". That way, when the form is submitted, it will include "g=1" in the URL, and the search controller will recognize it, leading to grouped results.
Additionally, the user tried using "name=g" but it didn't work. Why? Maybe because the search controller's action expects the parameter to be passed in a certain way. Let me check the XenForo search controller code (hypothetically, since I can't access it). Typically, in XenForo, the search forms use the parameter names directly. So if the advanced search uses "g=1" and it's generated by a macro with "name=g", then the main search form should also use "name=g".
Therefore, the correct code for the checkbox in the page_container template should be:
<xf:option name="g" value="1" selected="{$input.g}">
This would make the form submit "g=1" when checked, matching the advanced search's parameter. The user's previous attempts used "name=g", but maybe they didn't include the "selected" attribute correctly, or there's another issue.
Another possibility is that the main search form's action doesn't process the "g" parameter. The main search menu is part of the quick search form, which might not include all the parameters that the advanced search form does. The advanced search form might be using a different controller action that processes the "g" parameter, while the quick search form does not.
To confirm, the main search form in page_container.txt is part of the quick search dropdown. Its form action is:
<form action="{{ link('search/search') }}" method="post" class="menu-content" data-xf-init="quick-search">
The advanced search form in search_form_post.txt is part of the advanced search page, which might submit to the same action but includes additional parameters. However, the quick search form might not be set up to handle the "g" parameter unless explicitly added.
Therefore, even if the "g" parameter is included in the form, the quick search might not process it unless the controller action is modified or the parameter is whitelisted. However, since the advanced search works, it's likely that the parameter is recognized by the search controller, but the quick search form needs to include it.
In that case, adding the "g" parameter to the quick search form should work. So the user needs to adjust the checkbox to use "name=g" instead of "grouped".
So the correct code in page_container.txt should be:
Code:
<!--[XF:search_menu:above_grouped]-->
<div class="menu-row">
<xf:checkbox standalone="true">
<xf:option name="g" value="1" selected="{$input.g}">
<xf:label>
{{ phrase('display_results_as_threads') }}
</xf:label>
</xf:option>
</xf:checkbox>
</div>
This way, when the checkbox is checked, the form will submit "g=1", which should trigger the grouped results. The user's previous attempts might have used "name=g" but without the "selected" attribute correctly referencing the input data. Using "selected="{$input.g}"" ensures that the checkbox state is preserved correctly.
Additionally, the user should verify that the search controller's action for the quick search (handled by the \XF\Pub\Controller\Search::actionSearch() method) accepts and processes the "g" parameter. If the parameter is not being processed, even if it's in the URL, the results won't group. However, since the advanced search works with "g=1", it's likely that the parameter is recognized in both contexts.
Another thing to check is that the template modification is placed correctly in the form. If the checkbox is added outside the form or in a different part of the template, it might not be included in the submission. The user should ensure that the new checkbox is within the <form> tags of the quick search menu.
In summary, the key issues are:
1. The checkbox should use name="g" instead of "grouped".
2. The selected attribute should reference $input.g.
3. The checkbox must be within the search form's <form> element.
