Low Search weirdness with member groups
Hi Low, got a strange issue here.
I'm running Low Search 2.0.1 - and everything is functioning fine - except for one member groups searching abilities. When that member group searches they get a error saying that the title field is required. When I add a hidden input names title I get a blank screen.
I've tried moving members that are within the problemed group to other groups which resolves the issue. I then tried to figure out what setting in that member group would clause this error - it ended up being because the member group was not assigned to a certain channel.
The channel is a collection in low search - but it was not being searched in the form generating the query.
Any ideas?
Replies
philipzaengle 24 May 2012 21:13
Ah, the plot thickens.
Did some more digging.
Looks like for some reason the search for is pulling the wrong ACT ID. It's pointing at safecracker (id65) which would cause the title error.
For some reason when the current members member group has access to a certain channel the id the form uses is id 47 (catch search method).
See attached screenshot.
philipzaengle 24 May 2012 21:33
Also - just upgraded from 2.4 to 2.5. still no dice.
I went ahead and print_r'ed what the form method was returning. sure enough the ACT hidden field says: input type="hidden" name="ACT" value="{AID:Safecracker:submit_entry}"
But it's being set correctly on line 64
$this->EE->functions->fetch_action_id(LOW_SEARCH_CLASS_NAME, 'catch_search')
Low 25 May 2012 07:58
What the eff?
This is very weird. Like you found, the module uses the correct fetch_action_id() method, but EE returns the wrong one somehow. This might be an EE bug.
You could work around it by hard-coding the ACT in the form, but I do think this should be reported to EllisLab, 'cause by the looks of it, LS is doing nothing wrong.
philipzaengle 25 May 2012 12:17
oh, the old it's not me it's you defense. :)
Just kidding - I'l type up a bug report for EL.
Low 25 May 2012 12:19
Just wondering, does optimizing the DB make a difference at all? Probably not, but the issue is weird enough to try. :)
philipzaengle 25 May 2012 12:42
Tried -no dice.
I found where the action is being swapped out.
Line 502 of Functions.php"
print_r($data);
// -------------------------------------------
// 'form_declaration_modify_data' hook.
// - Modify the $data parameters before they are processed
// - Added EE 1.4.0
//
if ($this->EE->extensions->active_hook('form_declaration_modify_data') === TRUE)
{
$data = $this->EE->extensions->call('form_declaration_modify_data', $data);
}
//
// -------------------------------------------
print_r($data);
Returns:
Before: Array
(
[id] => form-search
[class] =>
[secure] => 1
[hidden_fields] => Array
(
[ACT] => {AID:Low_search:catch_search}
[result_page] => search
[collection] => artwork|classes|courses
[search_mode] => all
[site_id] => 1
)
[action] =>
[enctype] =>
[onsubmit] =>
)
After: Array
(
[id] => form-search
[class] =>
[secure] => 1
[hidden_fields] => Array
(
[ACT] => {AID:Safecracker:submit_entry}
[result_page] => search
[collection] => artwork|classes|courses
[search_mode] => all
[site_id] => 1
[allow_comments] => y
)
[action] =>
[enctype] =>
[onsubmit] =>
Low 25 May 2012 12:45
Right. So, which extensions are using that hook?
philipzaengle 25 May 2012 12:54
Just SafeCracker
Low 25 May 2012 12:59
And do you have a SafeCracker form in the same template / page?
philipzaengle 25 May 2012 13:04
Yep :)
Low 25 May 2012 13:05
If you remove that, for testing purposes, does that solve the issue?
philipzaengle 25 May 2012 13:10
Yes - it seems to. For now I'll just hardcode that ACT var ({AID:Low_search:catch_search}) and submit a bug report.
Low 25 May 2012 13:19
Yep, definitely SafeCracker messing things up here.
Gonna mark this "not a problem" tho it definitely is.
To make sure it's a 1st party issue, you could try and put a native search form where the LS form is, and see if the ACT value still points to SafeCracker.