This server will not be available today at 3PM Seattle time. I will be performing an upgrade which hopefully will take around 15 minutes.
Upgrade is done. We should now have file attachment support. The button on the toolbar still looks like an image, but it should support a large variety of file formats now
Guess I should test 
Here’s an attachment of a 3dm file
facetest.3dm
We are now running on discourse version 0.9.3 (with some hacks for file attachments). If you really want to geek out and see what has changed recently, here’s the commit log
I really dislike that links are opened in the active window.
Please add “open in new tab/window” as default.
And that github link gave me an angry, pink, unicorn and this: “This page is taking way too long to load.
Sorry about that. Please try refreshing and contact us if the problem persists.”
Also your smilyface took 15 seconds to load, the text was fast, but anyting imagerelated is slow over here (Norway)
-J
There is a check box in your user preferences to enable this. Click on your name and go to preferences to set this.
I wish it were “on” by default and users could choose to turn it off.
1 Like
@brian - The 
emoji is an image on our discourse server. Sounds like we may need to experiment with cloudfront or pagespeed
Did you see the problem if you refreshed?
If this was your first time visiting github, I can understand why you may be getting the error message. I’ve seen the load time for people new to github slow the first time they visit the site. Probably some larger javascripts are being download and stored in your browsers cache.
oh no…
Our Internet use policy restricts access to this web page at this time.
Reason: This Websense category is filtered: Personal Network Storage and Backup.
URL: https://www.filepicker.io/api/file/Izv9Ch3pSA2eUIVtV5cg
Yes, Github loaded fast now.
Man, that makes things tougher. I’m assuming that the image/file attach button in your reply toolbar also doesn’t work since it is using filepicker.io.
@brian any thoughts on this?
Not sure. It looks like Filepicker doesn’t make it very easy to link directly to the file on S3.
I did a test just now, and ended up with these two links:
https://www.filepicker.io/api/file/TcJ2CVVNSSy0eZHm0a5M
http://usercontent.mcneel.com/discourse/attachments/Z0RqVweRjax4VHjuPiVb_pipe.3dm
The first link goes through filepicker.io, and gives back a file named “pipe.3dm”. The second is the direct location of the file on S3, and gives back a file named “Z0RqVweRjax4VHjuPiVb_pipe.3dm” which isn’t very useful.
It appears that filepicker.io insists on using “_” as a delimiter between the file key and the filename. If it used “/” instead, we’d be golden. I guess we can see if the filepicker.io team is as responsive as the Discourse team to making improvements!
Even if we could make it so @wim can get links that work with the files, it still may not work for actually submitting the files.
Perhaps this is why Discourse originally used their own upload to their own server, then to S3 
I don’t know what the best option is. Worst case, Wim can use his own file sharing service to share with us.
I don’t think we’ve got the bandwidth to write a full-featured file upload javascript system for Discourse at this point.