Using XThreads Custom Thread Field to Hold Additional Data

[RateU]

I have an idea to use XThreads Custom Thread Fields to hold additional data for a thread (I don't know how to say this correctly ).

Here is a simple example for this:
In our download forum, we will try to use a custom thread field to add "Mark This File as Downloaded" link, and hold the data of users who have marked a download thread as downloaded.

In this example, we are assuming that we already had a custom thread field with key: fupload as file uploader in our download forum.

Create Custom Thread Field:

• Title: Mark As Downloaded
• Key: dl_mad
• Applicable Forums: select our download forum
• Input Field Type: Multiline Textbox
• Editable by / Required Field?: Administrator
• Capture Tab Key: No
  

That is our custom thread field that will be used to hold the data of users who have marked a download thread as downloaded.
With the custom thread field above, Administrators has an ability to view, edit or delete the data directly in a thread (using full edit).

Put {$xt_mad_link} variable in our showthread or template_prefix_showthread template.

Screenshot:
1. If users not mark a download thread as downloaded:
   

2. If users mark a download thread as downloaded:
   

3. If users already marked a download thread as downloaded:
   

4. The data can be viewed, edited, or deleted by Administrators directly in a download thread by full editing the thread.
   

That is my idea. Not quite sure whether it is OK or not

Note:
Do Not use this plugin in a production forum. This is for example and an idea only.

[leefish]

I like this idea very much RateU. I guess its sort of similar to subscribing to a thread.

I am a member of a very big forum (VB sadly) and in that we have a list of all our downloaded items in our USER CP. There is a link in the User CP, and clicking on it takes you to subpage called "my downloads". In that page we see a list of all the items we have downloaded. Its really neat for checking for if any item we have downloaded is updated after we have downloaded it.

I have attached a picture of the report we get in the "My Downloads" page, just an idea of what I would be hoping to do with the data.

I would consider making it happen automatically rather than on request - for users at least.

[RateU]

(03-25-2011 12:41 PM)leefish Wrote:  In that page we see a list of all the items we have downloaded. Its really neat for checking for if any item we have downloaded is updated after we have downloaded it.

I think it is better to use a 'dedicated' table for that, Lee.

(03-25-2011 12:41 PM)leefish Wrote:  I would consider making it happen automatically rather than on request - for users at least.

I think a user needs to 'mark' a thread as downloaded thread, and record the needed data in the 'dedicated' table. And the 'system' will check whether the file already updated or not automatically. Do you mean like that?

[leefish]

Well, I agree it needs a dedicated table - will be death to the DB otherwise I think. I just think requiring the user to "mark" the thread will risk us having incomplete data. It is my experience so far that asking users to DO things often results in a lot of "durrrrrr" sounds all over the forum. Of course, the advantage of making it user selection is that existing users can "update" the downloaded items list themselves.

If this was a new install I would think it would be better that the action of downloading the item automatically updated the existing table. Unfortunately I already have something "hooked" onto that bit of the xthreads.attach.php...... if it was possible to add them both then that would be cool, but I see that there may be an issue with guest downloads.

You can see the code I used for the "hook" to the dedicated table in this post and this post (there is no hook in xthreads.attach.php but I don't know how else to say it).

I would definitely see this as a thing for the downloader/admin to use, and for the actual uploader to have no visibility on WHO downloaded the thread. In my experience it could cause squabbles and friction if an uploader discovers that user x downloaded and did not thank the thread (simmers are very emotional).

[RateU]

(03-28-2011 11:52 PM)leefish Wrote:  I just think requiring the user to "mark" the thread will risk us having incomplete data.

I'm sorry, I can't understand what you meant by the 'incomplete data'?

(03-28-2011 11:52 PM)leefish Wrote:  If this was a new install I would think it would be better that the action of downloading the item automatically updated the existing table.

If you already edit the XThreads file, I think you can stick the code there.

(03-28-2011 11:52 PM)leefish Wrote:  I already have something "hooked" onto that bit of the xthreads.attach.php...... if it was possible to add them both then that would be cool, but I see that there may be an issue with guest downloads.

Probably create other dedicated table with this structure:

did => Primary Key
aid => attachment id
tid => thread id
uid => user id (downloader)
lastupdate => the updatetime of the attachment being downloaded. Probably you need to edit your query to load the update time of the attachment being downloaded, and record the result into this field.

Update/insert the fields when a user download an attachment.

(03-28-2011 11:52 PM)leefish Wrote:  but I see that there may be an issue with guest downloads.

Check whether the user has an uid or not before run the update/insert query?

(03-28-2011 11:52 PM)leefish Wrote:  I would definitely see this as a thing for the downloader/admin to use, and for the actual uploader to have no visibility on WHO downloaded the thread. In my experience it could cause squabbles and friction if an uploader discovers that user x downloaded and did not thank the thread (simmers are very emotional).

I think in showthread you can check whether a user is admin or not before run a query (if you want to display who downloaded the attachment in this page) from the table (select uid, and put tid in WHERE clause)?

In usercp (using a specified action maybe), run a query (put uid in WHERE clause). I think you need to join the xtattachments table with this query, so you can compare the lastupdate and the updatetime.

It is only my opinion

[ZiNgA BuRgA]

A problem you may face is that xthreads_attach.php doesn't load the MyBB core, so stuff like $mybb->user won't be available unless you cause it to be loaded.  You can probably try changing the "LOAD_SESSION" define to true to see if that does it.

[leefish]

(03-29-2011 06:44 AM)RateU Wrote:  

(03-28-2011 11:52 PM)leefish Wrote:  I just think requiring the user to "mark" the thread will risk us having incomplete data.

I'm sorry, I can't understand what you meant by the 'incomplete data'?

By incomplete data I mean that there would be the chance that a downloader did not mark all the threads they downloaded - sometimes deliberately not, sometimes because they forgot.

(03-29-2011 06:44 AM)RateU Wrote:  

(03-28-2011 11:52 PM)leefish Wrote:  If this was a new install I would think it would be better that the action of downloading the item automatically updated the existing table.

If you already edit the XThreads file, I think you can stick the code there.

By the new install I was referring to a MYBB install rather than an XThreads Install. In an existing forum then there probably are downloads already, so having the user mark as download is the way to go as data is already incomplete. Its also a lot easier than trying to hook into XThreads.....(maybe thats because I am a noob at coding though)

However, on a NEW FORUM INSTALL, with XThreads in there from day one,  then catching the data at the moment of download is the way to go (IMO). That way you get a complete record.

(03-29-2011 06:44 AM)RateU Wrote:  

(03-28-2011 11:52 PM)leefish Wrote:  I already have something "hooked" onto that bit of the xthreads.attach.php...... if it was possible to add them both then that would be cool, but I see that there may be an issue with guest downloads.

Probably create other dedicated table with this structure:

did => Primary Key
aid => attachment id
tid => thread id
uid => user id (downloader)
lastupdate => the updatetime of the attachment being downloaded. Probably you need to edit your query to load the update time of the attachment being downloaded, and record the result into this field.

Update/insert the fields when a user download an attachment.

Hmm, I am unsure as to the did as the primary key - I would have thought the user ID, then check to see if they had already downloaded? Table design is a new area for me though, so you are probably right.

(03-29-2011 06:44 AM)RateU Wrote:  

(03-28-2011 11:52 PM)leefish Wrote:  but I see that there may be an issue with guest downloads.

Check whether the user has an uid or not before run the update/insert query?

See the point from Zinga -I was unable to work out  how to hook into WHO had downloaded stuff  - now I see why..... so in order to see IF its a guest I would need to load the session (and the mybb core) - would that have a slowdown effect?

(03-29-2011 06:44 AM)RateU Wrote:  

(03-28-2011 11:52 PM)leefish Wrote:  I would definitely see this as a thing for the downloader/admin to use, and for the actual uploader to have no visibility on WHO downloaded the thread. In my experience it could cause squabbles and friction if an uploader discovers that user x downloaded and did not thank the thread (simmers are very emotional).

I think in showthread you can check whether a user is admin or not before run a query (if you want to display who downloaded the attachment in this page) from the table (select uid, and put tid in WHERE clause)?

Yes, I would do that too

(03-29-2011 06:44 AM)RateU Wrote:  In usercp (using a specified action maybe), run a query (put uid in WHERE clause). I think you need to join the xtattachments table with this query, so you can compare the lastupdate and the updatetime.

Re the "My Downloads" view - yes, definitely a USERCP thing - the way I have it at the moment with my stats for uploaders is that the user will see threads in their stats  IF they have uploaded something - I would think a similar approach would work to check if user id is in the table then show results.


Re the remark from Zingaburga:
Aha - when I fastened on the query I have I found that it was rather difficult to get that user data - that explains why I was unable to do anything other than play about with the actual xattachments data. Of course, for what I have now, who downloaded was not a consideration.

[ZiNgA BuRgA]

(03-29-2011 08:34 AM)leefish Wrote:  Hmm, I am unsure as to the did as the primary key - I would have thought the user ID, then check to see if they had already downloaded? Table design is a new area for me though, so you are probably right.

Primary keys need to be unique, so if you put it on uid, the user cannot have more than one aid associated with it.
did is an "artificial" primary key.
Personally, I'd put it on aid,uid (ie, a composite primary key), since the pair of columns uniquely identify each table row (what a primary key should do).

(03-29-2011 08:34 AM)leefish Wrote:  I would need to load the session (and the mybb core) - would that have a slowdown effect?

Loading core definitely consumes more resources, but how much is somewhat open to interpretation, and whether it affects you is something you need to find out (in short, if host doesn't complain, you're probably fine).  Here's a bit more of a technical explanation.
xthreads_attach.php was somewhat designed to handle two extreme cases which the MyBB attachments.php doesn't do well (as well as a number of other things, but that's irrelevant here):
- very large (i.e. multi-gigabyte) downloads
- many requests (i.e. an image gallery displaying a lot of thumbnails on a page)

For the former case, typically the script will be active for a long time, since the download will take a while to transfer.  So if we load the core here, the script will hog that amount of memory for quite some time.  This problem can be further compounded with multi-part downloading - eg, user downloads a 2GB file with 10 threads = 10x MyBB cores stay resident on the server's memory whilst the user downloads the file.
If you have no excessively large downloads, then this point isn't a problem.

For the latter case, imagine a gallery 18 thumbnails per page.  Loading the core effectively means that a user visiting forumdisplay will cause the MyBB core to be loaded 19 times, instead of just once.  Quite a bit more load obviously, but if your host isn't complaining, then this shouldn't be much of an issue.  If you're not using something like this, then you don't need to worry either.
There may be a fix for this issue on XThreads' end by directly linking thumbnails rather than serving through xthreads_attach.php - I don't know why I didn't think of it a long time ago.  It might be a bit too late to change now (breaks template edits) though there may be a bit of a workaround.
But there's another thing you could do - just simply conditionally define LOAD_SESSION based on whether the user is trying to view a thumbnail or not.  May require a fair bit of editing though.

[RateU]

(03-29-2011 08:03 AM)ZiNgA BuRgA Wrote:  A problem you may face is that xthreads_attach.php doesn't load the MyBB core, so stuff like $mybb->user won't be available unless you cause it to be loaded.

Ah yes, I don't know about it, Yumi

Off Topic:

I have a question, Yumi:

If I want to edit XThreads files to put some plugin hook, could you suggest in which part/area I should put it?

[ZiNgA BuRgA]

I can't really suggest anything - just place it wherever it suits you best.