Erratic search

[yellowled]

In my new blog template, I moved the search form to the archives page.

Since then (I assume since then since there's no indicator for other reasons), search is behaving quite erratic. It doesn't respect the pagination (which should be one entry per page) and the number of search results don't match the number of emitted entries as results, but only for some queries.

Probably better illustrated with examples:

"jQuery" as a search query works as expected, "Webdesign" does not.

I don't even have an idea where to start debugging this. Anyone?

YL

[garvinhicking]

Hi!

The search handler is executed through include/genpage.inc.php, the "search" action:

Code: Select all

        case 'search':
            $r = serendipity_searchEntries($serendipity['GET']['searchTerm']);

So this calls the serendipity_SearchEntries() function found in include/functions_entries.inc.php.

To see what's-a-happenin, you can edit that file and check out the SQL code that's generated.

At the end of the function you see this:

Code: Select all

 $search =& serendipity_db_query($querystring);

Maybe the =& is already a problem and "disturbs" your PHP memory. Try to remove the "&" and see if that changes things.

Else, below the query do an "echo $querystring" so that we can get the actual SQL code that's created for your search. This should help to see if the query itself looks proper.

You could execute the exact query in phpmyadmin to see if that yields the same "wrong" results.

Another thing that could be interfering is a patch that I believe onli did to the extension of the query in case too few search results were found. I see a hardcoded "< 4" in there, maybe if your pagination has less than 5 items per page, this could exactly be your trouble. In that case we'd need to patched that function and ask why there's a hardcoded 4 in there.

Regards,
Garvin

[yellowled]

Maybe the =& is already a problem and "disturbs" your PHP memory. Try to remove the "&" and see if that changes things.

Nope, doesn't change anything.

Else, below the query do an "echo $querystring" so that we can get the actual SQL code that's created for your search. This should help to see if the query itself looks proper.

Code: Select all

SELECT e.id, e.authorid, a.realname AS author, e.allow_comments, e.moderate_comments, a.email, e.timestamp, e.comments, e.title, e.body, e.extended, e.trackbacks, e.exflag, e.isdraft, e.last_modified, a.username AS loginname FROM serendipity_entries e LEFT JOIN serendipity_authors a ON e.authorid = a.authorid LEFT JOIN serendipity_entrycat ec ON e.id = ec.entryid LEFT JOIN serendipity_category c ON ec.categoryid = c.categoryid LEFT JOIN serendipity_authorgroups AS acl_a ON acl_a.authorid = 0 LEFT JOIN serendipity_access AS acl_acc ON ( acl_acc.artifact_mode = 'read' AND acl_acc.artifact_type = 'category' AND acl_acc.artifact_id = c.categoryid ) WHERE (MATCH(title,body,extended) AGAINST('Webdesign')) AND isdraft = 'false' AND timestamp <= 1340028000 AND ( c.categoryid IS NULL OR ( acl_acc.groupid = 0) OR ( acl_acc.artifact_id IS NULL ) ) GROUP BY e.id ORDER BY timestamp DESC LIMIT 1SELECT e.id, e.authorid, a.realname AS author, e.allow_comments, e.moderate_comments, a.email, e.timestamp, e.comments, e.title, e.body, e.extended, e.trackbacks, e.exflag, e.isdraft, e.last_modified, a.username AS loginname FROM serendipity_entries e LEFT JOIN serendipity_authors a ON e.authorid = a.authorid LEFT JOIN serendipity_entrycat ec ON e.id = ec.entryid LEFT JOIN serendipity_category c ON ec.categoryid = c.categoryid LEFT JOIN serendipity_authorgroups AS acl_a ON acl_a.authorid = 0 LEFT JOIN serendipity_access AS acl_acc ON ( acl_acc.artifact_mode = 'read' AND acl_acc.artifact_type = 'category' AND acl_acc.artifact_id = c.categoryid ) WHERE (MATCH(title,body,extended) AGAINST('Webdesign*' IN BOOLEAN MODE)) AND isdraft = 'false' AND timestamp <= 1340028000 AND ( c.categoryid IS NULL OR ( acl_acc.groupid = 0) OR ( acl_acc.artifact_id IS NULL ) ) GROUP BY e.id ORDER BY timestamp DESC LIMIT 1  

(for a "Webdesign" query, which gives back false search results)

You could execute the exact query in phpmyadmin to see if that yields the same "wrong" results.

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1SELECT e.id, e.authorid, a.realname AS author, e.allow_comments, e.moderate_com' at line 1

It's possible I used this the wrong way: I pasted the result of 'echo $querystring' in phpmyadmin (have to paste this in German, sorry) → Abfrageeditor → SQL-Befehl in der Datenbank xy – is that what I was supposed to do?

Another thing that could be interfering is a patch that I believe onli did to the extension of the query in case too few search results were found. I see a hardcoded "< 4" in there, maybe if your pagination has less than 5 items per page, this could exactly be your trouble. In that case we'd need to patched that function and ask why there's a hardcoded 4 in there.

I can easily patch stuff there if you need a guinea pig. The blog is not updated, but rsync'd frequently.

YL

[garvinhicking]

Hi!

I believe my last clue is the "proper" one, can you try the patch mentioned here:

http://board.s9y.org/viewtopic.php?f=10 ... #p10431174

[yellowled]

I believe my last clue is the "proper" one, can you try the patch mentioned here:

Patch applied, search working again. Yay! If you need more testing before committing: Just say the word.

YL

[garvinhicking]

Hi!

I'll see if Timbalu or Ian report back on the issue; if I don't hear anything in the next week, please either commit the fix to 2.0, master and 1.6 or remind me to do it. Thanks

[yellowled]

if I don't hear anything in the next week, please either commit the fix to 2.0, master and 1.6 or remind me to do it

Someone else please handle this. I'm more or less on vacation right now, I will very like forget to remind you. Thanks.

[Timbalu]

I'll see if Timbalu or Ian report back on the issue;

Are we involved at this?
The 4 does not refer to me, äh (us) ... its onlis first patch. But we also had the limitation to 3+ searchresults before we applyed the patch ...?