I sent him an email through the board last week about a security vulnerability, and he hasn't responded yet. His last post on the board was over half a year ago: 2007-06-27 22:47:12

You need to learn about variable scoping in PHP. A variable like $db declared outside a function isn't available (by default) inside the function.

The fix is to do this:

function get_mods($fid)
    $db = $GLOBALS['db'];
    $result = $db->query('SELECT moderators FROM '.$db->prefix.'forums WHERE id = '.$fid) or die();

They're stored in serialized form in the moderators column in the forums table.
The code in index.php to unserialize is:

$mods_array = unserialize($cur_forum['moderators']);
while (list($mod_username, $mod_id) = @each($mods_array))


(51 replies, posted in PunBB 1.2 discussion)

Mostly 5.0.xs - one or two 4.1.x versions (but specifically 4.1 rather than 4.0 to get the whole utf-8 stack right) - and one 3.x which we don't speak of. tongue

Ah! That makes a lot of sense. I already was having major issues trying to reproduce mt_rand()s lack of randomness.
Thanks a lot!

Hi, we're running a large punbb forum (freshly migrated from UBB - of all places) on windows 2003 (not my choice), and the primary way for members on this forum to navigate is through the "new posts since your last visit" and "recent topics" searches. We're getting quite a few error reports however on the "Unable to insert search results". Turning on PUN_DEBUG, and randomly reloading those pages quite a few times (with clicks to topics and marking read and such - so I don't have reliable steps to reproduce) I get the following error report:

File: C:\AppServ\www\bbs\search.php
Line: 416

PunBB reported: Unable to insert search results

Database reported: Duplicate entry '1794661802' for key 1 (Errno: 1062)

key 1 is the search id, which is defined as mt_rand(1, 2147483647);
At a guess, this randomizing function is run maybe 500-1000 times an hour. And we're getting a couple of collisions per hour! This is rather insane. I don't know if the root cause is windows, or whatever, but I think it would be really good if a better unique id could be generated as the primary key for the search_cache table. (Maybe the last x digits of timestamp concatenated with a (shorter) random value to prevent a collision from the page being loaded multiple times at the exact same time?)

Seeing this by code-inspection - no idea if any functionality is actually impacted by it.

In search.php, line 705 (or thereabouts; using a moderately modified setup), there's a query which contains:

LEFT JOIN '.$db->prefix.'forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id='.$pun_user['group_id'].')

Shouldn't that $pun_user['group_id'] be $pun_user['g_id'] ?

Oh, nm. I see this is fixed already in source: http://dev.punbb.org/changeset/42

In viewtopic.php,

if ($pun_config['o_quickpost'] == '1' &&
  $is_admmod ||
  (!$pun_user['is_guest'] &&
  ($cur_topic['post_replies'] == '1' || ($cur_topic['post_replies'] == '' && $pun_user['g_post_replies'] == '1')) &&
  $cur_topic['closed'] == '0'))

should probably be

if ($pun_config['o_quickpost'] == '1' &&
  ($is_admmod ||
  (!$pun_user['is_guest'] &&
  ($cur_topic['post_replies'] == '1' || ($cur_topic['post_replies'] == '' && $pun_user['g_post_replies'] == '1')) &&
  $cur_topic['closed'] == '0')))

In other news, thanks from one (so far) very happy customer for sticking with the "simple" idea (not to mention the "readable code"). I'm still ripping out large parts of the feature set since I'm integrating with a lot of other stuff and the target audience wouldn't know what to do with 90% of this stuff, but at least with this board it's doable (I remember trying with phpbb a while ago: major suffering).
Also a suggestion to provide a HTML 4.01 strict version next to the XHTML one. It's easy enough to do a global search/replace on doctype and " />", but it would still be nice.