My Feature Ideas

[ZiNgA BuRgA]

v1.40 of XThreads will have most of the features I've wanted to include in the plugin.  So I'm thinking of slowing down on development after that, and primarily only maintain bug fixes and maybe something that really interests me, but I kinda want to move on to other things.

But whilst I'm still working on it, I may consider adding something.
Here's a dump of the random ideas I thought had some interest, but may or may not implement:

Custom Thread Fields

• Max/min limit for multiple valued thread fields (ie, you cannot have more than 5 values) Use conditional input error in XThreads 1.6: <if substr_count({VALUE}, "\n") > 5 then>You cannot enter more than 5 items</if>
• Multiple file input field??  This may be rather tricky to do.
• Vocabulary.  For example, you may set this to "valid username".  If so, XThreads will ensure that anything entered by the user will be a valid username on the board.  This may be useful for applications where you may wish to assign a thread to someone or similar (and the filtering system will allow users to see what's assigned to them).  Other vocab terms could work, such a valid thread ID etc.  A difficulty may be what to do if the thread/post is deleted.
• Additional "Parser" setting: filtered HTML.  Allows HTML, but a very limited subset of it.  Dunno if this is useful in any way. Seems not too useful; can always attach a plugin and use with conditionals to do the parsing.
• Additional "Parser" setting: evaluated value.  Essentially allows variables to be inserted, as well as conditionals.  I'm worried about the security implications of this however.  This may be useful for a "custom pages" type system.
• Separate "editable" and "settable" permissions.  The former refers to being able to edit the value (ie after the thread has been posted), whereas the latter refers to permissions when posting a new thread.  May be useful if you want someone to set a value but not change it after posting perhaps. Use conditional input error in XThreads 1.6: <if $current_page == 'editpost.php' then>You cannot modify this value</if> (you'll probably also want to wrap a similar conditional around Custom Input HTML)
• Extend display order?  Right now it just orders fields around the place, however, there's no easy way to move a field above the subject, or below the message textarea etc.  Although it can be done via template edits, there's a bit of difficulty with getting the tab indexes right.  IDK how I'd ever implement such a thing though.  Suggestions?
• Recognise more file types than just images, such as ZIP archives, MP4 videos etc; eg "only accept .torrent files", and provide additional information about the torrent file in the $threadfields['key'][...] array Use a plugin framework for this instead.  Stick to image types only for core.
• Custom HTML for thread field input; I originally planned to do this, but ditched it, so might bring it back.  The idea is that you can specify the HTML used for the thread field input, rather than relying on a preset textbox/textarea/selectbox etc
• Regular expression matching in Format Map?
• Indexing table - improve performance with filtering on a multi-valued field, and possibly allow displaying all values set for a field (ie a thread tagging system)
  

Other

• Variables and conditionals in forum template prefix.  May have some uses, such as "views", eg, use a different template prefix if $mybb->input['view']=='different'.  Difficulty with handling search/portal prefixes however.
• Partial match filtering.  Currently, filtering only works on exact matches, eg filtertf_something=somevalue - something must equal somevalue.  Perhaps allow some way to filter based on what it starts/ends with or contains, eg everything beginning with 's'.  Am worried about the performance of this, but I guess that's the admin's decision to enable it.
• Filter by other thread properties, eg replies, views, closed status etc?
• Additional filter operators (somewhat linked to partial match filtering) - eg > operator, combined with the above, filter by threads with >10 replies or whatever, or maybe all threads with thread field somefield NOT equal to somevalue
• Filter threads in portal
• xtattachment optimiser?  Optimise uploaded JPEG/PNGs (through jpgcrush/pngout if available) or provide some means for parsing and modifying uploaded attachments? Doesn't make too much sense without context of the file.  May add some image processing support for v1.6
• Gzip support for xtattachments?  And maybe even store the file gzipped? [won't work well with ranged requests]  Possibly also add some smart system to see whether it's worthwhile gziping a file, eg, it's pointless to gzip a PNG file, but probably a good idea to gzip a HTML file.
• Disable certain moderation actions in certain forums.  May help with some integrity, for example, allowing moderators to move threads around the place may have some adverse effects on thread fields.
• Or maybe check integrity on moderation action and get moderators to amend integrity violations?  For example, if required thread field A is assigned to forum A, but not B, and a moderator moves a thread from forum B to A, normally, the required thread field A won't have a value set, since it was posted in B and not required there.  With this, when the moderator attempts the move, it will ask the moderator to fill in A, helping maintain integrity.
• Some plugin API?  I'm thinking of deferring this.
• Admin logs - I really haven't looked at this and don't even know if it works
• Check data integrity?  There's a few places where a bug may potentially damage (XThreads') data in the database due to various integrity assumptions.  A check integrity feature can ensure that these assumptions haven't been broken by anything.
• More per forum settings overrides?  Such as override maximum post size (on a per forum basis), post flood time etc.  Maybe more suitable for a separate plugin though...
• Child threads - allow threads to be created within threads.  Can potentially see some uses (discussion forking?, maybe downloads within a download, for example, older versions of a program) but IDK how easy it is to implement.  Some random idea that came by me some time...
• Search thread fields, dunno how to implement this one exactly
• Custom post fields - probably won't ever implement this
  

I'm obviously not going to implement all, or really, any, of these, but if you think anything is particularly interesting, you can put your case forward, and I'll see if you've thought up something I haven't thought of before

[Imran]

Some of them are must have features and some are amazing, especially this;

Quote:Child threads - allow threads to be created within threads.  Can potentially see some uses (discussion forking?, maybe downloads within a download, for example, older versions of a program) but IDK how easy it is to implement.  Some random idea that came by me some time...

Threads within Threads ??

[RateU]

(12-08-2010 09:00 PM)ZiNgA BuRgA Wrote:  [*]Admin logs - I really haven't looked at this and don't even know if it works

I've checked my Admin Logs (MyBB 1.4), it shows something like this:
config/threadfields - edit(thread fields key, thread fields title)
config/threadfields - add(thread fields key, thread fields title)

So, I think it works, Yumi?

Mmmm.... are we allowed to "vote" up to three from that feature list, Yumi ?

[ZiNgA BuRgA]

Oh thanks for that.  You can put forward whatever you feel is the most interesting

[RocketFoot]

There is nothing I can add other than this mod already exceeds anything I could dream up!  Anything else you add will be icing on the cake!

Thanks for everything!

[RateU]

(12-08-2010 09:00 PM)ZiNgA BuRgA Wrote:  Variables and conditionals in forum template prefix.  May have some uses, such as "views", eg, use a different template prefix if $mybb->input['view']=='different'.  Difficulty with handling search/portal prefixes however.

Do you mean, when users visit forumdisplay.php?fid=forum_id or showthread.php?tid=thread_id, the default template prefix will be used,

but,

when users visit forumdisplay.php?fid=forum_id&view=tp1 or showthread.php?tid=thread_id&view=tp1, then, the tp1_ template prefix will be used,

or,

if users visit forumdisplay.php?fid=forum_id&view=tp2 or showthread.php?tid=thread_id&view=tp2, then, the tp2_ template prefix will be used,

as long as the template available, Yumi?

[ZiNgA BuRgA]

If you supply it in the prefix, eg:

Code:

<if $mybb->input['view'] == 'tp1' then>tp1,</if>normalprefix

---

[RateU]

Woaaa..... I'm more than 100% sure to vote for that feature, Yumi!
It will enhance the usage of the multiple template prefix feature.

(12-08-2010 09:00 PM)ZiNgA BuRgA Wrote:  Child threads - allow threads to be created within threads.  Can potentially see some uses (discussion forking?, maybe downloads within a download, for example, older versions of a program) but IDK how easy it is to implement.  Some random idea that came by me some time...

This..... I've been thinking of this since yesterday. But I can't imagine how this systems works......
Could you give us more info, Yumi?

[leefish]

(12-08-2010 09:00 PM)ZiNgA BuRgA Wrote:  Child threads - allow threads to be created within threads.  Can potentially see some uses (discussion forking?, maybe downloads within a download, for example, older versions of a program) but IDK how easy it is to implement.  Some random idea that came by me some time...

I was looking at this one - and I realised that you can ALMOST make a blog set up doing that. The THREAD is the blog - the thread within the thread is the blog entry - and the comments on the "sub thread" are comments on the blog. That would be rather swish XBlogs.......

(12-08-2010 09:00 PM)ZiNgA BuRgA Wrote:  Indexing table - improve performance with filtering on a multi-valued field, and possibly allow displaying all values set for a field (ie a thread tagging system)

Yes - that would be awesome indeed

and - not mentioned - but wanted by me for so long - a way to create a display page for a "family"of forums all using the same custom thread fields (would tie in nicely with that XBlog.....)

[ZiNgA BuRgA]

(12-10-2010 12:12 PM)RateU Wrote:  This..... I've been thinking of this since yesterday. But I can't imagine how this systems works......
Could you give us more info, Yumi?

Well, inside threads, you have an additional "New Thread" button, which allows you to create a thread.  The difference is that this thread will be contained with the thread you created it in.
You can somewhat think of it like the hierarchical forums system, except this is for threads. (and this can probably go on infinitely, unless a limit is set, eg, you can create a child of a child thread)

Threads will contain a listing of the threads contained within.
I think a big difficulty would be modifying moderator tools to suit the system.

(12-10-2010 12:44 PM)leefish Wrote:  I was looking at this one - and I realised that you can ALMOST make a blog set up doing that. The THREAD is the blog - the thread within the thread is the blog entry - and the comments on the "sub thread" are comments on the blog. That would be rather swish XBlogs.......

I think manually creating forums might be better?  If you really do have a user base, this system is a bit cumbersome as users need to create their "parent thread" for the blog, and there's nothing stopping people posting threads in other peoples' blogs...

(12-10-2010 12:44 PM)leefish Wrote:  and - not mentioned - but wanted by me for so long - a way to create a display page for a "family"of forums all using the same custom thread fields (would tie in nicely with that XBlog.....)

Would you be able to elaborate more?