Search options (Page 1 of 6)

2008-01-12 00:35

Occurs when "All forum search" is disabled for guests and members, but administrator and moderators should be able to perform search in all forums.

Moderators and admins should always be able to search through all forums at once, search.php, line 706:

if ($pun_config['o_search_all_forums'] == '1' || $pun_user['g_id'] < PUN_GUEST)
     echo "\t\t\t\t\t\t\t".'<option value="-1">'.$lang_search['All forums'].'</option>'."\n";

But they can't since this exists on line 125 (still search.php): (well, they can, but only if all forums search is enabled for everyone)

// Search a specific forum?
$forum_sql = ($forum != -1 || ($forum == -1 && $pun_config['o_search_all_forums'] == '0')) ? ' AND t.forum_id = '.$forum : '';

Solution? Well, I did this with row 125:

// Search a specific forum?
$forum_sql = ($forum != -1 || ($forum == -1 && $pun_config['o_search_all_forums'] == '0' && $pun_user['g_id'] >= PUN_GUEST)) ? ' AND t.forum_id = '.$forum : '';

I have not spent any considerable time to 100% confirm that this is a bug, but for what I've seen and tested so far, it is.

2007-10-12 08:30

http://www.aftonbladet.se/:D

becomes:

http://www.aftonbladet.se/:D

Nothing very serious, but since it messes with the html-tags it might be something to consider taking a look at.

2006-09-03 07:01

MadHatter wrote:

lol, how is it a security issue, and why would one query (or even a whole bunch) slow the database performance down for the rest of the users. databases are highly optimized applications which are specifically designed and written to 1) have a lot of connections, and 2) look for data.

LOL at yourself. Before you have all the facts an experience of running a high traffic site (wich I actually dont know if you have, but if you did you would probably not react the way you did) you should shut up.

1) A query that takes 50 seconds to run takes a lot of cpu.
2) if you only have 1 server for database and webb all is affected when this query eats cpu.
3) say 10 searches are made, and cpu load gets to 100% for at least 5-10 minutes.

This slows down everything like hell before all queries are done...

So please, dont say anything else before you actually KNOW it... I know this for a fact, else I would have not taken this up to be an issue at all.

Edit: "Security issue" may be the wrong words, but i'ts certanely an issue!

2006-09-02 08:07

Rickard wrote:

Even though 30-40 seconds might not be a lot in the greater scheme of things, it's incredibly annoying from a user's POV.

Not only that, it's an security issue that consumes lot of server power and slows down the entire database and browsing for all users...

2006-08-31 09:21

Smartys wrote:

Err, the index can't help here for a very simple reason: you're not searching for an ID, you're searching for a word.

Then this is an bad solution. The query is straight from punbb... and is slow as hell. I guess it should not be this slow ...

I'm really hoping for mysql fulltext search in new versions... or I'll have to convert punbb myself... this does not work well at all

2006-08-30 10:57

I cant specify what index to be used either. It refuses to use the ones I ask for...

It gets better, but not good:

mysql> explain SELECT m.post_id FROM search_words AS w FORCE INDEX (PRIMARY) INNER JOIN search_matches AS m FORCE INDEX (search_matches_word_id_idx) ON m.word_id=w.id WHERE w.word LIKE '%text%';
+----+-------------+-------+------+----------------------------+----------------------------+---------+------------+--------+-------------+
| id | select_type | table | type | possible_keys              | key                        | key_len | ref        | rows   | Extra       |
+----+-------------+-------+------+----------------------------+----------------------------+---------+------------+--------+-------------+
|  1 | SIMPLE      | w     | ALL  | NULL                       | NULL                       | NULL    | NULL       | 193562 | Using where |
|  1 | SIMPLE      | m     | ref  | search_matches_word_id_idx | search_matches_word_id_idx | 3       | forum.w.id |     17 |             |
+----+-------------+-------+------+----------------------------+----------------------------+---------+------------+--------+-------------+
2 rows in set (0.00 sec)

2006-08-30 10:55

elbekko wrote:

Well, %text% is a wildcard match. It matches everything with 'text' in it

I know, but why is not index in search_matches being used suddenly?

2006-08-30 10:50

mysql> explain SELECT m.post_id FROM search_words AS w INNER JOIN search_matches AS m ON m.word_id=w.id WHERE w.word LIKE '%text%';
+----+-------------+-------+------+----------------------------+---------------------+---------+-----------------+---------+-------------+
| id | select_type | table | type | possible_keys              | key                 | key_len | ref             | rows    | Extra       |
+----+-------------+-------+------+----------------------------+---------------------+---------+-----------------+---------+-------------+
|  1 | SIMPLE      | m     | ALL  | search_matches_word_id_idx | NULL                | NULL    | NULL            | 3268634 |             |
|  1 | SIMPLE      | w     | ref  | search_words_id_idx        | search_words_id_idx | 3       | forum.m.word_id |       1 | Using where |
+----+-------------+-------+------+----------------------------+---------------------+---------+-----------------+---------+-------------+

This query takes about 30-40 seconds to run.

What could be wrong here?

other example, witch works fine:

mysql> explain SELECT m.post_id FROM search_words AS w INNER JOIN search_matches AS m ON m.word_id=w.id WHERE w.word LIKE 'text';
+----+-------------+-------+-------+-----------------------------+----------------------------+---------+------------+------+-------------+
| id | select_type | table | type  | possible_keys               | key                        | key_len | ref        | rows | Extra       |
+----+-------------+-------+-------+-----------------------------+----------------------------+---------+------------+------+-------------+
|  1 | SIMPLE      | w     | range | PRIMARY,search_words_id_idx | PRIMARY                    | 22      | NULL       |    1 | Using where |
|  1 | SIMPLE      | m     | ref   | search_matches_word_id_idx  | search_matches_word_id_idx | 3       | forum.w.id |   17 |             |
+----+-------------+-------+-------+-----------------------------+----------------------------+---------+------------+------+-------------+
2 rows in set (0.00 sec)

Notice the difference between the two "... LIKE '%text%'" and "... LIKE 'text'"

2006-07-26 18:35

jmpy, yeah, I changed that also. This is not very pretty but it works 99% of the times:

function stripBBCodeQuote($text)
{
    for ($i = 0; $i < 3; $i++)
        $text = preg_replace('#\[quote\]([^\[]*?)\[/quote\]#', '', $text);
    
    for ($i = 0; $i < 10; $i++)
        $text = preg_replace('#\[quote=([^\[]*?)\]([^\[]*?)\[/quote\]#', '', $text);

    return $text;
}

Your function is better though. With some modification I ended up with this that works perfect:

function stripBBCodeQuote($text)
{
    while ($text)
    {
        $text = preg_replace('#\[quote\]([^\[].*?)\[/quote\]#', '', $text);
        $text = preg_replace('#\[quote=([^\[].*?)\]([^\[]*?)\[/quote\]#', '', $text);
        if ($text == $old) break; else $old = $text;
    }
    return $text;
}

2006-07-26 13:10

Rickard wrote:

Well, in that case, you could just do:
$message = str_replace(array('[quote]', '[/quote]
'), '', $message);
Edit: Hmm, it appears the PunBB pre-parser inserts a linebreak in the middle of the code block above. Odd.

i don't believe thats removes the text within the actual quote.

[quote=nisse][quote=anders]Andres wrote this[/quote]
Nisse wrote this.[/quote]
I wrote this.

The function should return "I wrote this." only.

2006-07-26 13:04

Rickard wrote:

I believe you'll have to loop it. Something along the lines of while(preg_replace...

A while would not work since $text also contains the last message of the post, and is never "null". I believe it's like that anyway... What I want to do is to strip all quotes of a post, and only have the actual post left.

2006-07-26 12:06

I have this wich ereases a single quote, and it works fine for a singel quote like this:

$text = "[quote]asdf[/quote]
";

$text = preg_replace('#\[quote\]([^\[]*?)\[/quote\]#', '', $text);
$text = preg_replace('#\[quote=([^\[]*?)\](.*?)\[/quote\]#', '', $text);

echo $quote; // gives nothing...(works)

But it does not work for a quote "tree" like this:

$text = [quote][quote]asdf[/quote]
asdf[/quote]
$text = preg_replace('#\[quote\]([^\[]*?)\[/quote\]#', '', $text);
$text = preg_replace('#\[quote=([^\[]*?)\](.*?)\[/quote\]#', '', $text);

echo $quote; // This time it displays "[quote]asdf[/quote]
".

2006-06-30 09:34

http://punbb.org/docs/dev.html#integration

2006-06-29 08:43

mysql> select count(*) from search_matches;
+----------+
| count(*) |
+----------+
|  2601088 |
+----------+
1 row in set (0.00 sec)

Is it really supposed to be like this? Rickard?

2006-05-18 17:03

mysql> SELECT m.post_id FROM search_words AS w IGNORE INDEX (search_words_id_idx) INNER JOIN search_matches AS m ON m.word_id = w.id WHERE w.word LIKE '%vadgadgag%';
Empty set (0.06 sec)

mysql> explain SELECT m.post_id FROM search_words AS w IGNORE INDEX (search_words_id_idx) INNER JOIN search_matches AS m ON m.word_id = w.id WHERE w.word LIKE '%vadgadgag%';
+----+-------------+-------+------+----------------------------+----------------------------+---------+------------+--------+-------------+
| id | select_type | table | type | possible_keys              | key                        | key_len | ref        | rows   | Extra       |
+----+-------------+-------+------+----------------------------+----------------------------+---------+------------+--------+-------------+
|  1 | SIMPLE      | w     | ALL  | NULL                       | NULL                       | NULL    | NULL       | 159117 | Using where |
|  1 | SIMPLE      | m     | ref  | search_matches_word_id_idx | search_matches_word_id_idx | 3       | forum.w.id |     14 |             |
+----+-------------+-------+------+----------------------------+----------------------------+---------+------------+--------+-------------+
2 rows in set (0.01 sec)

This, with some modification in the query to ignore a index is fast (on the fast server)...

I have not examined how the search function in punbb actually works, but this does it for that type of search query anyway...

Rickard? Any explenation to this, and is it "safe" to enter this in the code to ignore this index?

2006-05-18 16:57

mysql> SELECT m.post_id FROM search_words AS w INNER JOIN search_matches AS m ON m.word_id = w.id WHERE w.word LIKE '%vadgaadgag%';
Empty set (0.20 sec)

mysql> explain SELECT m.post_id FROM search_words AS w INNER JOIN search_matches AS m ON m.word_id = w.id WHERE w.word LIKE '%vadgaadgag%';
+----+-------------+-------+------+----------------------------+----------------------------+---------+------------+--------+-------------+
| id | select_type | table | type | possible_keys              | key                        | key_len | ref        | rows   | Extra       |
+----+-------------+-------+------+----------------------------+----------------------------+---------+------------+--------+-------------+
| 1  | SIMPLE      | w     | ALL  | search_words_id_idx        |                            |         |            | 133758 | Using where |
| 1  | SIMPLE      | m     | ref  | search_matches_word_id_idx | search_matches_word_id_idx | 3       | forum.w.id | 12     |             |
+----+-------------+-------+------+----------------------------+----------------------------+---------+------------+--------+-------------+
2 rows in set (0.01 sec)

This is run on a old dev. server im using, only about 30 000 less posts in that database. Here it's fast... how come?

Notice and compare the number of examined rows in the both examples..

edit: ah, different indexes are used here... I'll look into that.

2006-05-18 16:49

mysql> SELECT m.post_id FROM search_words AS w INNER JOIN search_matches AS m ON m.word_id = w.id WHERE w.word LIKE '%vadgadgag%';
Empty set (39.52 sec)

mysql> explain SELECT m.post_id FROM search_words AS w INNER JOIN search_matches AS m ON m.word_id = w.id WHERE w.word LIKE '%vadgadgag%';
+----+-------------+-------+------+----------------------------+---------------------+---------+-----------------+---------+-------------+
| id | select_type | table | type | possible_keys              | key                 | key_len | ref             | rows    | Extra       |
+----+-------------+-------+------+----------------------------+---------------------+---------+-----------------+---------+-------------+
|  1 | SIMPLE      | m     | ALL  | search_matches_word_id_idx | NULL                | NULL    | NULL            | 2190300 |             |
|  1 | SIMPLE      | w     | ref  | search_words_id_idx        | search_words_id_idx | 3       | forum.m.word_id |       1 | Using where |
+----+-------------+-------+------+----------------------------+---------------------+---------+-----------------+---------+-------------+

Its the same with only one % ... should it be this slow? The server is fast, with a lot of memory and a proper my.cnf (well, it should be anyway).

2006-03-24 20:58

When a user have a custom title, and is banned, the title is not changed to (showed as) "banned" as when user have default title.

2006-03-22 06:52

Kollade lite mer på det här nyss och hittade att "problemet" låg i extern.php, och inte search.php.

Det blir visserligen inget problem förrän man gör som jag, nämnligen att visa aktiva trådar på varje sida och varje sidvisning, och när trafiken blir intensiv kan den här queryn ta kål på servern och få loaden att gå upp i taket.

I vilket fall, en enkel lösning för mig var att lägga till:

WHERE ... AND t.last_post>".(time()-60*60*24)." ...

Om forumet är relativt aktivt kanske 24 timmar bak räcker för att alltid fylla listan över aktiva trådar, annars kan man ju alltid öka till en vecka eller så.

MVH.

2006-02-11 10:20

Elzar wrote:

It's not a bug though is it? If you are logged in why would you request a new password....

Well, people do all kind of stuff. Just becouse it's not likely or reasonable to do something you can bet that someone will do it anyway.

2006-02-09 18:43

Situation:

User requests new password (via the login page while the user is not logged in).

User logs in with old password and saves the login (cookies).

Users recieves email with new password activation link and visits the link.

Result: nothing happens. The password is not changed until the user loggs out and then visits the link.

This is confusing for many people and in my opinion users should be logged out when an valid activation link is visited.

2006-02-06 07:01

Rickard wrote:

FredrikK wrote:
Jorå.
Somehow I think she would prefer a more enthusiastic respons
I'll post a picture when I get home from work. Maybe I'll snap a few pictures of my new apartment.
By the way, my girlfriend's name is also Lina

Are you still at work?

2006-01-29 18:46

Jag har lagt märke till en query som är lite av en flaskhals i punbb. Det gäller när man listar "senast aktiva trådarna". Närmare queryn (eller motsvarande, jag har inte kollat så jättenoga nu. fattas ju lite värden här för att det ska vara just den queryn. Men i vilket fall...):

SELECT t.id, t.subject, t.last_post FROM forum.topics AS t INNER JOIN forum.forums AS f ON f.id=t.forum_id LEFT JOIN forum.forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.moved_to IS NULL AND t.closed=0 ORDER BY t.last_post DESC LIMIT 25;

Explain på den ger i mitt fall runt 7200 rows för tabellen topic.

Det känns onödigt och kan minskas ned rejält.

Mitt hastiga förslag är index på columnen last_post i tabellen topics, och sen ändra queryn till:

SELECT t.id, t.subject, t.last_post FROM forum.topics AS t INNER JOIN forum.forums AS f ON f.id=t.forum_id LEFT JOIN forum.forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE t.last_post > unix_timestamp()-<tiden för när användaren "sist var inloggad"> AND (fp.read_forum IS NULL OR fp.read_forum=1) AND t.moved_to IS NULL AND t.closed=0 ORDER BY t.last_post DESC LIMIT 25;

Skillnaden ligger i ett tillägg direkt efter WHERE.

Detta minskar antalet aktuella rader i tabellen topics dramatiskt.

Mvh Christian

2006-01-17 11:06

"Show recent posts" first page (showing 26 rows, and max per page is also set to 26).

Now we go to page 2, but there are not posts to show there. Even so there is a link to page two:

2006-01-10 18:44

CableGuy wrote:

In Admin/Options you can deselect the checkbox that makes this happen... [shrug /]

That disables it everywhere, and thats not wanted.

Search options (Page 1 of 6)

Posts found: 1 to 25 of 135

1 Topic by chrizz 2008-01-12 00:35

Topic: All forums search bug (v1.2.16) (2 replies, posted in PunBB 1.2 bug reports)

2 Topic by chrizz 2007-10-12 08:30

Topic: Link html-bug (1 replies, posted in PunBB 1.2 bug reports)

3 Reply by chrizz 2006-09-03 07:01

Re: Very slow search (query) (16 replies, posted in PunBB 1.2 troubleshooting)

4 Reply by chrizz 2006-09-02 08:07

Re: Very slow search (query) (16 replies, posted in PunBB 1.2 troubleshooting)

5 Reply by chrizz 2006-08-31 09:21

Re: Very slow search (query) (16 replies, posted in PunBB 1.2 troubleshooting)

6 Reply by chrizz 2006-08-30 10:57

Re: Very slow search (query) (16 replies, posted in PunBB 1.2 troubleshooting)

7 Reply by chrizz 2006-08-30 10:55

Re: Very slow search (query) (16 replies, posted in PunBB 1.2 troubleshooting)

8 Topic by chrizz 2006-08-30 10:50

Topic: Very slow search (query) (16 replies, posted in PunBB 1.2 troubleshooting)

9 Reply by chrizz 2006-07-26 18:35

Re: Strip (preg_match) bbcode of entire quotes, and quote on quote (9 replies, posted in Programming)

10 Reply by chrizz 2006-07-26 13:10

Re: Strip (preg_match) bbcode of entire quotes, and quote on quote (9 replies, posted in Programming)

11 Reply by chrizz 2006-07-26 13:04

Re: Strip (preg_match) bbcode of entire quotes, and quote on quote (9 replies, posted in Programming)

12 Topic by chrizz 2006-07-26 12:06

Topic: Strip (preg_match) bbcode of entire quotes, and quote on quote (9 replies, posted in Programming)

13 Reply by chrizz 2006-06-30 09:34

Re: How to get logged in user ID out of PunBB without being in it?! (4 replies, posted in PunBB 1.2 troubleshooting)

14 Topic by chrizz 2006-06-29 08:43

Topic: The table "search_matches" is huge (2 replies, posted in PunBB 1.2 troubleshooting)

15 Reply by chrizz 2006-05-18 17:03

Re: extremely slow search query (3 replies, posted in PunBB 1.2 troubleshooting)

16 Reply by chrizz 2006-05-18 16:57

Re: extremely slow search query (3 replies, posted in PunBB 1.2 troubleshooting)

17 Topic by chrizz 2006-05-18 16:49

Topic: extremely slow search query (3 replies, posted in PunBB 1.2 troubleshooting)

18 Topic by chrizz 2006-03-24 20:58

Topic: User "title" does not change to "banned" when user is banned... (3 replies, posted in PunBB 1.2 bug reports)

19 Reply by chrizz 2006-03-22 06:52

Re: Förslag till optimering av en SQL-fråga (2 replies, posted in Archive)

20 Reply by chrizz 2006-02-11 10:20

Re: New password validation (possible "bug") (3 replies, posted in Feature requests)

21 Topic by chrizz 2006-02-09 18:43

Topic: New password validation (possible "bug") (3 replies, posted in Feature requests)

22 Reply by chrizz 2006-02-06 07:01

Re: Post a picture of yourself. (23 replies, posted in General discussion)

23 Topic by chrizz 2006-01-29 18:46

Topic: Förslag till optimering av en SQL-fråga (2 replies, posted in Archive)

24 Topic by chrizz 2006-01-17 11:06

Topic: Paginate (1 replies, posted in PunBB 1.2 bug reports)

25 Reply by chrizz 2006-01-10 18:44

Re: bbc code and urls (5 replies, posted in PunBB 1.2 bug reports)

Posts found: 1 to 25 of 135