Url filtering problem in fabrik 3.8

[dimoss]

Hi,

It seems that something changed between F3.7 and F3.8 and the complex url filtering doesn't work as expected.
Below there are two identical sites in terms of data. The only difference is the Fabrik and Joomla ver.
1. http://ittfstats.alfaweb.gr/index.php?option=com_fabrik&view=list&listid=41&Itemid=156 (F3.7 & J3.7.5)
2. http://akeba.alfaweb.gr/index.php?option=com_fabrik&view=list&listid=41&Itemid=156 (F3.8 & J3.8.2)

If you try both with the same search term (103107) you will get the same results. However clicking on the number links, you will get the correct url filtering in the first case but not in the second case.

As I don't know what changed between the two versions in url filtering, I hope that the Fabrik experts can give a solution..:-

Thanks id advance.

 

[dimoss]

Continuing my first post, here is the WHERE clause which I see with fabrikdebug=1 in case you click the 2017 Total matches

1st case
http://ittfstats.alfaweb.gr/index.p..._previous][]=1&fab_matches___yr[value][]=2017

2nd case
http://akeba.alfaweb.gr/index.php?o..._previous][]=1&fab_matches___yr[value][]=2017

1st case

WHERE ( ( `fab_matches`.`player_a_id` = '103107' OR `fab_matches`.`player_b_id` = '103107' OR `fab_matches`.`player_x_id` = '103107' OR `fab_matches`.`player_y_id` = '103107' ) AND `fab_matches`.`yr` = '2017' )

2nd case

WHERE ( ( `fab_matches`.`player_a_id` = '103107' OR `fab_matches`.`player_b_id` = '103107' OR `fab_matches`.`player_x_id` = '103107' OR `fab_matches`.`player_y_id` = '103107' AND `fab_matches`.`yr` = '2017' ) )

It's obvious that the second WHERE is wrong as the 'yr' is included inside in the first parenthesis while in the first WHERE is outside as it should be!

 

[dimoss]

There is an example in the WiKi based on the above case
http://www.fabrikar.com/forums/inde...-tables/#grouping-sub-queries-another-example

Actually the WiKi example was proposed by me some time ago...but now it seems it doesn't work with F!3.8

 

[cheesegrits]

Well, it's actually the second one that looks right to me. You have:

&fab_matches___player_a_id[value][]=103107
&fab_matches___player_a_id[join][]=OR
&fab_matches___player_b_id[value][]=103107
&fab_matches___player_b_id[join][]=OR
&fab_matches___player_b_id[grouped_to_previous][]=1
&fab_matches___player_x_id[value][]=103107
&fab_matches___player_x_id[join][]=OR
&fab_matches___player_x_id[grouped_to_previous][]=1
&fab_matches___player_y_id[value][]=103107
&fab_matches___player_y_id[join][]=OR
&fab_matches___player_y_id[grouped_to_previous][]=1
&fab_matches___yr[value][]=2017

... with grouped_to_previous set to 1 on all three. Which means they'll all be in the same (..) group. The 'grouped_to_previous' says "include this condition in the same parentheses as the last condition". As you have it set for all conditions, they'll all be in the same paren group. If you set the last grouped_to_previous to 0, then the last OR should outside the ().

-- hugh

 

[dimoss]

Hi Hugh

Both links have the same conditions as you note. If you check you will see that they are identical.
However the 2nd case produces an incorrect WHERE clause as it puts the last filter fab_matches___yr inside the OR group which is wrong as it should be outside the parenthesis with AND.

With F!3.8 Github 12/10/2017 I tested and it works but with the latest Github it doesn't.

 

[dimoss]

This is the correct WHERE clause and this is produced only in F3,7 or F3.8 (Github 12/10/2017)

WHERE ( ( `fab_matches`.`player_a_id` = '103107' OR `fab_matches`.`player_b_id` = '103107' OR `fab_matches`.`player_x_id` = '103107' OR `fab_matches`.`player_y_id` = '103107' ) AND `fab_matches`.`yr` = '2017' )

The 2nd link produces this:

WHERE ( ( `fab_matches`.`player_a_id` = '103107' OR `fab_matches`.`player_b_id` = '103107' OR `fab_matches`.`player_x_id` = '103107' OR `fab_matches`.`player_y_id` = '103107' AND `fab_matches`.`yr` = '2017' ) )

which is incorrect as the last filter with AND is inside the group!

 

[cheesegrits]

Ah HAH!

It was this commit:

https://github.com/Fabrik/fabrik/co...f927ef0#diff-7bfe58b005295da10912d4a79a37f015

... where I changed an each() loop to a foreach(), because each() is deprecated in PHP 7. But, what I didn't know is that in PHP 7, foreach() does not advance the array pointer. So this line of code in that loop:

            $n = current($valueKeys);

            if ($n === false)
            {
                // End of array
                $n = -1;
            }

... wasn't working, $n was never getting set to false ... and that's how we know to do an implicit end of the grouping sequences when creating the paren groups.

Working on a solution that is PHP 5 and 7 compliant now.

-- hugh

 

[cheesegrits]

Should be fixed as of this commit:

https://github.com/Fabrik/fabrik/commit/392b5a9c18f0db583933920ad281ab0e144c7826

-- hugh

 

[dimoss]

Hi Hugh

Now it works as expected..
Thanks a lot for the fast fix!