I can't imagine I ripped out all of that code from the SQL, are you sure I helped you? wink

$sql = 'SELECT t.id, t.poster, t.subject, t.posted, t.last_post, t.last_post_id, t.last_poster, t.num_views, t.num_replies, t.closed, t.sticky, t.moved_to, t.question, t.rating, t.icon_topic, t.labels, p.poster_id AS last_poster_id FROM '.$db->prefix.'topics AS t INNER JOIN '.$db->prefix.'posts AS p ON (p.id=t.last_post_id) WHERE forum_id='.$id.' ORDER BY sticky DESC, '.(($cur_forum['sort_by'] == '1') ? 'posted' : 'last_post').' DESC LIMIT '.$start_from.', '.$pun_user['disp_topics'];

Try this, I just merged the two queries.

1,402

(8 replies, posted in PunBB 1.2 troubleshooting)

Aha smile
There was a bug in the code on the wiki, it used an INNER JOIN for the topics table rather than a LEFT JOIN. Fixed.

1,403

(8 replies, posted in PunBB 1.2 troubleshooting)

I'm assuming you're loading a cached copy of the page
http://wiki.punres.org/index.php?title= … oldid=1760

Again, if that doesn't work, paste your index.php so I can see the problem

1,404

(8 replies, posted in PunBB 1.2 troubleshooting)

Make sure you're looking at the current version of that wiki page, it should have no such issue.

If you're still having a problem, paste your index.php here

1,405

(8 replies, posted in PunBB 1.2 troubleshooting)

http://wiki.punres.org/Last_post%27s_su … orum_index

Mmm, lets see
viewtopic.php

FIND

result = $db->query('SELECT id FROM '.$db->prefix.'posts WHERE topic_id='.$id.' ORDER BY posted') or error('Unable to fetch post info', __FILE__, __LINE__, $db->error());

REPLACE WITH

result = $db->query('SELECT id FROM '.$db->prefix.'posts WHERE topic_id='.$id.' ORDER BY posted DESC') or error('Unable to fetch post info', __FILE__, __LINE__, $db->error());

FIND

$result = $db->query('SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM '.$db->prefix.'posts AS p INNER JOIN '.$db->prefix.'users AS u ON u.id=p.poster_id INNER JOIN '.$db->prefix.'groups AS g ON g.g_id=u.group_id LEFT JOIN '.$db->prefix.'online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id='.$id.' ORDER BY p.id LIMIT '.$start_from.','.$pun_user['disp_posts'], true) or error('Unable to fetch post info', __FILE__, __LINE__, $db->error());

REPLACE WITH

$result = $db->query('SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM '.$db->prefix.'posts AS p INNER JOIN '.$db->prefix.'users AS u ON u.id=p.poster_id INNER JOIN '.$db->prefix.'groups AS g ON g.g_id=u.group_id LEFT JOIN '.$db->prefix.'online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id='.$id.' ORDER BY p.id DESC LIMIT '.$start_from.','.$pun_user['disp_posts'], true) or error('Unable to fetch post info', __FILE__, __LINE__, $db->error());

I think that should properly reverse the view order of posts.
Out of curiosity, why would you want this? Reversing the order of posts makes the conversation much more difficult for people to read if they haven't kept up with the topic and doesn't provide much benefit (if any) for people who have tongue

Out of curiosity, why not?

$my_db = $db;
[punbb stuff]
$db = $my_db;

When you move a topic, there is a checkbox. It says "Leave redirect topic(s)." If you keep that box checked, not only is the original topic moved from Forum 1 to Forum 2 but a new topic is created in Forum 1 that redirects to the topic in its new location. It is called a redirect topic.

Moved: is for redirect topics.

http://www.modsecurity.org/
It sounds like your host is using a bad ruleset that is blocking the word board (which is odd, I've heard of some random words being blocked that made more sense than that one).

That's an issue with your server, probably mod_security. Talk to your host.

Just FYI, if you're using common.php you can use PunBB's dblayer: the connection already exists.

Which means don't include functions.php when including common.php since common.php takes care of that for you wink

You can't just include functions.php: well, you can, but since you're lacking common.php you're missing out on lots of variables. I think you should try including config.php.

The cookie set, in other words, is not the same.

$_COOKIE isn't updated until the next pageview wink

1,418

(2 replies, posted in PunBB 1.2 bug reports)

Makes sense to me smile

It should be, all that's checked to see if a user is logged in is a cookie.
And unless you modified the cookie path in config.php, I don't think there's an issue.

The mod I linked to should work

1,421

(26 replies, posted in PunBB 1.2 discussion)

I can't help you if you're just going to give 5 word answers wink
Now, as I said, if you're having trouble installing modifications, you should ask for help over at PunRes. Most modifications work perfectly fine with the current version of PunBB, as my site can attest to.

Can you compare the cookie that was set to the cookie that is set when logging into PunBB properly? Maybe that will shed some light on the problem.

1,423

(4 replies, posted in PunBB 1.2 troubleshooting)

You know, you could be seeing a bot or script of some kind that's just pulling what stylesheet it feels like.

1,424

(15 replies, posted in General discussion)

Rickard wrote:
eric235u wrote:

as a side note, a friend of mine has mentioned that he just changes the user agent for his browser to googlebot and is able to read most content without registering.

I've always wondered whether hiding content from non-bots in that way is "allowed" by the search engines. In my opinion, it should be penalized. There's nothing more annoying than googling for something and then finding that the content isn't visible unless you register or spoof your user agent.

It isn't, it's cloaking

It's the primary key, id