cheesegrits
Support Gopher
OK, we're on Skype now ... I'm logged in to your site, and testing.
-- hugh
-- hugh
-
New Commercial Services Section
We have now opened a commercial services section here on the forum for registered users. If you have a Fabrik project that you wish to have someone work on for you, post it under Help Wanted. If you are an application developer and wish to earn some money helping others, post your details under Fabrik Application Developers.
Both of these are unmoderated. It will be up to both parties to work out the details and come to an agreement.
-
Joomla 5.1
For running J!5.1 you must https://fabrikar.com/forums/index.php?wiki/update-from-github/ or include the new file manually https://fabrikar.com/forums/index.php?threads/joomla-5-1-and-fabrik-cannot-find-files-error.54473/post-285151 See also Announcements
Search by filter error
- Thread starter dimoss
- Start date
cheesegrits
Support Gopher
OK, I've narrowed it down, unfortunately it's in a somewhat disputed area of code, where me and Rob are going back and forth on a few lines of code. Around line 3872 in the main element model, in getFilterHiddenFields() ...
In the above, I've re-commented out Rob's re-un-commenting out of his commented out ... oh, I don't know ... anyway, I've "fixed" it on your site with the above code change. But that's not a fix, as obviously Rob found a case that my original fix broke ... so I need to work out a fix that fixes your issue, without breaking Rob's issue ...
Anyway ... if you update your site again before I get this resolved, you'll need to re-apply the above change in ./components/com_fabrik/models/element.php.
-- hugh
Code:
/**
* $$$ hugh - these two lines are preventing the "exact match" setting on an element filter working,
* as we always end up with an = condition, so exact match No nev er works. I've "fixed" it by just using
* the element's getFilterCondition(), but I don't know what side effects this might have.
* So BOLO for filtering oddities!
*
* $condition = JArrayHelper::getValue($filters, 'condition', array());
* $condition = JArrayHelper::getValue($condition, $counter, $this->getFilterCondition());
*/
// Rob - reverting Hugh's comment. Its not right
$condition = $this->getFilterCondition();
/**
* If no post/querystring condition has been set use the getFilterCondition()
* If we don't do that then a querystring url on foo>5 gets munged to foo=5 on a page navigation
*/
//$condition = JArrayHelper::getValue($filters, 'condition', array());
//$condition = JArrayHelper::getValue($condition, $counter, $this->getFilterCondition());In the above, I've re-commented out Rob's re-un-commenting out of his commented out ... oh, I don't know ... anyway, I've "fixed" it on your site with the above code change. But that's not a fix, as obviously Rob found a case that my original fix broke ... so I need to work out a fix that fixes your issue, without breaking Rob's issue ...
Anyway ... if you update your site again before I get this resolved, you'll need to re-apply the above change in ./components/com_fabrik/models/element.php.
-- hugh
cheesegrits
Support Gopher
I'm still not entirely sure how to work round this.
rob - any suggestions?
The band aid above, by re-instating my non-fix, is really just that - a bandaid. It basically bypasses a chunk of code later on, which is where the error shows up.
The main issue seems to be that we aren't quoting the values when we build an "IN (...)" clause for a join element's filter.
Is there any performance reason, or other MySQL-ish reason, for not quoting the values of an "IN (...)" clause, i.e. removing the assumption that we are dealing with INT's?
So is IN(1,2,3) for an INT any faster than IN('1','2','3')? If not, this would seem a simpler fix than trying to determine if the key we are dealing with is numeric or string.
-- hugh
rob - any suggestions?
The band aid above, by re-instating my non-fix, is really just that - a bandaid. It basically bypasses a chunk of code later on, which is where the error shows up.
The main issue seems to be that we aren't quoting the values when we build an "IN (...)" clause for a join element's filter.
Is there any performance reason, or other MySQL-ish reason, for not quoting the values of an "IN (...)" clause, i.e. removing the assumption that we are dealing with INT's?
So is IN(1,2,3) for an INT any faster than IN('1','2','3')? If not, this would seem a simpler fix than trying to determine if the key we are dealing with is numeric or string.
-- hugh
cheesegrits
Support Gopher
Trying to get you on Skype atm.
As I said in my previous post, the band aid above only "fixes" Dimo's filter problem by masking it. With my original fix, Dimo's filter uses an '=' and the value gets quotes (which I think is what it should do, iirc he has exact match and dropdown, which should result in a straight up = condition). Without my (commented out) fix, it uses an "IN" and doesn't quote the value, which blows up.
Rather than jump in an start quoting everything in that IN() code, I wanted to check with you if there's a reason we don't just quote all values we use in IN() clauses, given that numbers will match with or without quotes, so it would seem to be like it doesn't really matter. So I'm asking if there is a reason we don't just quote everything.
-- hugh
As I said in my previous post, the band aid above only "fixes" Dimo's filter problem by masking it. With my original fix, Dimo's filter uses an '=' and the value gets quotes (which I think is what it should do, iirc he has exact match and dropdown, which should result in a straight up = condition). Without my (commented out) fix, it uses an "IN" and doesn't quote the value, which blows up.
Rather than jump in an start quoting everything in that IN() code, I wanted to check with you if there's a reason we don't just quote all values we use in IN() clauses, given that numbers will match with or without quotes, so it would seem to be like it doesn't really matter. So I'm asking if there is a reason we don't just quote everything.
-- hugh
rob
Administrator
thi sis what Hugh said to me:
"I've tried several times to replicate that issue, can't.
[00:18:46] Hugh Messenger: So ... any objection if I just go ahead and quote all FK values when building conditions?
[00:19:13] Hugh Messenger: AND (foo.bar IN ('1', '2', '3'))
[00:20:11] Hugh Messenger: there's an asusmption somewhere int eh code somewhere about integer FK's, but I can't seem to track down what causes it."
I said I don't have an issue with tat - so I guess he'll be working on that today
"I've tried several times to replicate that issue, can't.
[00:18:46] Hugh Messenger: So ... any objection if I just go ahead and quote all FK values when building conditions?
[00:19:13] Hugh Messenger: AND (foo.bar IN ('1', '2', '3'))
[00:20:11] Hugh Messenger: there's an asusmption somewhere int eh code somewhere about integer FK's, but I can't seem to track down what causes it."
I said I don't have an issue with tat - so I guess he'll be working on that today
cheesegrits
Support Gopher
Hey Dimo,
I may or may not have fixed this.
But as I've never been able to actually replicate your issue, I don't know if I've fixed the right bit of code, and I don't want to commit anything till I've tested something that it actually has an effect on.
Can you find my on Skype, and we'll run some tests on your site, so you can tell me for sure if it's fixed.
-- hugh
I may or may not have fixed this.
But as I've never been able to actually replicate your issue, I don't know if I've fixed the right bit of code, and I don't want to commit anything till I've tested something that it actually has an effect on.
Can you find my on Skype, and we'll run some tests on your site, so you can tell me for sure if it's fixed.
-- hugh