Home

Your premium source for custom modification services for phpBB
  logo

HomeForumsBlogMOD ManagerFAQSearchRegisterLogin

Comments May 12, 2008

Building a Better Merge Part I: Interface Ideas

Filed under: MOD Writing, phpBB — Dave Rathbun @ 12:14 pm  

One of the features missing from phpBB2 is a Merge Topic option. Forum moderators can delete, lock, split, and move topics. A locked topic can be unlocked. A moved topic can be moved back to its original location. But there is no “undo” for deleting or splitting. If there was a way to undo a “split” it would most likely be called a “merge” which - if available - would also provide a way to merge two similar topics together to combine a discussion. In the next few posts I want to talk about how I designed and wrote a MOD to address the missing merge feature in phpBB2.

Building a Merge Interface

I have reviewed a number of merge MODs available at phpbb.com over the past years, and none of them felt “right” to me. In phpBB3 the developer team released a merge feature, and even after using it I’m not sure I can describe the interface. :lol: It certainly doesn’t feel “right” to me. A search at phpbb.com and phpbbhacks.com revealed that several attempts had been made to generate a merge feature. I didn’t like any of them, so I started thinking about why that was the case.

First is that most merge features seem to assume that only two topics will be merged. It is entirely possible that there will be more than two topics that I want to merge, so my MOD has to be able to handle that.

Second, the topics to be merged are not necessarily going to be in the same forum. I would rather not have to move a topic first in order to be able to merge it.

Third, I don’t always know where the other topic is! For example, I might be reading forum X when I come across a topic that looks very familiar. In fact, I am quite certain that I saw a topic that covered nearly the exact same thing only a few minutes ago. If I could just remember where… and that takes me to the search screen, right? Oh, but I don’t want to lose my place on the other topic, so I have to either start a new window (or tab) or bookmark the topic I am currently reading before I go find the other topic.

What it really boils down to in my opinion is I need an easy way to identify (and mark in some way) two (or more) topics and then merge them. Since those two actions can be separate I decided to design my MOD interface that way. Identify topics and put them onto a merge queue, and then process the merge queue in a separate step.

Merge Interface Implementation

Ultimately that’s how the MOD ended up being released. When you click the “merge” icon on the moderator toolbar it places the topic onto a merge queue (a special table was created for this purpose). Here’s what my moderator toolbar looks like after installing this MOD (and a few others as well): Moderator Tools

The icons are (from left to right): Delete Topic, Move Topic, Lock (Unlock) Topic, Mark Topic Unsearchable (Custom MOD, Reversable), Split Topic, Merge Topic (This MOD), Schedule Topic (Custom MOD, not documented at this time), and Moderator Control Panel (link to existing modcp.php code). A moderator can click on the merge icon for as may topics as needed. Nothing actually happens until they visit the Merge Queue, pictured here:

Merge Queue Image

As you can see on this screen a moderator can select two or more topics (no limit other than page size) via checkboxes, and then select one of those topics to become the host or destination topic via a radio button.

I like this interface, even if it does require a second step. A moderator can select topics from any number of forums and put them into the merge queue. Two or more moderators can be working on a merge step at the same time; they just have to be careful to select the proper set of topics to merge on the final step. If extra topics get put into the queue there is an easy way to remove them. This MOD has been in use on my largest board for about two months so far, and no complaints have been issued. I consider that a good sign. :)

In the next post I will talk more about the database design behind these screens and show some of the SQL required to merge the topics.

4 Comments »

  1. You have some good points which I hadn’t thought of, especially making the merge queue so more than two topics may be merged. Truthfully, I hadn’t even considered more than two.

    I thought the phpBB3 version was nice, allowing you to view the forum and select the topic, then return. But your method is still better.

    Here are two questions/comments:

    - Collision detection? You say more than one moderator may have queues. What happens when two moderators try and put the same topic in a queue? My thought was to not allow more than one instance of the same topic.

    - Post ordering? Can you think of any way to order posts by either post_id or time? I suppose that’s really up to viewtopic.php, though…

    Comment by Dog Cow — May 23, 2008 @ 11:57 am

  2. There is only one merge queue. If moderator “A” puts a topic on the queue and then moderator “B” tries to do the same topic they’re going to see a message along the lines of “This topic has already been marked for merging” or something like that. I don’t remember the exact phrase.

    There is also an option to remove something from the queue if it was added accidentally.

    The post order is a bit problematic, as two merged topics will quite likely end up with posts intermixed. I don’t have any magic solutions for that. :) I decided that the standard post ordering was just fine and left it at that.

    Comment by Dave Rathbun — May 27, 2008 @ 9:13 am

  3. OK, well you have confirmed my assumptions (sometimes it can be foolish to assume!)

    Well then, what about a way to sort by moderator. Let’s imagine, a board with thousands of moderators, thousands of merges/splits every week. The switchboard is lit up 24/7, hundreds of transactions. Not to mention users are still posting 1,000 posts per minute.

    A thought I had last whenever:

    - The topic should be locked when it is being split or merged. Then, as soon as the merge or split or complete, the topic is unlocked. Generally, this lock/unlock process should take just a second with the main action. Why? There’s no other way to stop users from posting while or in-between the split/merge action.

    This does NOT mean, lock the topic as soon as it hits the queue, it means locking the topic for the duration of the action.

    - Point # 2: A big queue of topics as mentioned earlier, many from different moderators. Perhaps it would be user-friendlier to sort the topics in to “categories” like on the forum index, execpt for these categories would be the moderator who added the topic; the “forum” for these categories would be the topic itself.

    Also, if there are not a lot of topics in the queue, a flat list of topics, ordered by last post or whatever, would also be available.

    Comment by DogCow — May 27, 2008 @ 4:31 pm

  4. uh-oh… I think your spam filter deleted my comment yesterday. :-0

    OK, here was the basic gist of my comment (which was much longer):

    1.) Lock the topic(s) while they’re being merged or split. This is in case users decide to post while the action is happening.

    2.) Perhaps and option to sort the merge queue by username, and also as a flat list ordered by date.

    Comment by Dog Cow — May 28, 2008 @ 2:41 pm

RSS feed for comments on this post.

Leave a comment

Tags allowed in comments:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Confirm submission by clicking only the marked checkbox:

 **             

Powered by WordPress