Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[Discussion] 2.0 Attachment System Enhancements
#1
I wanted to bring this discussion to the community after having discussed it as a staff team. We're hoping to start doing this much more frequently for major features in order to gather feedback on what we've decided so far and to promote suggestions for changes and enhancements. Below is the current draft of what we (as a team) would expect the attachment system in 2.0 to do/change.



MyBB 2.0 should feature a much enhanced attachment system, with the following being key goals:
  • Attachments should be able to be attached to posts, announcements and conversation messages.
  • Users should have an "attachment library" from which they can select old attachments rather than uploading them again.
  • Attachments should be exposed with their original extension rather than the MyBB 1.x 
    abc.attach
  • Attachments should be able to be uploaded to both a local filesystem and external services (e.g.: Amazon S3, Dropbox, etc.).
  • Add the ability to perform extra processing on certain attachment types such as image compression, etc. This could simply be via plugin hooks or via some other system that is yet to be decided.
  • Attachments should be configurable to allow only certain mime types/extensions.
  • Users should have a quota disk space for attachments, which is configurable by user group.
  • UI Wise, the attachment system should support drag/drop with multiple uploads and a simple load button fallback for users without JavaScript. Uploads should be performed via AJAX.
  • Attachments should be configurable with user group permissions to control at least the following:
    • Can upload attachments?
    • Attachment quota (MB)?
    • Can view attachments?
    • We'll also maybe want to restrict attachment types (by mimetype/extension) to only be uploaded by certain groups.
  • Set attachments to require moderation before display on a per user group/forum basis.
We do not want the attachment system to become a gallery system or anything extreme like that. We wish for it to maintain its simplicity yet improve its ease of use and flexibility to allow further development and enhancement by plugin developers.

We are looking on feedback on the above points and suggestions on anything we may have over looked or not yet thought of. Note that your suggestions may gather a lot of support, but that is in no way a guarantee that they will be implemented (though if they're sensible, feasible and fit within our vision for MyBB, there's a very high chance they will be!). Please try to keep this discussion on topic as it's also a first instance of this kind of thing being done and will be watched to influence future decisions.

Thanks!
Reply
#2
nice list of features there, Euan. I like the ability to offload the attachments to a 3rd party..that'll help keep the disk space overhead low for big boards. I imagine imgur would be in that mix as well? how would the system work? will users be able to manage their 'attachments' if a board owner offloads it to a 3rd party?
Reply
#3
(08-13-2015, 07:46 PM)andrewjs18 Wrote: nice list of features there, Euan.  I like the ability to offload the attachments to a 3rd party..that'll help keep the disk space overhead low for big boards.  I imagine imgur would be in that mix as well?  how would the system work?  will users be able to manage their 'attachments' if a board owner offloads it to a 3rd party?

I'm not sure about Imgur as I haven't looked at their API. Amazon S3 and Dropbox come off the top of my head as they work with the Flysystem library we will be using. The details about the attachments will be stored in the database with any relevant meta information (e.g.: upload path if local, ID or whatever if remote, etc) so it'll all be manageable the same way hopefully Smile

The way attachments are stored in the database/filesystem still needs to be designed too, but I'd like to see attachments stored with an MD5 hash of the origin file to make sure they're all verifiable and this could also possibly be used to catch duplicates and save disk space that way.
Reply
#4
(08-13-2015, 07:53 PM)Euan T Wrote:
(08-13-2015, 07:46 PM)andrewjs18 Wrote: nice list of features there, Euan.  I like the ability to offload the attachments to a 3rd party..that'll help keep the disk space overhead low for big boards.  I imagine imgur would be in that mix as well?  how would the system work?  will users be able to manage their 'attachments' if a board owner offloads it to a 3rd party?

I'm not sure about Imgur as I haven't looked at their API. Amazon S3 and Dropbox come off the top of my head as they work with the Flysystem library we will be using. The details about the attachments will be stored in the database with any relevant meta information (e.g.: upload path if local, ID or whatever if remote, etc) so it'll all be manageable the same way hopefully Smile

The way attachments are stored in the database/filesystem still needs to be designed too, but I'd like to see attachments stored with an MD5 hash of the origin file to make sure they're all verifiable and this could also possibly be used to catch duplicates and save disk space that way.

here's to hoping that imgur's api can work with mybb 2.0 as they don't limit disk space AFAIK.
Reply
#5
What about the option to limit how much a user can upload per file? (This way admins can limit how much each file can take up. So they don't end up with a bunch of 10-20 MB files. EX- video clips, camera raws, etc...)

I do think the idea for an attachment "library" is a massively important and should be a central goal. This way each user would have a central location to see everything they've uploaded. (It'd be nice if it showed them where things were linked too, so this way if they uploaded funny.gif to a post then PMed it it'd show them which post and which PM if it was still in their sent/saved items.)

It may also be a good idea to include an attachment cleaner too so that if they delete an attachment it could check through and remove links to that attachment to stop dead links.
My MyBB 2.0 suggestions - Mass edit group permissions - Post based Anti-spam
Reply
#6
(08-13-2015, 07:55 PM)andrewjs18 Wrote:
(08-13-2015, 07:53 PM)Euan T Wrote:
(08-13-2015, 07:46 PM)andrewjs18 Wrote: nice list of features there, Euan.  I like the ability to offload the attachments to a 3rd party..that'll help keep the disk space overhead low for big boards.  I imagine imgur would be in that mix as well?  how would the system work?  will users be able to manage their 'attachments' if a board owner offloads it to a 3rd party?

I'm not sure about Imgur as I haven't looked at their API. Amazon S3 and Dropbox come off the top of my head as they work with the Flysystem library we will be using. The details about the attachments will be stored in the database with any relevant meta information (e.g.: upload path if local, ID or whatever if remote, etc) so it'll all be manageable the same way hopefully Smile

The way attachments are stored in the database/filesystem still needs to be designed too, but I'd like to see attachments stored with an MD5 hash of the origin file to make sure they're all verifiable and this could also possibly be used to catch duplicates and save disk space that way.

here's to hoping that imgur's api can work with mybb 2.0 as they don't limit disk space AFAIK.
Well, it's more like that MyBB 2.0 has to work with Imgur's API if it is decided as core feature or added by a plugin. Imgur's API is rather easy to use and imo even easier to integrate. The thing is that just every board administrator has to register an app for his board at Imgur and give MyBB the API credentials.
Reply
#7
(08-13-2015, 08:26 PM)VirusZero Wrote: What about the option to limit how much a user can upload per file? (This way admins can limit how much each file can take up. So they don't end up with a bunch of 10-20 MB files. EX- video clips, camera raws, etc...)

I do think the idea for an attachment "library" is a massively important and should be a central goal. This way each user would have a central location to see everything they've uploaded. (It'd be nice if it showed them where things were linked too, so this way if they uploaded funny.gif to a post then PMed it it'd show them which post and which PM if it was still in their sent/saved items.)

It may also be a good idea to include an attachment cleaner too so that if they delete an attachment it could check through and remove links to that attachment to stop dead links.
That kind of comes in with the quota feature I mentioned in the original spec. I'd personally like to see a file size limit per file type (e.g.: PNG files can only be a max of 2MB, MP4 files can be 5MB, etc.).

The library is planned as said in the original outline too, and will allow users to re-use their existing attachments elsewhere without re-uploading them.

The attachment cleaner is interesting. We'll have to look at what we can do there with the pre-parsing of posts that is implemented with 2.0...
(08-13-2015, 08:31 PM)Exception Wrote:
(08-13-2015, 07:55 PM)andrewjs18 Wrote:
(08-13-2015, 07:53 PM)Euan T Wrote:
(08-13-2015, 07:46 PM)andrewjs18 Wrote: nice list of features there, Euan.  I like the ability to offload the attachments to a 3rd party..that'll help keep the disk space overhead low for big boards.  I imagine imgur would be in that mix as well?  how would the system work?  will users be able to manage their 'attachments' if a board owner offloads it to a 3rd party?

I'm not sure about Imgur as I haven't looked at their API. Amazon S3 and Dropbox come off the top of my head as they work with the Flysystem library we will be using. The details about the attachments will be stored in the database with any relevant meta information (e.g.: upload path if local, ID or whatever if remote, etc) so it'll all be manageable the same way hopefully Smile

The way attachments are stored in the database/filesystem still needs to be designed too, but I'd like to see attachments stored with an MD5 hash of the origin file to make sure they're all verifiable and this could also possibly be used to catch duplicates and save disk space that way.

here's to hoping that imgur's api can work with mybb 2.0 as they don't limit disk space AFAIK.
Well, it's more like that MyBB 2.0 has to work with Imgur's API if it is decided as core feature or added by a plugin. Imgur's API is rather easy to use and imo even easier to integrate. The thing is that just every board administrator has to register an app for his board at Imgur and give MyBB the API credentials.

Yeah, I just haven't had time to look at it nor have I worked with it before. I'm sure there are libraries to make it super easy to work with too. The only slight problem will be that Imgur will only work for images (obviously) so perhaps attachment types can have an option such as "is an image file?" so only images will be pushed across to Imgur. 

Creating an app isn't a problem really IMO. The same kind of thing will be required to use S3, Dropbox, etc. Whether or not this will be configurable via the ACP (I'd like to think so, but I'm not sure yet - depends on how we get on) or whether it's within the config files depends.
Reply
#8
best if add option for:


  • Attachments should be able to be uploaded to both a local filesystem and external services
    • Can upload attachments?
    • Attachment quota (MB)?
    • Can view attachments?
    • We'll also maybe want to restrict attachment types (by mimetype/extension) to only be uploaded by certain groups.
    • just use external services ?
Reply
#9
@OMID_HXC - I believe Euan meant to say that both local and external storage systems will be options. Therefore, it should be feasible to only use external services, if you wish.
PGP Key (Fingerprint: 9163 CDB6 2513 5205 28E0  5EF5 2FF1 92C4 5261 6DF0)
Reply
#10
(08-14-2015, 03:36 AM)Josh H. Wrote: @OMID_HXC - I believe Euan meant to say that both local and external storage systems will be options. Therefore, it should be feasible to only use external services, if you wish.

Yeah, that's exactly what I meant. Sorry if that isn't clear Smile
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)