Ideas for "bumping up" posts in a file-based commenting system.

Question

Hi there,

I'm working on a file based commenting system with in-line comments (only 1 level). Despite being a newby I've managed to create a system in which users are able to add new comments and use @[NUMBER] to add their reply below another comment.

My file and folder structure looks like this:

/threads/
         1/
            1.txt
            2.txt
            3.txt

         2/ 
            1.txt
         3/
            1.txt
            2.txt
            3.txt
            4.txt

The folder in threads has the thread number (used to make a reply) for its name and 1.txt contains the contents of the "mother" post. Every post higher than 1 is a reply.

So I could show the threads in the order which they have been made or show them upside down, but they'll be stuck in that order (I'm using a loop to find folders and then increase or decrease the folder number). Does anybody have any ideas on how I can make threads which get replies to the top of the list?

I thought of an order.txt file which has the thread numbers in a certain order and when a reply gets made to thread X the script should put X at the top of that list (or bottom, easy to inverse).

Suggestions are very much appreciated!

Answer 1

Stick a file in each folder (1, 2, 3, etc...) that contains a line with the time that the thread was last updated (could be when it was posted if it has no replies or the time of the last reply). When it's time to display each thread, look at the time in that file and slot it into the correct position when displayed.

The reason I'd do this over creating an order.txt file is that a single file is:

1. Easily corrupted, meaning that you'd lose ALL ordering info.
2. It is inefficient to read/rewrite a large file everytime a post is added

You can also stick other data you might want into this text file in each folder. It's kind of like how Windows stores thumbnails in a thumbs.db file for each folder.

Answer 2

Well, while I don't agree with the wisdom of doing it this particular way, the order text file seems fine enough granted depending how often your updating your threads there may be read/write lock issues.

Another option is to check the modified time for the folders and/or posts. http://php.net/manual/en/function.filemtime.php i believe would be an appropriate function.

In reference to sorting you'd need to use a sorting function. The best ideas i can come up with is when creating your array convert the modified time to a unix timestamp and use that as the array index. May need to invert the array after to show newest first but i would think that would work. I'd suggest using the mktime function in conjunction to produce a nicely formatted date/time and then use that for the index.

An alternative is storing an array within array and doing something like this:

$threadArray = array(
   array("thread" => "1", "timemodified" => "12703048849"),
   array("thread" => "2", "timemodified" => "12703048842"),
   array("thread" => "3", "timemodified" => "12703045349"),
   array("thread" => "4", "timemodified" => "12703021449"),
);

function sortByTime($a, $b)
{
  return strnatcmp($a['timemodified'], $b['timemodified']);
}

# sort
usort($threadArray, 'sortByTime');

Answer 3

Pretty similar to box9, but with a different approach.
In each thread folder, make a file, let's say - random.timestamp.txt ($file = 'random.'.time().'.txt';).
Whenever there are changes within the thread, you rename this file with the new timestamp. When you're displaying threads, fetch each threads timestamp file and align them as you wish (DESC / ASC). Something like that..

Answer 4

I'll probably get down voted for this, but if you're not going for a relational database here, why not make the order information part of the file/folder name? So you could order by metadata that is contained as part of the file/folder name scheme (as you have started to do here) your threads directory would contain a 1_2/ (first thread, second order) 2_1/ (second thread, most recent), 3_0/ (third thread, sticky <--please forgive the feature creep) This would allow you to use the split function to get relevant metadata from the file names.

Final folder structures would vary and change on update, but might look something like this in a snapshot:

/threads/ 
          1_2/
               1.txt
               2.txt
          2_3/
               1.txt
               2.txt
               3.txt
          3_1/ 
               1.txt
               2.txt