Search options (Page 86 of 307)

Oh, right, left join in case there is no last post data
I'm not sure why you would have to enable buffering though, unless you're running a query inside that loop (an unmodded PunBB does not)

Closed, since this was indeed a PunBB-Hosting issue

I would need to see the cookie settings to tell

config.php has the cookie settings

Link?

Guys, this is not an announcement to say "Use 1.3," it isn't done and is not for production use (and we're not accepting bug reports at this point)

Don't change the code. Is this the query you ran?:

update topics set moved_to=null where moved_to=0

I would argue that PunBB is scalable. My understanding of replication is somewhat limited, but I believe you would have one master, several slaves, make all selects come from the slaves, and all inserts/deletes/updates go to the master. I don't see any case where PunBB makes that difficult.

Deleting all posts/topics by a user: check out it's done when users are deleted by PunBB.

        // Should we delete all posts made by this user?
        if (isset($_POST['delete_posts']))
        {
            require PUN_ROOT.'include/search_idx.php';
            @set_time_limit(0);

            // Find all posts made by this user
            $result = $db->query('SELECT p.id, p.topic_id, t.forum_id FROM '.$db->prefix.'posts AS p INNER JOIN '.$db->prefix.'topics AS t ON t.id=p.topic_id INNER JOIN '.$db->prefix.'forums AS f ON f.id=t.forum_id WHERE p.poster_id='.$id) or error('Unable to fetch posts', __FILE__, __LINE__, $db->error());
            if ($db->num_rows($result))
            {
                while ($cur_post = $db->fetch_assoc($result))
                {
                    // Determine whether this post is the "topic post" or not
                    $result2 = $db->query('SELECT id FROM '.$db->prefix.'posts WHERE topic_id='.$cur_post['topic_id'].' ORDER BY posted LIMIT 1') or error('Unable to fetch post info', __FILE__, __LINE__, $db->error());

                    if ($db->result($result2) == $cur_post['id'])
                        delete_topic($cur_post['topic_id']);
                    else
                        delete_post($cur_post['id'], $cur_post['topic_id']);

                    update_forum($cur_post['forum_id']);
                }
            }
        }

Now, to optimize that a bit more, you can choose to run update_forum for all forums after the loop is done. And in 1.3, the query inside the loop will be unnecessary thanks to the new topics column first_post_id. However, the code is really not that difficult to understand and I think PunBB handles it quite nicely.

That's still the wrong timeframe: as Rickard said, it was early in the summer

It is for efficiency, in some cases: the cost of running the query every time the number is needed outweighs the cost of running the query once and storing the number and keeping it up to date.
In terms of user post count, there's also the fact that we don't want it to decrement automatically when a post is deleted.
In terms of poster/poster_id, what happens when Guests post? We need to store their poster name somewhere and the posts table is where we do it.

Now, if you explain a little more clearly what problems you're having with pruning, we might be able to help you

http://dev.punbb.org/browser/trunk/uplo … parser.php

As opposed to revision 93 from the 1.3 development branch, which is not what you're running and is not anywhere near the newest version.

I'm very sorry to hear that, lets see if I can address some of your concerns.

We did make the announcement public, that's why you're posting in this topic
As to why we didn't post it before now, Rickard really summed it up

It isn't all that important though, it's almost a non-story. I'll go with Rickard again:

They can add PunBB to their portfolio of work. They can develop "official" services using PunBB and make money off of that. They can develop a "premium" version (although to the best of my knowledge there are no plans for anything like that), which if done wrong by them would result in a fork by the development team.

Except the core development team is the group that writes most of the code and the group that has said it's more than willing to fork. I really don't see what your problem with that is.

Hopefully I've managed to address your issues, if you have any more points feel free to respond