New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drag & Drop support of folders (Chrome >= 21) #587
Conversation
…ncelling the corresponding dom events
Conflicts: src/javascript/plupload.html5.js
Wrote a blog post containing more infos: http://blog.protonet.info/post/26894439416/html5-drag-drop-files-and-folders |
👍 |
What's the progress on this one? We need this functionality. |
Checking if those are indeed files that are being dragged is interesting. Will bear this in mind. |
Hi I would like to know if the folder uploading function will be incorporated to plupload 2, and why it's not in the latest releases of plupload 1.5.7 although the code is here. I'm trying to add it to this one, but I'm not able to add the files of a folder to the plupload component. Thank you very much, |
It is incorporated in Plupload 2. Regarding this code here, it is good, but still has some flaws. So that we cannot merge it directly. But more importantly the code for our html5 runtime in 1.x branch is already quite big and hard to follow. We decided to not extend it any further. So, only bugfixes. Plupload 2 will get all new features. |
If not too much to ask, do you know approximately when it will be available in the main branch of plupload 2? Thank you very much for your attention and congratulations for your work, plupload is the best upload component that I know. |
It is in main branch already. The latest binaries are always available at moxie repo, ubder |
I'm seeing the code, and I see the calls to webkitGetAsEntry and else, but I don't see any reference of relativePath or any other way to know the path of each file (of course, this is null when drag&drop folder and its files). Can it be done at present? Thank you very much |
Dropped folders are recursively checked for files that fulfill filter requirements and files that fit are added. That's it. How you planned to use relativePath or where did you expect it to appear? |
Yes, when I drag & drop a folder with subfolders and files inside, all the files appear in plupload, but I need to know what is the folder structure of each one of the files to uploading in order to I can clone the whole folder structure (with its files) in my server. jQuery('#uploader').plupload('getUploader').bind('BeforeUpload', function (up, file) {
up.settings.multipart_params = {'originalFileName':file.name,'totalSize':file.size,'relativePath':file.relativePath}
}); |
Makes sense. Also shouldn't require too much coding to add I guess, I'll check... |
After some thinking I came to a conclusion that it is more confusing than useful, mainly because it is not supported across browsers. Not sure why you would want to rely on something like that? |
It would be very useful and the easiest way to be able to upload files from different folders without mixing them and preserving the original order (that sometimes is complex and shouldn't be lost). Thank you very much for your attention |
has this been resolved in v2 yet? I am not seeing any relativePath definition similar to relativePath = directory.fullPath.replace(/^//, "").replace(/(.+?)/?$/, "$1/"); I agree that a way to duplicate a folder/subfolder structure on upload is a valuable feature, even if only supported by Chrome. |
Guys, until the new release is out – to take some pressure from Davit – you might want to use a workaround. Source: http://www.i-do-this.com/blog/plupload-2-1-chrome-and-folder-support/57 <div id="drop-target">
<input type="file" id="files" />
</div>
<button id="uploadfiles">Upload!</button>
<script src="//cdn.jsdelivr.net/plupload/2.1.2/plupload.full.min.js"></script> var uploader, traverseFileTree, map = {};
// replace by your plupload setup, this is just an example
uploader = new plupload.Uploader({
runtimes : 'html5',
container: 'drop-target',
drop_element: 'drop-target',
browse_button : 'files',
url : 'http://www.torrentplease.com/dropzone.php',
init: {
PostInit: function() {
document.getElementById('uploadfiles').onclick = function() {
uploader.start();
return false;
};
},
BeforeUpload: function (up, file) {
// send relativePath along
if(map[file.name] !== undefined) {
up.setOption('multipart_params', {
relativePath: map[file.name].shift()
});
}
}
}
});
uploader.init();
// all relative paths are built here
traverseFileTree = function (item, path) {
var dirReader = null;
path = path || '';
if (item.isFile) {
item.file(function(file) {
// careful here, could be several files of the same name
// we assume files will be in the same order here than in plupload
if(map[file.name] === undefined) {
map[file.name] = [];
}
map[file.name].push(path);
});
} else if (item.isDirectory) {
dirReader = item.createReader();
dirReader.readEntries(function (entries) {
var n = 0;
for (n = 0; n < entries.length; n++) {
traverseFileTree(entries[n], path + item.name + "/");
}
});
}
};
// bind another handler to the drop event to build an object representing the folder structure
document.getElementById('drop-target').addEventListener('drop', function(e) {
var items = e.dataTransfer.items, n, item;
for(n = 0; n < items.length; n++) {
item = items[n].webkitGetAsEntry();
if(item) {
traverseFileTree(item);
}
}
}, false); |
After looking into implementing a version of foaly-nr1's workaround above, I realized that there are indeed some issues that need to be addressed, and it's probably a bad idea to go too far down this road right now. There doesn't seem to be any API for getting the path of a File that is widely supported by browsers. The webkitGetAsEntry() call in foaly-nr1's code (which provides an Entry) is a part of the FileSystem API, which is apparently dead ("Work on this document has been discontinued and it should not be referenced or used as a basis for implementation.") as of April 2014 (via html5rocks.com) and is obviously not well supported in browsers other than Chrome and Opera. The other API for handling files that does seem to be supported widely is the File API, but that API doesn't seem to support anything that would allow a developer to get ahold of the path. Point being, it seems that it would be a bad idea to depend on this feature even if it is incorporated in plupload at this time, based on the state of the relevant web specifications. While I don't agree with jayarjo that having the feature itself would be confusing, even if it were not fully supported by vendors--clearly there is developer demand for this, and developers can choose to ignore anything they don't feel comfortable implementing for whatever reason--otherwise I would agree it shouldn't be incorporated because it doesn't seem likely to be supported in the future. I'd love to be shown to be wrong here--but as far as I can tell, the deceased FileSystem API is the only API that provides path information for files in conjunction with the Drag-and-Drop API. It also follows, sadly, that foaly-nr1's workaround is probably not a good thing to rely upon even in Chrome or Opera, as there is no guarantee this API could be available in any future releases. |
Follow-up counterpoint from my boss, for your consideration:
|
I have merged this code into my pluploader, we have this on a live system and works well.
|
More information about @tsmgeek's fix (since I was just about to submit essentially the same fix): The root cause of the issue is that the code isn't following the Basic Concepts of the DirectoryReader class. See this StackOverflow post for details. |
Great news, thanks @jayarjo! |
How to make that property be posted? |
Chrome 21 implemented the possibility for folder drag & drop.
This patch adds a "relativePath" property to each instance of
plupload.File
.Example: http://protonet.github.com/plupload/examples/drag_and_drop.html
More details to the chrome implementation: http://wiki.whatwg.org/wiki/DragAndDropEntries
Chromium issue: http://code.google.com/p/chromium/issues/detail?id=99823
Also this patch makes sure that the default behavior within
dragover
is only prevented when the drag contains any files otherwise there will be problems when eg. thedrop_element
is a<textarea>
and the user is dragging text around.