ForumSearch Module Breaks after bb upgrade to 2021-NotSolved

registered · Worker Joined: May 07, 2005 Posts: 129

I recently upgrade my phpbb forum in nuke version 7.6 3.1patched. After doing this I had a user come to me and complain that he could no longer search the forums with out getting the following error message:

Code:




Could not delete old search id sessions





DEBUG MODE





SQL Error : 1054 Unknown column 'search_time' in 'where clause'





DELETE FROM nuke_bbsearch_results WHERE search_time < 1151358865





Line : 668


File : search.php

I looked at the line in search.php (668) and here is what it says:

Code:




            {


               message_die(GENERAL_ERROR, 'Could not delete old search id sessions', '', __LINE__, __FILE__, $sql);


            }

The Search worked before the upgrade patch since the user used to use it almost daily...

Any Ideas ???

Blonde Moment

Not Solved...I jumped the gun...

Sells PC To Pay For Divorce Joined: Posts: 5661

i dont know why it happend to you but a lot of people/websites seem to have the same problem...
but i couldnt find a fix either.. Sad

Posted: Mon Jun 26, 2006 5:55 pm

Debating replacing the Search.php file with the old one to see what happens...

What do you think? LOL

Posted: Tue Jun 27, 2006 12:58 am

Quote:

Debating replacing the Search.php file with the old one to see what happens...

Ehh refresh my memory..

Posted: Tue Jun 27, 2006 9:10 am

If the error is in the "new search.php" file, I am debating putting the "old-before forum update search.php file back"

I am not sure this would work since the error could be in the database and not necessarily in the search.php file...Am I correct in thinking this???

For a refresher on what the problem is...LOL scroll up and re-read posts LOL

Posted: Tue Jun 27, 2006 9:49 am

well you can try......
try from your previous versions...

Posted: Tue Jun 27, 2006 9:53 am

i believe this error is fixed in the patch 3.2

just for reference try changing ur search.php

replace from line 621 to line 665
with this:

if ( !strstr($multibyte_charset, $lang['ENCODING']) )

{

$match_word = str_replace('*', '%', $split_search[$i]);

$sql = "SELECT m.post_id

FROM " . SEARCH_WORD_TABLE . " w, " . SEARCH_MATCH_TABLE . " m

WHERE w.word_text LIKE '$match_word'

AND m.word_id = w.word_id

AND w.word_common <> '1'

$search_msg_only";

}

else

{

$match_word = addslashes('%' . str_replace('*', '', $split_search[$i]) . '%');

$search_msg_only = ( $search_fields ) ? "OR post_subject LIKE '$match_word'" : '';

$sql = "SELECT post_id

FROM " . POSTS_TEXT_TABLE . "

WHERE post_text LIKE '$match_word'

$search_msg_only";

}

if ( !($result = $db->sql_query($sql)) )

{

message_die(GENERAL_ERROR, 'Could not obtain matched posts list', '', __LINE__, __FILE__, $sql);

}

Posted: Tue Jun 27, 2006 12:15 pm

Where can I find the patch 3.2 ? I've been looking for it in the downloads...must be looking in wrong places LOL

Will try your fix if I can't find the patch 3.2 1st.

Thanks!

Posted: Tue Jun 27, 2006 1:31 pm

For what it's worth, I am not seeing the problem with Raven Nuke 2.02.02 and the Forums 2.0.21. I would suggest that anyone verify they have the problem before rushing out for fixes.

I also looked at the SQL that creates the bb_search_results table in the load process of Raven Nuke and the field search_time is in there. I would suggest that your research ought to focus on why that field is not in your table. I don't know if it (the field) was created during some previous bbtonuke upgrade and maybe you missed running it?

Posted: Tue Jun 27, 2006 1:41 pm

Is this ravennuke?
Uhh I thought we were dealing with a regular nuke problem.

Just for reference you can find nuke patch version 3.2 at http://www.nukeresources.com .

Posted: Tue Jun 27, 2006 1:57 pm

True: darklord, the original problem was stated as "regular" nuke. However, despite the improvements in RN we are still dealing with a similar base set of programs and tables. I'd just suggest focusing on where that one field got "lost" because that's what seems to cause the SQL errors and it should be there.

Posted: Tue Jun 27, 2006 2:27 pm

thing is i dont have that field in my database at all and it simply doesnt call on it in my nuke.

so i have no errors.

--
-- Table structure for table `nuke_bbsearch_results`
--

TABLE `nuke_bbsearch_results` (
`search_id` int(11) unsigned NOT NULL default '0',
`session_id` varchar(32) NOT NULL default '',
`search_array` text NOT NULL,
PRIMARY KEY (`search_id`),
KEY `session_id` (`session_id`)
) TYPE=MyISAM;

Posted: Wed Jun 28, 2006 9:32 am

It is PHPNuke not raven nuke but I do use Raven's patches for PHPNuke, as of yet I do not see a new patch for PHPNuke in the downloads area.

I fixed the problem by replacing the "new search.php" with the old search.php.
My only guess is that some how my download of the update got munched...will have to redownload and try reapplying it.

For the time being the problem is fixed until I can figure out exactly how the file or files were not functioning or re-apply the upgrade.

You mentioned the patch 3.2, not I...LOL I assumed we were still talking about PHPNuke. I assume there is not yet a patch 3.2 for PHPNuke.(?)

Thanks for all the imput, I'm sure I'll be back to let you know what I screwed up or if the problem was fixed by a re-application of the upgrade.

Fkelly you may be correct with regards to the tables...that was my thinking that something is awry there, I had a look at the tables and I'm not sure what it was precisely, but even with my limited knowledge it didn't look right to me. I also had my Dad (PC Guru of the ages in my book LOL) take a look at the error, he also thinks it's a missing or eronious command in the tables.

Cheers!!

Posted: Wed Jun 28, 2006 3:57 pm

Patch 3.2 for phpnuke is available, this is what I have been talking about the whole time. There is also a phpnuke patch called 3.2B witch I believe that has had a lot of these errors fixed on it, although with patch 3.2, i cant see an error in the search function as you have reported. So I'm left to one conclusion, this must be an error that 3.1 did not address properly.

You can get 3.2 or 3.2B at www.nukeresources.com

Posted: Thu Jun 29, 2006 6:03 am

pdoobepd we both have almost the same versions running...
but its possible you missed something while upgrading..

Quote:

replacing the "new search.php" with the old search.php

that was something i recommended to try in the beginning of this topic..

Posted: Thu Jun 29, 2006 8:15 am

hitwalker wrote:

i dont know why it happend to you but a lot of people/websites seem to have the same problem...
but i couldnt find a fix either.. Sad

pdoobepd wrote:

Debating replacing the Search.php file with the old one to see what happens...

What do you think? LOL

Actually I suggested it and questioned as to if you or anyone else thought it would be OK or not...LOL Have you slept lately? lol

Step away from the pc and sleep my friend.

Thanks to All!

RavensScripts

Posted: Thu Jun 29, 2006 9:23 am

sleep ?
huh..whats that.. killing me

But i meant ..

Quote:

well you can try......
try from your previous versions...

its a bit the same,i suggest to try what you suggested...
are you following this.. killing me

Posted: Fri Jun 30, 2006 10:20 am

Topic Matter Solved ROTFL

I have redone my site with rwsRavenNuke76_v2.02.02_FULL and have plenty to keep me busy...now to find the correct upgrade for the forum when using rwsRavenNuke76_v2.02.02_FULL ...

Wish me Luck or point me in the right direction ROTFL

yes I know it's BBtoNuke I want for the upgrade of the forum ROTFL

Posted: Fri Jun 30, 2006 11:17 am

thats easy...
all upgrades are at nukeresources.com

Regular Joined: Jan 20, 2006 Posts: 84

Well I'm having the same SQL Error : 1054 Unknown column 'search_time' in 'where clause' issue and still can't figure out how to solve it. Is the solution to use an older version of search.php?

registered · Posted: Wed Jul 19, 2006 12:26 am

You've missed the upgrade script from 2.0.20

Run this in phpMyAdmin

Code:




ALTER TABLE nuke_bbsearch_results ADD COLUMN search_time int(11) DEFAULT '0' NOT NULL;