Search options (Page 22 of 354)

Correct. We have to think long and hard on where to position the hook calls. I'll probably start a topic asking people to suggest places to put hook calls.

You use a proxy to view your own site?

I'm using dojo for a non-PunBB related project and it's been great so far. It's not quite what your looking for though (it's huge ).

As much as I'm a fan of the "do it yourself instead of using some bloated framework" approach, you could have a look at one of the lighter framworks. For example Prototype.

Edit: Nevermind I just saw your new post.

If you get a blank page, that probably means you didn't edit the cache file properly. Try setting o_additional_navlinks to NULL. It should looks something like this:

...
'o_quickjump' => '1',
'o_gzip' => '0',
'o_additional_navlinks' => NULL,
'o_report_method' => '0',
'o_regs_report' => '0',
...

Updated. Sorry for the delay.

Thanks a lot for the donation!

In order for those to line up properly, you would have to use the exact same font and font size as PunBB does in posts.

It's not quite that simple. With your suggested change, you'll end up on the last page if you don't supply the script with a page number.

Chepra: Insert $pun_config['o_base_url'] and you should be fine. Don't forget to add $pun_config to the globals list in the do_smilies() function.

elbekko: They won't be updated to use PUN_ROOT. They will be prefixed with o_base_url though. PUN_ROOT won't make sense because PUN_ROOT is the relative path on the actual server and might not match the relative path in the URL. These problems arise primarily when using "fancy URLs".

Edit: http://dev.punbb.org/changeset/540

Enable DEBUG mode and try again. Then post the full error message.

chrizz: There's no faster way to search a large table of words (that I know of) unless we switch to MySQL's built-in fulltext indexing. The reason %text% is a lot slower than text% is that the latter assumes the word must start with text. If we search for %text%, MySQL has to read every byte of every word (or at least until the search pattern can't fit).

What you could do is strip out some more noise words from your index. That might speed up the query a bit. Run the following query:

SELECT sw.word, COUNT(sm.post_id) AS hits
FROM search_words AS sw
INNER JOIN search_matches AS sm ON sw.id = sm.word_id
GROUP BY sw.id
ORDER BY hits DESC LIMIT 50

That'll list the top 50 most frequent words used in your forum. I'm sure at least 20 of those words can be added to stopwords.txt in your language pack. Then just rebuild your search index.