lie2815 wrote:

What did you do before whatever happened that bothers you now?
Where is the website located?

I was going to put up a test site to demonstrate it, but I think I found the problem. You don't connect to the hook fn_qr_get_topic_reply_count3, which is called when a new post is made -- so a topic's num_replies will be correct after a user deletes a post, but as soon as another reply is added, the num_replies is reset to the incorrect value including deleted replies.


(81 replies, posted in PunBB 1.3 troubleshooting)

Replying to this, since there's apparently no guest posting on the Trac?

SQLite should actually be the easiest, because it does not enforce type checking. The column types are basically for the benefit of anyone reading the schema -- you can put any type of data in any column. That includes storing strings of any length. See this page, under "Manifest typing" (and I suppose the "Variable-length records" bit is also relevant).

So, as far as I can tell, there shouldn't actually be any updating needed for SQLite.


(2 replies, posted in PunBB 1.3 troubleshooting)

In your hook, couldn't you just do $query['WHERE'] = '('.$query['WHERE'].') AND <your stuff>';?

Bump. It doesn't look like this has been fixed yet, has it?


(7 replies, posted in PunBB 1.3 troubleshooting)

Hey, how about you test the code (or at least check the syntax?) before you commit, eh? tongue

What do you mean "What did you do before that?"?


(15 replies, posted in PunBB 1.3 troubleshooting)

Isn't that pretty much what I suggested in the first place? tongue

Adam Atlas wrote:

by adding "$forum_id = $fid;" before "require PUN_ROOT.'footer.php';" in post.php


(15 replies, posted in PunBB 1.3 troubleshooting)

But cache_quickjump_*.php files allow the selected option to be changed at include-time. I just tried this by adding "$forum_id = $fid;" before "require PUN_ROOT.'footer.php';" in post.php, and it seemed to work fine. Any reason why that wouldn't work?

Cool, thanks.

I think admin/reindex.php might also be vulnerable to this. An attacker could try to direct an admin to admin/reindex.php?i_per_page=1&i_start_at=1&i_empty_index=1 -- this would empty the search_matches and search_words tables, and wouldn't repopulate them with more than one post (assuming the attacker uses an [img] or somesuch, in which case the browser obviously wouldn't follow the window.location=... thing). But maybe I'm missing something about how reindex.php works (I hope I am tongue).

Perhaps these actions should get CSRF tokens, as with logout and some of the moderator tools? Currently someone could trick other users into performing such actions by embedding them in [img] tags, for instance. It's not exactly a security vulnerability, but it would certainly be a nuisance, and there are unfortunately a great deal of people who go out of their way to be nuisances on forums.


(151 replies, posted in PunBB 1.3 extensions)

Herbivor wrote:

And a hook before "@natcasesort($url_schemes);" in admin/options.php to add new method of URL Rewriting Scheme ?
For example :

$url_schemes[] = 'Method.php';

Maybe aop_add_url_scheme ?

You just need to put your URL rewrite scheme PHP file in include/url. It'll be added automatically.


(3 replies, posted in PunBB 1.3 troubleshooting)

1. Maybe there could be an option to use BBCode to format the rules page?


(34 replies, posted in PunBB 1.3 extensions)

lie2815 wrote:

Ooh, that's not good, with 1.3, too?


Ah, alright. It turns out the two "replace with" rules just need to be in the reverse order. smile Sorry 'bout that (and thanks for letting me know). I edited the post.

Thanks for the tip. Unfortunately, I don't have access to IE6 right now (I'm on a Mac, and my Parallels environment is having problems), but once I do, I'll work out a fix as soon as possible.

Well. I've been using PunBB 1.3 quite successfully on a rather active forum, and I've written some extensions for it. 'Tis time to start sharing them.

A very basic extension which makes it easy to install JQuery and to access it from other extensions.

Thanks to PunBB 1.3's $tracked_topics, once you read a topic marked as having unread posts, it will no longer appear unread for the rest of the session. This extension takes it a bit further -- it clears the read marker as soon as you click the link to the associated topic, instead of waiting until the next time you reload the listing. Requires JQuery

Purely as a matter of personal taste, I happen to hate the "File-based" and "Folder-based" (and "fancy" variations thereof) URL schemes. So I made my own, based not on comparison to files or folders, but to LOVE! (*shrug* I couldn't think of a more specific explanation. tongue Suffice it to say, I designed it with REST style in mind.) Maybe you'll like it, maybe you won't; all a matter of personal preference, of course. (To install it, you'll have to move (or symlink) the Love_based.php file into the /includes/url directory. Also, make sure MultiViews is disabled in your PunBB directory.)

Grand finale (for now): This extension provides permanent tracking of topic readness. It distinguishes between "new" topics (meaning the same as it does now -- new unread posts since last visit) and "unread" topics (ones that have had new posts since the user last actually viewed the topic (or explicitly marked all posts as read)). Any topic marked "new" will also be marked "unread" (I'm talking about CSS classes here), so you'll have to add some style so that it'll actually look like something. I edited my Oxygen_cs.css thus:

td.tcl img {
    border-color: #2B75AD #235E8C #1F537B #266799

[Replace with]
td.tcl span.unread img {
    border-color: #E6E6E6 #235E8C #1F537B #E2E2E2

td.tcl img {
    border-color: #2B75AD #235E8C #1F537B #266799

That gives unread-but-not-new topics a marker with colours halfway between the read marker and the new posts marker.

I know there are usually efficiency concerns (time and storage space) when it comes to things like this, but I've made an effort to make it as optimized as possible.

How for you to be downloading things
I'd consider all of these alpha-quality (other than jquery, since there's so little to it), and I haven't packaged them up for release, but I have Bazaar repositories for all of them. Of course, I do not recommend trying these on a live forum; I only do because I'm intimately familiar with them. smile But test them as you please.
So you can download the files from these indexes directly, or, preferably, if you have Bazaar installed, branch them (these are the branch URLs too) so you can automatically keep up with changes.

Please let me know any problems you encounter. The Internet appreciates your help. Meanwhile, in the pipeline is rearrange, an extension that will let users customize their index pages -- rearrange categories and individual forums, or hide some altogether, so each user can make their index page as subjectively useful as possible. Unfortunately, it's not in any remotely usable state yet, but I'll post it as soon as it is.


(34 replies, posted in PunBB 1.3 extensions)

I've had this problem with both.


(151 replies, posted in PunBB 1.3 extensions)

Indeed. People tend to only think about how much CPU time it might waste, but think of all the programmer and administrator time saved by the extension system! smile


(11 replies, posted in PunBB 1.3 extensions)

Until then, here's something I've found to work very well on my forum: Create a forum called "Black Hole" or somesuch, and give it a description like "Don't post in here; it's just a trap for spambots." Make sure it is at the top of the Index page. The bots almost always post in the first section in which they're able to, so all the spam will end up in there and your users can ignore it. Then you can prune it (set it to prune topics ?0 days old) every once in a while.

I've had one or two spam posts in another forum since I started doing that (a few days ago), but at least a hundred in the Black Hole.


(34 replies, posted in PunBB 1.3 extensions)

That makes sense, but it didn't start happening until I installed this extension.


(151 replies, posted in PunBB 1.3 extensions)

You're right, I must admit. I did some testing, and I found that while a "($hook = get_hook(...)) ? eval($hook) : null;" statement can execute on my computer almost 2.23 million times per second, "eval(get_hook(...));" can only execute a pathetic 1.26 million times. yikes tongue

(On a trip to viewtopic.php just now, I found that 159 undefined hooks were called. By my calculations, this means one second would be wasted after 18,294 calls to viewtopic.php. My moderately-high-traffic forum got 62,083 hits to viewtopic.php last month, which means that if the modified hook code had been used at the time, viewtopic.php would have wasted approximately 3.4 CPU-seconds over the month. Is this deemed acceptable or not?)


(34 replies, posted in PunBB 1.3 extensions)

There's a bug in this (and in earlier PunBB 1.2 versions that I've observed) where sometimes, in a topic that has had posts deleted, it sometimes shows at least one page that doesn't actually exist (in the Pages: 1 ... 6 7 8 etc. navigation thing) at the end. Clicking on it takes you to a page that looks like a normal viewtopic page, except with no posts. Do you know what might be causing this?

Edit: I'm talking about the Deleted Posts Log extension, specifically. Sorry about that.


(151 replies, posted in PunBB 1.3 extensions)

In general, wouldn't it be good to keep the hook layout consistent (where applicable) between the topic-listing parts in viewforum.php, moderate.php, and search.php?

Today I'm wondering if you could add a hook in each somewhere after $pun_page['item_status'] is set but before $pun_page['item_style'] and $pun_page['item_indicator'] are generated.

Edit: By the way, why is the "($hook = get_hook(...)) ? eval($hook) : null;" boilerplate necessary? If you had get_hook return '' instead of false when there are no entries for a given hook, you could just do "eval(get_hook(...));". I think that would be good for readability.


(7 replies, posted in PunBB 1.3 extensions)

Jquery would be excellent. It's very lightweight and fast (and logically-designed), like PunBB itself.

I also really like MochiKit, but maybe that's just because I'm a Python programmer. (It makes JS feel a bit more like Python, to the extent possible.)

which is bad, because they're often the ones we need to moderate the most. smile

Index: viewtopic.php
--- viewtopic.php    (revision 1540)
+++ viewtopic.php    (working copy)
@@ -342,20 +347,23 @@
     // Generate author information
-    if ($cur_post['poster_id'] > 1 && $pun_config['o_show_user_info'] == '1')
+    if ($pun_config['o_show_user_info'] == '1')
-        if ($cur_post['location'] != '')
-        {
-            if ($pun_config['o_censoring'] == '1')
-                $cur_post['location'] = censor_words($cur_post['location']);
+        if ($cur_post['poster_id'] > 1)
+        {
+            if ($cur_post['location'] != '')
+            {
+                if ($pun_config['o_censoring'] == '1')
+                    $cur_post['location'] = censor_words($cur_post['location']);
-            $pun_page['user_info'][] = '<li><span><strong>'.$lang_topic['From'].'</strong> '.pun_htmlencode($cur_post['location']).'</span></li>';
-        }
+                $pun_page['user_info'][] = '<li><span><strong>'.$lang_topic['From'].'</strong> '.pun_htmlencode($cur_post['location']).'</span></li>';
+            }
-        $pun_page['user_info'][] = '<li><span><strong>'.$lang_topic['Registered'].'</strong> '.format_time($cur_post['registered'], true).'</span></li>';
+            $pun_page['user_info'][] = '<li><span><strong>'.$lang_topic['Registered'].'</strong> '.format_time($cur_post['registered'], true).'</span></li>';
-        if ($pun_config['o_show_post_count'] == '1' || $pun_user['is_admmod'])
-            $pun_page['user_info'][] = '<li><span><strong>'.$lang_topic['Posts'].'</strong> '.$cur_post['num_posts'].'</span></li>';
+            if ($pun_config['o_show_post_count'] == '1' || $pun_user['is_admmod'])
+                $pun_page['user_info'][] = '<li><span><strong>'.$lang_topic['Posts'].'</strong> '.$cur_post['num_posts'].'</span></li>';
+        }
         if ($pun_user['is_admmod'])