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
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)
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.
@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?
Our Internet use policy restricts access to this web page at this time.
Reason: This Websense category is filtered: Personal Network Storage and Backup.
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:
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.