Wouldn't it be simpler to support zero as meaning no limit in the localise.php files?

I'm guessing that the different limits per language are to support those languages that require multi-byte encoding.

Yes, you're right. Having no (upper) limit or some large value (e.g. 500) is simpler as having one more thing to configure for the obvious is probably too much. I mean, user probably barely know com_search has options...

Certainly the easiest thing to do is remove the limit.

I'd also think it would be better to remove the limit than worry about
imposing a specified limit, unless there are any implications in terms of
queries being made for long strings?

Ruth

On 14 November 2014 17:18, Fotis Evangelou notifications@github.com wrote:

Yes, you're right. Having no (upper) limit or some large value (e.g. 500)
is simpler as having one more thing to configure for the obvious is
probably too much. I mean, user probably barely know com_search has
options...

Certainly the easiest thing to do is remove the limit.

Reply to this email directly or view it on GitHub
#5103 (comment).

Be like me, be Carbon free - don't print this and save a tree
IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only. If you have received
this email by mistake, please notify the sender immediately and do not
disclose the contents to anyone or make copies thereof.

I doubt there is - perhaps from a performance standpoint for large site deployments with GBs of data records (but I guess only the devs of MySQL know that) :)

If it doesn't have any performance implications I would vote for removing it too. I tried to find out why it has been added, but it seems to be in the code since forever and I could find any hints on that.

Any SQL experts in here that could provide us some help?

In the past, it has been discussed forever, it was suggested to set a high limit configurable. Various inputs in this thread from 2008 https://groups.google.com/forum/#!topic/joomlabugsquad/q7D9s1_26EA

Funny, 200 is what I modified joomlaworks.net to be :)

So, we have three proposals on the table:

1. leave the com_search code as it is, and instead the limit in the localise.php to 200: easy, fast
2. make the limit configurable and add a default of 200: cleaner solution but a a bit more complex to implement
3. remove the limit: might cause unknown sideeffects

Depending on the amount of time you can invest, I would work for either 1 or 2

I'd recommend no. 1 - PR issued in 5 secs :)

I'd go for 1 too. Does modifying the non-English localise.php files require coordination with the language teams? @infograf768

@chrisdavenport @fevangelou
I suggest to modify the method in JLanguage so that we get:

    /**
     * Returns an upper limit integer for length of search words
     *
     * @return  integer  The upper limit integer for length of search words (200 if no value was set or if default value is < 200 for a specific language).
     *
     * @since   11.1
     */
    public function getUpperLimitSearchWord()
    {
        if ($this->upperLimitSearchWordCallback !== null || $this->upperLimitSearchWordCallback < 200)
        {
            return call_user_func($this->upperLimitSearchWordCallback);
        }
        else
        {
            return 200;
        }
    }

This will not bother Translation Teams.

I have corrected the code in the above post

Or how about this (which also ensures that the upper limit if >= the lower limit):

/**
 * Returns an upper limit integer for length of search words
 *
 * @return  integer  The upper limit integer for length of search words (200 if no value was set for a specific language).
 *
 * @since   11.1
 */
public function getUpperLimitSearchWord()
{
    $bound = 200;

    // Get the language-specific upper limit if there is one.
    $upperLimit = $this->upperLimitSearchWordCallback !== null ? call_user_func($this->upperLimitSearchWordCallback) : $bound;

    // Make sure that upper limit lies within proper bounds.
    $upperLimit = max(min($upperLimit, $bound), $this->getLowerLimitSearchWord());

    return $upperLimit;
}

JM's tweak looks cleaner to my eye.

Maybe, but JM's tweak won't work. ;-)

In fact, just tested both, and both don't work...
I just did a var_dump of $upper_limit in mod_search.php and always get the language xx-XX.localise.php setting.
This is obtained in both component and module by
$upper_limit = $lang->getUpperLimitSearchWord();

Looks like we have an issue here going further. :)

OK, found out :
it should be
if ($this->upperLimitSearchWordCallback !== null && call_user_func($this->upperLimitSearchWordCallback) > 200)

And I guess, in Chris proposal
// Make sure that upper limit lies within proper bounds.
$upperLimit = max(min($upperLimit, $bound), call_user_func($this->getLowerLimitSearchWord()));

Hehe. Well use what works, but drop the else that is wrapping the return 200. It isn't needed.

Without the else, we get a null value... :)
Please test #5121

dropped the else, thanks Chris.

What I meant was change:

if (...)
{
return ...
}
else
{
return ...
}

to:

if (...)
{
return ...
}

return ...

Oh, you've already done it. Thanks. :-)

Please confirm #5121

closing this as we have a a patch