-
A quick little plugin, this takes advantage of modern browser's ability to upload via XHR(AJAX). Features :
- Supports multiple selection, drag and drop into attachments area
- Shows progress of the current upload
- Supports client side validation of attachments including file size
Note that these features will only work on modern browsers with support of XHR upload, for older browsers it will resort back to default behavior.
Thanks :)
-
Why don't have this in core (with a fallback to older browsers)? :)
-
Agree. It could be good if it in core with (Not working? Try simple uploader) -mode-
-
As I understand it, it would need to be rewritten again to work with the attachment uploader currently in Wedge (which, you'll notice, is not the same one SMF has)
-
As I understand it, it would need to be rewritten again to work with the attachment uploader currently in Wedge (which, you'll notice, is not the same one SMF has)
Posted: March 21st, 2012, 02:20 PM
Agree. It could be good if it in core with (Not working? Try simple uploader) -mode-
-
I don't really have a problem with this being core, if someone wants to rewrite it (because I don't), but it doesn't bother me if we don't either, as I'm happy enough with the current attachments stuff, current bug with it notwithstanding.
-
I had a fairly good idea for this plugin that I forgot. Damn I need to take more notes.
-
I know that feeling. I've forgotten a good many ideas that way.
-
I vote for core. With all my heart.
-
I have no objections to it being core if someone wants to do the work necessary to integrate it with what we have, handle limits and so on. It's just not something I've been too concerned about; the core has something better than what SMF had, and it is more usable (even if it has one side bug) but this would make it awesome. I just don't have the brain power to implement it myself right now.
-
Thanks :), I'd rather have it as a plugin now(Even if it becomes an official one), because I don't see it being much prettier(code wise) even if integrated into core itself. Plus I'm too lazy to do that ATM :P, although I'll try to take a look at it in a while.
-
Now supports client side validation and I improved the drag and drop area.
Updated first post with screenshots.
-
Nice indeed! :cool: :cool:
-
Sexy plugin. Could leave it as plugin and include it later in core if its popular.
-
We can indeed do that too :)
-
Agree. It could be good if it in core with (Not working? Try simple uploader) -mode-
-
Agree. It could be good if it in core with (Not working? Try simple uploader) -mode-
-
guys, how can I download this plugin?
-
guys, how can I download this plugin?
-
Yeah, lol...
Silly as it sounds, though... How can I download this plugin?
What, we sure could use it on wedge.org itself... :lol:
-
Guys, guys.
If we can get our hands on this plugin, maybe we can create a GUI interface using visual basic to get our hands on the Wedge sourcecode!
www.youtube.com/watch?v=hkDD03yeLnU(http://www.youtube.com/watch?v=hkDD03yeLnU)
-
Uploaded this to AeMe as well, after adding a little fix to prevent form submission during upload (translation required here Nao :P). Again, this has the full potential to kill your cat. Don't blame me.
-
Very nice, like this a lot :cool:
-
Dragooon, I'm still waiting for your approval to change the author ID to Wedgeward
-
It gives a friendly interface and thats always good. :)
-
/mebangs the core feature drum :P
Trouble with making things into core features is that I'm not a fan of 'core plugins' and that prevents easy linkage back to repos.
-
Remember the bug where a selected word in the posting box being dragged would trigger this plugin's event? That's why it was removed from this site...
BTW, whatever became of the ambitious dream to replace attachments with media items?
-
Sure I remember that. I'm still convinced it's ultimately not a blocker for it being a core feature, but simply that the selector is not as selective as it should be about grabbing events.
Mostly I think Nao and I have been quietly hoping the other will have a sudden idea on how to solve the architectural issues that come out of it but I think that in the end I'll just have to go in and do it. There is one aspect to it that is rather awkward to solve but not unsolvable, it's just figuring out how to do it without breaking the crap out of everything.
-
Sure I remember that. I'm still convinced it's ultimately not a blocker for it being a core feature, but simply that the selector is not as selective as it should be about grabbing events.
-
Remember the bug where a selected word in the posting box being dragged would trigger this plugin's event? That's why it was removed from this site...
BTW, whatever became of the ambitious dream to replace attachments with media items?
-
And fixed(https://github.com/Dragooon/MultiAttach/commit/eb7b58e7c5f69edc7453a34749e3594ac7c3e057) (lightly tested, didn't do a cross browser test), also merged the changes Nao did in Plugin repository
Sure I remember that. I'm still convinced it's ultimately not a blocker for it being a core feature, but simply that the selector is not as selective as it should be about grabbing events.
-
Dragooon, I'm still waiting for your approval to change the author ID to Wedgeward
Well, the plugin isn't "public" yet, so I didn't bother to ask you too much.I didn't even know there was an alternative copy of this plugin in Wedge's plugin repository :P.
I don't mind the author ID change, but there has to be a better way to maintain the repository. Can't it be some sort of svn:external with the master in my GitHub account?
Posted: March 11th, 2013, 04:49 PM
Remember the bug where a selected word in the posting box being dragged would trigger this plugin's event? That's why it was removed from this site...
I don't even know what bug you're talking about.BTW, whatever became of the ambitious dream to replace attachments with media items?
-
And even if it does become a core feature, it won't work nicely through externals because core feature implies not being bridged through the plugin manager... so it would need to be a separate tree anyway.
I don't even know what bug you're talking about.
It is currently disabled but there's other reasons why that might be (as other plugins are also disabled without any reason I'm aware of for that)
-
Hmm, didn't get a "new post" warning when sending the last one, even though I'd posted another... Maybe because it was one of mine..?
Sure I remember that. I'm still convinced it's ultimately not a blocker for it being a core feature, but simply that the selector is not as selective as it should be about grabbing events.
Mostly I think Nao and I have been quietly hoping the other will have a sudden idea on how to solve the architectural issues that come out of it but I think that in the end I'll just have to go in and do it. There is one aspect to it that is rather awkward to solve but not unsolvable, it's just figuring out how to do it without breaking the crap out of everything.
But really, the real reason, in reality, is really that, really, I'm super-fucking lazy and I try to focus on features that require less than a week to implement... And this one... It even requires writing a converter!! Eh!! And I'm not going to ask TE to do it... :^^;:
-
Hmm, didn't get a "new post" warning when sending the last one, even though I'd posted another... Maybe because it was one of mine..?
It's not an *architectural* issue (what's to be afraid of? Creating a generic "Attachments" album where all attachments will go..?
If you have an attachments system like that, you need to be able to reference the topic it came from, not so much for 'which topics use this' but 'can the person see this attachment'. Would really suck if attachments could be leeched without having proper board access.
Right now, access to a given file is based on its album. But that doesn't work for attachments whose access rights are implicitly different. Thus you need to be able to indicate where a given media item is supposed to get its authentication from, be that an album or thread access. Or, indeed, anything else you care to think of, e.g. helpdesk attachments.
I did suggest one method of doing this but you weren't very keen on it.
-
And I didn't get a warning for that post either...
Although I just got one for your latest, but it's because you posted it before I hit the Reply button, so I had the warning at post time, not post2 time, basically.
This needs fixing, because it will make people miss on posts, as they're expecting to be told when someone posted in the meantime...There was certainly a bug with it affecting events and at least once it was disabled for that reason.
It is currently disabled but there's other reasons why that might be (as other plugins are also disabled without any reason I'm aware of for that)
Posted: March 11th, 2013, 05:14 PM
Hmm, it should still have warned. Something is very much amiss.
The problem that I mention isn't that at all, I wouldn't mind but I have mentioned it multiple times now.
If you have an attachments system like that, you need to be able to reference the topic it came from, not so much for 'which topics use this' but 'can the person see this attachment'.
Hmm, does that imply creating a new album on the fly, matching these..? I don't know. I don't remember if AeMe has a setting to fine-tune permissions per-item. I'M NOT OLD!!! I'm just rusty.Would really suck if attachments could be leeched without having proper board access.
Right now, access to a given file is based on its album. But that doesn't work for attachments whose access rights are implicitly different. Thus you need to be able to indicate where a given media item is supposed to get its authentication from, be that an album or thread access.
I did suggest one method of doing this but you weren't very keen on it.
-
Did that happen after I restored your admin access, maybe..? Otherwise it must be a very old discussion, and I remember having the plugin enabled here...
It got disabled when I changed its name, but I'm pretty sure I re-enabled it...
That 'last' param in the URL... Is it only checked against correctly...?
Oh, don't talk down to your elders! I'm young enough to remember things! Well, at least part of the things! What was I talking about, already..?
Well, in some situations I suppose you wouldn't mind...
I'm of the opinion that this should be done at post time... i.e. if you post an attachment from within a certain topic, get the topic, then the board, get its group list, attach these groups to the item's permissions.
Or we could just store the id_board in the item table, yeah, and do a {query_see_board} on that.
We would need two columns: type and contextual id. For album items, this would be 'album' and the album id. For regular attachments this would be 'board' and the board id. Or topic id, actually, since there's per-topic privacy.
Then in the file server, you'd fetch the item, figure out what it wants to do to authenticate, check it, and if all good, serve it. The trick is making it extensible.
I don't remember why you weren't keen on it though.
-
Bug, I can't get the drop area to appear after dropping my first item. Will have a look at it in a while.
-
I installed your copy yesterday, but didn't look into it I have to admit.
-
I installed your copy yesterday, but didn't look into it I have to admit.