Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

[resolved] Keyword search is not working

version 1.9.4 stable

Hi all,

When I tried to search based on keyword, it is only searching the user (not the ticket).

Have a look here:

Could someone help me with this please?

Thank you


  • Click Advanced Search.
    The autocomplete looks like its trying to complete the field with the email address that popped up.
  • Hi ntozier,

    Thank you for your reply. Unfortunately the search is also not working using the advanced search. I am using Apache server with PHP 5.5. Not sure if the version of the PHP that caused the problem.
  • Anyone can help me? :) Thanks
  • Just test it here, an everything is working fine.

    I also think that the auto-complete is somehow used and so the result is not as expected.
  • Hi Chefkeks,

    Thank you for your comment, it is definitely not working on my server. I have re-installed everything from scratch and still not able to search. Below is my server software:
    osTicket Versionv1.9.4 (c18eac4)
    Web Server SoftwareApache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/1.0.1e-fips mod_bwlimited/1.4
    MySQL Version5.5.40
    PHP Version5.5.15

    Installed it on my localhost and it is working so I am guessing there must be something wrong with the server software.

    So what I did now is to install the previous version v1.9.3 on my web server and interestingly the search is working well on this version. Will keep using v1.9.3 for now and hopefully there will be an update to address this in the future.
  • I'm also having same results (ie search not working). This is our first install 1.9.4 and it's never worked. If I look in ost__search table I can see all the tickets have an entry but the content column is numbers, e.g.

    H 560 Status Changed 0 6 7 14 15 19 20 24 25 27 28 34 35 37 38 42 43 47

    Is that normal? Is there a way to test the search code outside of the UI?

    If it makes any difference I'm running site on HTTPS?
  • Ok, looks like in my case the problem is related to:

    The fix is to comment out the IntlBreakIterator section. However, I now need to repopulate the ost__search table with the correct text. How do I do that?
  • Truncating the table forces IndexOldStuff to re-populate the table.
  • edited November 2014
    I have the same issue.  I'm on Rackspace cloud.

    [SELECT DISTINCT COALESCE(B1.ticket_id, B2.ticket_id, B3.ticket_id, B4.ticket_id) FROM (
                    SELECT object_type, object_id, MATCH (search.title, search.content) AGAINST ('stephen' IN BOOLEAN MODE) AS `relevance`
                    FROM `ost__search` `search`
                    WHERE MATCH (search.title, search.content) AGAINST ('stephen' IN BOOLEAN MODE)
                ) `search` LEFT JOIN (select ticket_id as ticket_id from ost_ticket
                ) B1 ON (B1.ticket_id = search.object_id and search.object_type = 'T') LEFT JOIN (select as thread_id, A1.ticket_id from ost_ticket A1
                    join ost_ticket_thread A2 on (A1.ticket_id = A2.ticket_id)
                ) B2 ON (B2.thread_id = search.object_id and search.object_type = 'H') LEFT JOIN (select as user_id, A1.ticket_id from ost_user A3
                    join ost_ticket A1 on (A1.user_id =
                ) B3 ON (B3.user_id = search.object_id and search.object_type = 'U') LEFT JOIN (select as org_id, A1.ticket_id from ost_organization A4
                    join ost_user A3 on (A3.org_id = join ost_ticket A1 on (A1.user_id =
                ) B4 ON (B4.org_id = search.object_id and search.object_type = 'O') LEFT JOIN ost_ticket A1 ON (A1.ticket_id = COALESCE(B1.ticket_id, B2.ticket_id, B3.ticket_id, B4.ticket_id)) LEFT JOIN ost_ticket_status A2 ON (A1.status_id = WHERE ((A1.staff_id=1 AND A2.state="open") OR A1.dept_id IN (1,2,3,4,6,5,7,8,9,22,11,12,13,14,15,16,17,18,19,20,21,23,24,25,26))ORDER BY `search`.`relevance` LIMIT 500]

    The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET MAX_JOIN_SIZE=# if the SELECT is okay<br />
    <br />
    ---- Backtrace ----<br />
    #0 (root)/include/mysqli.php(177): osTicket->logDBError('DB Error #1104', '[SELECT DISTINC...')<br />
    #1 (root)/include/ db_query('SELECT DISTINCT...', Object(Closure))<br />
    #2 (root)/include/ MysqlSearchBackend->find('stephen', Array, 'Ticket', Array)<br />
    #3 (root)/include/ SearchInterface->find('stephen', Array, 'Ticket')<br />
  • Hi Snow,

    Where can I find  IntlBreakIterator class to comment out? I am new to osticket. Thank you for your help.

  • Hi Snow,

    Don't worry, I found it under class.format.php under include folder. 
    Changed it to if (class_exists('IntlBreakIterator')==false)

    I have truncated the ost__search table too and it looks like the search is working.

    Similar like Christom, got an email from osticket with the error message, however it is a bit different. My error was:

    Duplicate entry 'U-5861' for key 'PRIMARY'<br /> <br />

    ---- Backtrace ----<br />

    #0 (root)/include/mysqli.php(177): osTicket->logDBError('DB Error #1062', '[INSERT INTO `o...')<br />

    #1 (root)/include/ db_query('INSERT INTO `os...')<br />

    #2 (root)/include/ MysqlSearchBackend->__index(Array)<br />

    #3 [internal function]: MysqlSearchBackend->IndexOldStuff(Array, NULL)<br />

    #4 (root)/include/class.signal.php(98): call_user_func_array(Array, Array)<br />

    #5 (root)/scp/autocron.php(58): Signal::send('cron', Array)<br />

    #6 {main}

  • I've asked the devs to take a look at this...

    But what "Duplicate entry 'U-5861' for key 'PRIMARY'" is saying is that you have a duplicate key.  Since I cannot see the rest of the error (or the query) I can't tell which table its in.

  • Hi ntozier,

    The table is below: [INSERT INTO `ost__search` (`object_type`, `object_id`, `title`, `content`)  VALUES ...

    This happened after I apply the fix suggested above (Disable int module and truncate ost__search database). Tried to upgrade to today and it looks like this problem has not been fixed.

    Thank you
  • I have upgraded to and I also still have the same problem.
  • I have upgraded to and I also still have the same problem.
    Same with me :(
  • The new upgrade: 1.9.6 fixed it all! I just upgraded to this version. No drama so far. Thank you all that have commented.
This discussion has been closed.