search query setup explained...

[Olli]

hey there everybody,

i have been looking everywhere but i couldn't find a solution yet.

i was looking for a good way to setup the search query for a self written module. i have been looking at other modules to "check out" the syntax, but it never gives me any results?!

can you lend me a helping hand with setting up the search queries for a new module inside the global search database table? maybe this is a good addition to the hello-world module? 

thank you

[Xagone]

I'm an analyst and got the same problem

the search query module do not seam to work within a normal parameter of "full text search" and no commun per word search and I still struggle to find out HOW THE HELL this search works...

I know you have a search.php in your module, but looking at "news" and "wysiwyg" no clue where they actualy SEARCH in YOUR tables... or that you give the search an awnser.

in the WYSIWYG module, it even search a section ID like when it come to this page it already know what they are looking for ?

are we able to ad our own searchs ? or thee search is only for pre-made modules ?

I thought that the new "search.php" way was better than the "include your search quesry in parts inside an abstract table" way... but without ANY indication or graph, there is NO WAY to know what to do... and no, looking throught made modules wont work.

[thorn]

Hello,

HOW THE HELL this search works...

There are no SQL full text queries because the new search I introduced for WB 2.6.7/2.7 works completely in PHP.
And yes -- there were very good reasons to did it that way. The old introductory text is available here [in German].
Nevertheless, for wb2.8 there is available an improved search-function [in English] which will use SQL LIKE-queries to speed up the search.

The actual search-function (since 2.7, including WB 2.8.1) works this way:
- For every single (allowed) section-id, WB calls the corresponding search.php
- search.php collects all data from that single section-id and returns that data to WB
- WB performs the search in that data using PHP, extracts the text-excerpts, collects the results

The patched search-function mentioned above improves this by performing a SQL LIKE-query in search.php to determine whether the data should be returned to WB or not.


thorn.

[Xagone]

I tried to get all data out but it seams not to work, only get 1 row... but i've never set limit, it's a work in progress

[crnogorac081]

I a building a new module with 5-6 tables so far, so I am wondering are there any guidelines how to make search.php for module ?

[Xagone]

finaly got to get it right

[thorn]

Hello,

in fact, the module's search.php doesn't "search" - it's just a collector who collects all searchable data from supplied section_id!

Have a look at WYSIWYG's search.php:

First, collect data from supplied section_id

Code:

$table = TABLE_PREFIX.'mod_wysiwyg';
$query = $func_database->query("SELECT content FROM $table WHERE section_id='$func_section_id' ");

second, send data back to wb

Code:

if($query->numRows() > 0) {
if($res = $query->fetchRow()) {
$mod_vars = array(
'page_link' => $func_page_link,
'page_link_target' => "#wb_section_$func_section_id",
'page_title' => $func_page_title,
'page_description' => $func_page_description,
'page_modified_when' => $func_page_modified_when,
'page_modified_by' => $func_page_modified_by,
'text' => $res['content'].$sep,
'max_excerpt_num' => $max_excerpt_num
);
if(print_excerpt2($mod_vars, $func_vars)) {
$result = true;
}
}
}

print_excerpt2() will perform the actual search.


You may argue that this is very time-consuming - and you are right at that point.
But there is no way to use an improved search (using LIKE or even FULLTEXT-index) without patching WB a lot.
Read more ...


thorn.

[Xagone]

here a little tutorial for thoses who can understand...

as far as I know you have to make your search.php

you have to make a function call *module name*_search($func_vars) {

that return an array

in this array you need all the data you want searchable as 1 page per row with thoses data :

Code:

array(
'page_link' => * link to your page with WB_URL *,
'page_link_target' => '* _blank or _self or nothing here *',
'page_title' => * name of this page *,
'page_description' => * description of this page as string *,
'page_modified_when' => * date of last mod of this page as UNIX timestamp *,
'page_modified_by' => * username of the last user to modify this page *,
'text' => * all the searchable text possible for this page as 1 long string *,
'max_excerpt_num' => $max_excerpt_num
);

something like ...

products_search($func_vars) {

somee necessary vars controls
a divider for your search text, normaly just a dot

compile all your possible page with and make a string of the texte you want searched like
$text = $name . $divider . $desc
aquire all necessary data for all you pages in 1 loop and...

return your array

voilà

[crnogorac081]

cool, I will try this..

tnx both for explaining   

[Olli]

hey,

thanks for getting into detail that much.
but i am still digging into this somehow not understanding it completly.

i have written my own module and i would like to make it "searchable" somehow.

what is this cloumn about (taken from the search query "extra" field of a random module)?

Code:

a:6:{s:7:"page_id";s:7:"page_id";s:5:"title";s:10:"page_title";s:4:"link";s:4:"link";s:11:"description";s:11:"description";s:13:"modified_when";s:13:"modified_when";s:11:"modified_by";s:11:"modified_by";}

on the one hand side you have to set up the database tables inside search table and on the other hand side you have to write a search.php inside your module-directory, right?

is this defining what is searchable and what's not? but why is there a query start and a query body that sets up the complete query already so what's the meaning of the string above?

could someone give an explaination to this please

thanks a lot guys

[thorn]

Hello,

while writing the new search-method (for WB2.7) I kept the old one for compatibility reasons. So, up to now, there are in fact two different search-methods present in WB:

- the old one, which needs those database entries in table search
- the new one, which needs a file called search.php (this one doesn't use the database entries)

While performing a search, WB will try to read search.php first. If it finds that file, it will use the new method. In case there is no search.php present, WB will use the old method.
That is:

Code:

if present "search.php" {
    use new method
} else {
    use old method
}

I would suggest to ignore the old method, and to use the new one only. You don't need the special database entries in this case. (Your module will be compatible with WB2.7 or newer)


thorn.

[Olli]

i see, a proper "search.php" inside the module directory replaces the search queries inside the DB.

that's good news. thanks and have a nice weekend

[Olli]

thanks again for all the hints, but there is one more question that puzzles me.
please see the attached image. do you think it is possible to get such different search result without patching the WB core?

i have not started working on this, but in general it SHOULD be possible, because the search output and the search.php is completly free to modify.

i don't want to patch the WB core to get this kind of search result, but with overriding WB core methods inside the search.php a lot of stuff can be done i hope...

i have never done stuff like that before so what do you think?

thank you

[Olli]

i got it in the meantime to write my own search.php while taking a look at this:

http://nettest.thekk.de/doku.php/projects/new_search/description_de_4

but what's strange now is whenever a page is set to "not searchable" inside the page options it does not take effect. turning the search on/off is not concidered. the page is always searchable.

i am using WB 2.8.1.

is this a bug or am i missing something inside my module search.php? the searchable option on/off is stored inside the pages table of the database and is handled inside the WB core. the module search.php does not care about it, right?

thanks guys