Recent Changes - Search:

Cookbook

PmWiki

pmwiki.org

DragDropMultiUpload-Talk

Summary: Talk page for DragDropMultiUpload.
Maintainer: Petko
Users: +6 (View / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.

Smaller drop target

Some browsers (I use Chrome) allow drag+drop onto file controls. I use this a lot when I want PmWiki to rename the file after upload, but with DDMU I can't do that any more. Can you make the drop target smaller, like the one you get in GMail, or just put the form control above it in the z-order? It looks like the form element could be raised and look reasonable, if confusing for users on other browsers...

Alternative idea: if it's an upload page, and there's a filename, and a single file is dropped, ask the user if they want to rename after upload (and then maybe just submit the form normally, no AJAXiness).

Maxim? August 25, 2011, at 11:12 PM

Thanks for the idea. Today's version lets you set the filelist as a drop zone instead of the whole page. I like both ways. To enable the drop zone only for the uploads page, use the following code in config.php. ---Petko August 25, 2011, at 10:48 PM

  if ($action == "upload") $DDMUEnableDropzone = 1;

Colors

The colours in ddmu.css don't work very well on dark backgrounds (mine is #069). I'm not sure what would be the best approach - setting the background-color would make it readable but ugly, and overriding it in my own skin CSS would be tricky as the specifiers are rather long and subject to change. This is not the first recipe I've had this problem with...

#069

red green orange

Black

red green orange

Pathological case

red green orange

This might work...

red green orange

Maxim? August 26, 2011, at 06:26 AM

I agree. Maybe the least bad solution is to inherit the site colors. Add to config.php such a line:

  $HTMLStylesFmt['myddmu'] = "#DDMU a {color: inherit !important;}\n";

The filenames will thus be the same color as your other text in the page, and can still be differentiated by their styles (normal, italic, strike-trough) and the icons (unfortunately on white background). --Petko August 26, 2011, at 07:15 AM


No Joy on IE8

I have not been able to get this to work on Internet Explorer 8. When I drop the jpg file on the target, the browser simply opens the image file. Or am I missing something? Has anyone had similar luck? I dont have another browser to try at the moment. BruceK? Sept 5, 2011, at 03:12 PM

Correct, the recipe doesn't work in IE because IE doesn't have the required functions. On a Windows system, you can get the free Firefox or Google Chrome browsers. It might work in IE with the Chrome frame plug-in, but you may need to add to config.php such a line:

  if($action=='edit' || $action == 'upload')
    $HTMLHeaderFmt['chromeframe'] = '<meta http-equiv="X-UA-Compatible" content="chrome=1"/>';

If you test it, please report if it works. --Petko September 05, 2011, at 11:52 PM


Not working on FF 8?

I've tested it with Firefox 8.0.1 on GNU/L and it's not showing any kind of message while trying to upload on the edit page. However, Chromium 15.0.87... works as expected. Any hint? --simkin December 06, 2011, at 04:44 PM

It looks like it works for me, just installed firefox amd64 8.0+build1-0ubuntu0.11.04.3 and tested it on the edit and upload page, both with and without a dropzone. Can you give me more information about your installation? Other JavaScript libraries may cause a conflict. --Petko December 18, 2011, at 03:01 PM

I'm not sure where is the problem. You can check our sandbox. DDMU works just fine with Chromium. On FF, the dark screen with the down arrow is shown, but nothing happens when mouse click is released. Opera doesn't seems to work at all. --simkin December 19, 2011, at 09:29 AM

Looks like mine is the only FF not working, from other computers it works ok. I'll try to reinstall or change my FF version and report. --simkin December 19, 2011, at 01:43 PM

I was able to upload a file to your sandbox without a problem. Could this be some browser extension/proxy issue? --Petko December 20, 2011, at 04:13 AM

Finally I found out the issue is related with the desktop file browser itself. I'm using Thunar as my regular file browser and dropping from it works on chromium but not on firefox. If I use Nautilus instead, dropping works for both browsers. So, in the end, it turned out the issue was not related with DDMU. Thanks. --simkin December 22, 2011, at 05:54 PM


Recent changes loss?

I've had a lot of cases of truncating my Site/AllRecentChanges, $Group/RecentChanges and $Group/RecentUploads which seem to be very aligned to using this to upload multiple images at the same time. I suspect it must be a bug in the PmWiki core upload functionality, possibly related to enabling $RecentUploadsFmt ? Maxim? March 13, 2012, at 02:08 PM

Thanks for the report, it is likely a problem when multiple instances of PmWiki read and edit the RecentUploads pages at the same millisecond. I'll investigate it although I'm not quite sure it is fixable. UpdateMe --Petko March 14, 2012, at 04:53 AM

Talk page for the DragDropMultiUpload recipe (users).

Edit - History - Print - Recent Changes - Search
Page last modified on March 14, 2012, at 04:53 AM