Seriously? is it deprecated now or not? and why bro?
there is no alternative to local file uploading :’(
Seriously? is it deprecated now or not? and why bro?
there is no alternative to local file uploading :’(
Rolled my own. But in case anyone else is looking for how to upload files in Meteor 1.3:
<input type="file" onChange={beginFileUpload} />
This of course means that file upload will begin immediately after selecting a file. Setting multiple
is perfectly fine as well so you can upload more than one file simultaneously.
beginFileUpload: (e) => {
if(Roles.userIsInRole(Meteor.user()._id, 'admin', 'admin_group')) {
let input = e.target;
_.each(input.files, function(file) {
let fileReader = new FileReader();
let encoding = "binary";
let name = file.name;
fileReader.onload = function() {
if(fileReader.readAsBinaryString) {
Meteor.call('saveFile', fileReader.result, name, '', encoding);
} else {
var binary = "";
var bytes = new Uint8Array(fileReader.result);
var length = bytes.byteLength;
for(var i=0; i < length; i++) {
binary += String.fromCharCode(bytes[i]);
}
Meteor.call('saveFile', binary, name, '', encoding);
}
};
fileReader.onloadend = function (e) {
console.log(e);
};
fileReader.onloadstart = function (e) {
console.log(e);
};
fileReader.onprogress = function (e) {
console.log(e);
};
fileReader.onabort = function (e) {
console.log(e);
};
fileReader.onerror = function (e) {
console.log(e);
};
if(fileReader.readAsBinaryString) {
fileReader.readAsBinaryString(file);
} else {
fileReader.readAsArrayBuffer(file);
}
});
}
}
Take note of the final if-clause and the one inside the onload event handler - that one is needed to deal with the Internet Explorer as it does not know the readAsBinaryString method. You can use the copious other event handlers to deal with displaying info about the upload.
Finally:
const fs = require('fs');
Meteor.methods({
saveFile: function(blob, name, path, encoding) {
if(Roles.userIsInRole(Meteor.user()._id, 'admin', 'admin_group')) {
console.log("Allowed");
if(process.env.NODE_ENV === "production") {
var path = '/var/www/static';
} else {
var path = process.env['METEOR_SHELL_DIR'] + '/../../../public/static';
}
var filename = name.toLowerCase().replace(/ /g,'_').replace(/ä/g,'ae').replace(/ö/g,'oe').replace(/ü/g,'ue').replace(/ß/g,'ss').replace(/[^a-z0-9_.]/g,'');
fs.writeFile(path+"/"+filename, blob, encoding, Meteor.bindEnvironment(function(err){
if(err) {
console.log("Error:"+err);
} else {
console.log("Success");
FileCollection.insert({name: name, filename: filename});
}
}));
}
}
});
Here you’ll note three things, basically. Firstly, I’m using alanning:roles
to make sure that actually saving files is only doable by worthy persons.
Secondly, I’m sending my files somewhere else in production than I’m doing in development (the huge mess of strings is due to how finding the directory under Windows works) - the URI is the same for both, because I configured the nginx webserver to serve up anything under /static
directly and not through the Node process.
Thirdly, I’m sanitizing my filename a bit, replacing spaces with underscores, Umlaute with similar ASCII counterparts and finally stripping away anything else. This method only lives on the server, so it’s not optimistic.
Thanks for @raix,
I think it is not good news.
I so very happy with CFS but I don’t want to closed this CollectionFS projects/github.
I think you can invite some one to continue support this project until you release the next version.
Many developer need this project in this times.
@aaronjudd @raix do you think someone (ongoworks, etc) could be granted collaborator status on the repo and allowed to review and merge in pull requests?
If not, I suggest that someone may want to fork and rename (for backwards/forwards compatibility) to keep this alive… it’s a great solution to a problem many many many developers have - and it’s still “good”… lets not loose it.
Sure @zeroasterisk we already have a couple on cfs with repo and publish access - but I think it would be great to add more. I had to mark the project as deprecated due to a number of complaints about it not being actively maintained - I lack time.
Sure - I totally understand that… Just trying to keep the torch burning, and hand it off to possible eligible maintainers with time (@aaronjudd).
Before xyz.meteor.com hosting was shut down, I have seen some prototype there, which offered marketplace similar to atmosphere.js but only with paid components in there.
I come from desktop world and our company is still buying components worth USD3000 a year from companies like Devexpress, there are tons of them for C/Delphi. There are a lot of paid components in Javascript world too, e.g. am going to license some calendar components.
What I have seen in open-source world is that some people are really ashamed to charge money for their work. If Meteor would like to lead the industry not follow it, it would be great to see marketplace of paid components (just forking Galaxy billing infrastructure, which I am sure tested and working) and even charging some 5-10% like Digital River and other Billing providers do.
Having said that, are there any paid Meteor components apart from Meteor Toys? Is everyone truly ashamed to charge money? Sad but true, while Linus has all the glory with his OS, Google has all the commercial success and 0.001% of Android users know there is Linux inside.
You have told about potential issues. So is it safer to use CollectionFS with Meteor 1.2.1 than with Meteor 1.3?
I’ve actually been thinking about this. Building a “startup” package that sells all the API integrations/components we’re building/built with Meteor+Polymer. I’m sure lots of startups could use quick “drag and drop solutions” that go beyond just UI layer but actually full functionalities. I’m sure you can make lots of money with that, considering really shitty reused bootstrap UI kits get sold for 30-60$ each.
I was already reducing dependencies that I only used minimally and built myself a replacement. Here it is for those who want to use it. In order to use multiple photos, you need an HTML form that takes all the file names and passes them to the event handler, which passes them to the WebApp function. That function can be abstracted to upload them by name, and then you can create a server that serves them and helpers that take the photo name and return the photo. There is a lot of nuaced features from cfs missing but it works.
client.html
<div class="form-group"> <label for="photoupload" class="control-label">Upload Photo: </label> <input type="file" class="photoupload" id="photoupload"><br> <img src="{{photopreview}}" alt="(Preview)" class="thumbnail"> </div>
client.js
Template.photo.events({ 'change .photoupload': function (event) { var file = event.target.files[0] var xhr = new XMLHttpRequest() xhr.open('POST', '/uploadPhoto', true) xhr.onload = function (event) { window.alert('Upload successful') window.location.reload() } xhr.onerror = function (error) { window.alert(error) } xhr.send(file) } })
Template.photo.helpers({ photopreview: function () { return 'http://localhost:8084/files/photo.jpg' } })
server.js
import fs from 'fs' import http from 'http' WebApp.connectHandlers.use('/uploadPhoto', function (req, res) { mkdirp('../../../files/') var path = '../../../files/photo.jpg' var file = fs.createWriteStream(path) file.on('error', function (error) { console.log(error) }) file.on('finish', function () { res.writeHead(200, { 'content-type': 'text/plain' }) res.end() }) req.pipe(file) })
http.createServer(function (req, res) { var plantLogo = fs.readFileSync('../../../files/photo.jpg') res.writeHead(200, { 'Content-Type': 'image/jpeg' }) res.end(photo, 'binary') }).listen(8084)
Looks like an interesting solution, do you know of anyone that has tried AWS S3 integration? (have looked at the Dropbox example, and doesn’t seem completely straighforward of what to do on every case)
I think it’s a good move to drop CollectionFS. I was very excited of the concepts when I first saw CFS, but was also quite disappointed when I tried to use it - and eventually moved on to alternatives like Slingshot. It’s sad, but sometimes it’s better to make a clear cut. Nevertheless: thank you, raix, aldeed and all the others involved. I can pretty much understand that you don’t have the time to maintain the project as it would be required. And thumbs up for the decision.
Here is current milestone.
S3 shouldn’t cause any extra work, I think there is no need in integration. Support for HTTP/XHR upload directly to 3rd-party storage and expressive example will be enough.
Cool! But how about MIT-license?
What about it?
And it requires at least 20 chars
Hi all, first it’s sad to see that package unmaintained, but I am glad it inspired me when I started creating UploadFS, so if you are interested in an alternative to CFS, you can try UFS : https://github.com/jalik/jalik-ufs
It’s not that much different, from my point of view a little more simpler to use and extend.
First I created a local file system store and after two different developers added packages to support GridFS, WABS and AmazonS3.
Also, I am proud to say that it’s currently used by RocketChat, and if some of you would like to help improving the package with PR or addons, I would be glad to assist and help.
So does this mean no version of cfs:gridfs will work anymore? Or will versions below 0.0.29 work?
Hello everyone!
Sorry, this message a bit is unrelated to this thread. But here is a lot of devs interested in file upload.
We’ve implemented RTC/DC (WebRTC) uploads in Meteor-Files package, could you please give quick response with your point of view to this kind of transport for the file-uploads in this thread?
Any feedback is highly appreciated.
Sincerely.
I’ve checked out the CollectionFS on Github and it still has some updates (last 2 Months). I just to ask it this package is still deprecated or not. Since it isn’t mentioned on the Github page.