DragDropMultiUpload-Talk

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

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

Please open a new section below this line.


Icons came back

It looks like in the current ddmu.zip archive icons are still provided. In ddmu.zip v20200612 there were only 3 files in pub\ddmu\: ddmu.css , ddmu.js and unverse.js

Finar

Thanks, file reuploaded. --Petko

Bugs with 'b' and icons

I've found two small bugs, see screen:

1) Icon's are lost on clean PmWiki v2.2.117 using FireFox 75.0

2) Look at the tooltip: there is a parasite 'b' letter in the end. The problem is on this line in ddmu.js :

 t = t.replace('$upmax', DDMU_max_size[ext]) + 'b'

I think this 'b' should be just removed, because of it is not needed in English and all the more so in other languages.

Finar May 07, 2020, at 04:34 PM

1) Icons were removed in "20180112 ... Replaced picture icons with Unicode characters" which are much, much faster to load -- I've removed the icons from the archive. 2) Thanks, this was fixed in 20200507 -- the "b" stood for "bytes" and I guess at some point the strings ended with the max number of bytes, just the number so the "b" was needed. Not now. --Petko May 07, 2020, at 05:13 PM

There is still a problem with removed icons. They are requested by the script, so we get multiple 404-errors. The problem is on line #1 in ddmu.css and around line #152 in ddmu.js. Finar June 12, 2020, at 03:18 PM

Thanks, released 20200612 now. --Petko June 12, 2020, at 04:06 PM


Restrict drop window to certain pages?

Is is possible to restrict the feature to specific pages?

I love DDMU. Thanks for making it. —Bernie Walp walp@hawaii.edu

Yes, it is possible to enable the recipe only on certain pages or groups, see PmWiki:GroupCustomizations. For example, if you only want to enable this in the group Photos, you create a file Photos.php inside the directory "local" (under index.php, next to local/config.php) and in that file you add "<?php" at the top then the installation code from the documentation. You need to remove the installation code from config.php. If you want to enable it in another group, you add another file, like local/Main.php. If you want to enable it in a specific page, say [[Group.Page]], you create a file local/Group.Page.php. --Petko April 21, 2020, at 09:01 AM


File name with spaces

Was your intention to leave spaces in the file name as is or to replace them with underscores? I would much prefer the latter but in my tests ddmu 20190509 keeps spaces intact. I prefer automatic space replacement because the occasional uploaders will not remember instructions to remove spaces from the uploaded file names, and will not know that [[Attach:picture with space.jpg]] works to insert a working link to a "picture with space.jpg" but Attach:picture with space.jpg doesn't work to insert a picture (see ddmu.js lines 113-114). Looking at js function handleFile I noticed that var name is set but never used, I think. This makes me hope that at some point you decided to do replace spaces but missed to update that line or thereabouts. --SteP January 29, 2020, at 10:57 PM

DDMU doesn't do anything to file names, it is the same as if you upload your files with ?action=upload. OTOH Mini has an option to rename (image) file names with spaces when it first downscales one. If you want to configure PmWiki (and DDMU) to replace spaces with underscores when a file is uploaded, you can add this in config.php:
$UploadNameChars = "-\\w. "; # unless you have a custom one
$MakeUploadNamePatterns = array(
    "/[^$UploadNameChars]/" => '',
    '/(\\.[^.]*)$/' => 'cb_tolower',
    '/^[^[:alnum:]_]+/' => '',
    '/[^[:alnum:]_]+$/' => '',
    '/ +/' => '_');

The last line is what is different from the default configuration, it replaces one or more consecutive spaces with one underscore. Note that if you have any uploaded file with spaces, they will become invisible to PmWiki, Attach: links will lead to the upload form. You will need to manually rename the file to replace spaces with underscores. --Petko January 30, 2020, at 05:57 AM

Looking at the handleFile() code, I forgot but yes, apparently my intention was to rename the file from spaces to underscores, but it doesn't work and wouldn't work because that property is read only. I should have added a separate 'upname' field like the one in the upload form but I haven't and now that people have been using this for years I will not change it. --Petko January 30, 2020, at 05:57 AM

Thank you. I will implement your suggestion and rename files with spaces using $MakeUploadNamePatterns. I do use a custom $UploadNameChars, and file renaming with Mini. Therefore, I also need to set $Mini['FixFilenamesPatterns'] consistently with the aforementioned upload variables. --SteP January 30, 2020, at 06:07 AM, edited 2022-09-14.


Optimization: base64 encoding icons

As part of my attempts to optimize my PmWiki-based sites, I'm trying to cut down on the number of HTTP requests that need to be made for pages to load. Here's a tweak that I made to DDMU:

I replaced the file URLs of the five icons (the red X, green checkbox, etc.) in ddmu.css with data URIs containing base64-encoded versions of those images. (That way, the browser does not have to make separate HTTP requests for each of the five images—they’re simply included in the CSS file.)

Here is the modified CSS file: Attach:ddmu_with_base64_encoded_images.cssΔ. (If you download and use it, in place of the CSS file included with the recipe, make sure to rename the file to just ddmu.css.)

Note that if this modification is made, lines 150–154 of ddmu.js should be commented out, as they are no longer necessary (and if you don’t comment them out, that defeats the point of this tweak!).

Said Achmiz January 10, 2018, at 09:53 PM

You can replace the existing file with this one without having to re-do it on upgrades with this line:

  $HTMLHeaderFmt['ddmu.css'] = "<link rel='stylesheet' 
    href='\$FarmPubDirUrl/ddmu/ddmu_with_base64_encoded_images.css'
    type='text/css' media='screen'/>";

I am thinking about even dropping the pictures entirely and instead use some text characters like colored squares. It will be even lighter, and people could more easily style those, see the "Colors" section below. --Petko January 11, 2018, at 03:58 AM

Thanks for the tip on replacing the file! I hadn't noticed that.

Re: text characters: great idea! If you decide to do that, I have a request—could you offer a config parameter, that would let me specify which character is used for which result? (Just an array or something…) Here is why I say this: if I could specify custom characters, then I could use icons from Font Awesome (which I already use elsewhere on my wikis). (Of course I would set a style that specified the Font Awesome font for that element.)

Said Achmiz January 11, 2018, at 01:04 PM

You probably don't need a special config parameter, see the CSS ::after pseudo-element and the Fontawesome cheatsheet:

  .ULsuccess a::after { content: "\00a0\f00c"; font-family:"FontAwesome"; } /*nbsp, fa-check*/

To place the CSS glyph codes, get the Unicode entity from the cheatsheet like [&#xf1f4;] and write in your css backslash+the_hex_part_of_the_entity "\f1f4".

In the next DDMU version instead of many different CSS classes for failure, there will be only ULsuccess, ULfailed and ULlogin. --Petko January 12, 2018, at 08:51 AM

Good point! If the characters are placed via pseudo-elements, then indeed no config parameter is needed. Looking forward to the new version—thanks! —Said Achmiz January 12, 2018, at 12:33 PM

Bug with wrong results shown when uploading

DDMU was showing the "error" icon (red file name with an X/trash-can) even when the files were, in fact, being uploaded successfully!

I tracked the problem down to the onreadystatechange handler in fileUpload() in ddmu.js. Here is how I rewrote it:

  xhr.onreadystatechange = function() {
    if (xhr.readyState == 4 && ((xhr.status == 200) || xhr.status == 304) && xhr.responseText != "") {
      var F = file.name, R = 'unknown_error';
      //&uprname=K.png&upresult=tquota
      if(xhr.responseURL.match(/uprname=([^&]+)(&|$)/)) F=m[1];
      if(xhr.responseURL.match(/upresult=([^&]+)(&|$)/)) R=m[1];
      if(xhr.responseText.match(/name='(authpw|password)'/)) R='login';
      AddFileToList(file.name, R, ext, F);
      processQueue(1);
    }

Now the problem is gone and all seems to be working properly.

Said Achmiz November 04, 2017, at 02:50 AM

You probably have some custom $UploadRedirectFunction, if so, you should disable it when there is a $_REQUEST['ddmu'], see ddmu.php (and the latest ddmu.js should work). If it comes from another recipe, include that other recipe before ddmu.php. BTW the code above will likely fail to catch any file renames and may not show the reason for an upload failure (the m variable is undefined). --Petko November 04, 2017, at 03:33 AM

Whoops! Good point re: m being undefined, my mistake. And I will try switching recipe order around—thanks! Said Achmiz November 04, 2017, at 02:11 PM

Update: I checked—there is no custom $UploadRedirectFunction in any of the other recipes I have installed! Here is why I figured that the problem is in ddmu.js in the function I noted:

The code looks for uprname and upresult in xhr.responseText (which has been assigned to the reply variable). But why should those things be in responseText? They will be in responseURL, no? I checked the documentation and it seems to match my understanding of what these things do, but it is possible I am misunderstanding something...

P.S. Updated version of my rewritten bit of code is like so:

  xhr.onreadystatechange = function() {
    if (xhr.readyState == 4 && ((xhr.status == 200) || xhr.status == 304) && xhr.responseText != "") {
      var F = file.name, R = 'unknown_error';
      //&uprname=K.png&upresult=tquota
      var m = xhr.responseURL.match(/uprname=([^&]+)(&|$)/);
      if(m) F=m[1];
      var n = xhr.responseURL.match(/upresult=([^&]+)(&|$)/);
      if(n) R=n[1];
      if(xhr.responseText.match(/name='(authpw|password)'/)) R='login';
      AddFileToList(file.name, R, ext, F);
      processQueue(1);
    }
  }

Said Achmiz November 04, 2017, at 02:25 PM

The current version, when you upload a file with DDMU, it will not redirect (responseURL) to the ?action=upload URL like the regular PmWiki upload mechanism but will simply print (responseText) that URL, see ddmu.php, function DDMURedirect. That's why, as your code works for you (and not for me, in any browser), I assumed something is actually redirecting to the URL, and that would be the case if $UploadRedirectFunction was hijacked. One such recipe is Worse. You can try disabling all your customizations/recipes/skins (except DDMU) and test the recipe while re-enabling them one by one until you find what's causing it to fail an upload. --Petko November 05, 2017, at 09:27 AM

Do you by any chance include ddmu.php conditionally? If so, it should be included when $action is 'postupload' in addition to 'edit' and/or 'upload' and/or 'browse'. --Petko November 05, 2017, at 09:35 AM

Yes, I do include DDMU conditionally! I will test this fix and report results, thanks! —Said Achmiz November 05, 2017, at 12:11 PM

Update: The conditional include was exactly the problem. Adding 'postupload' to the actions under which ddmu.php was included, solved it. Thank you!! (And thank you for being patient with my confusion :) —Said Achmiz November 06, 2017, at 02:15 PM

Absolute ref for Attach link

DDMU is a great repice that provide a more user friendly page edition. But the "Attach:file.ext" link doesn't allow to include page in a different group without breaking the attachment reference ( this is a normal and logical behaviour of pmwiki ). In this case, the "Attach:" link need an absolute reference like : "Attach:Group.PageName/file.ext".

To do that we need to change the lines 108 to 109 of the pub/ddmu/ddmu.js file (diff command out):

108,109c108,109
<       if(f.indexOf(' ')<0) {insMarkup('', '', 'Attach:'+f);}
<       else insMarkup('', '', '[[Attach:'+f+']]');
---
>       if(f.indexOf(' ')<0) {insMarkup('', '', 'Attach:{$FullName}/'+f);}
>       else insMarkup('', '', '[[Attach:{$FullName}/'+f+']]');

Would be cool if this will become the default behaviour of ddmu.

Antony Templier May 13, 2013, at 03:47 PM

Sorry for the late reaction, this can be a useful feature. You can now set in config.php $DDMUEnableAbsoluteAttachLinks = 2; to achieve this, see recipe documentation. --Petko


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

IE10 is finally supported. Previous versions of IE didn't work because they didn't have the required functions. --Petko July 24, 2012, at 10:23 PM

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. --Petko March 14, 2012, at 04:53 AM

The new version released today can have a "queue mode" where the files are uploaded one after another and not in parallel. To enable it, add to config.php the line $DDMUEnableQueue = 1; This should be just a little slower but safer for the RecentUploads pages. --Petko July 24, 2012, at 07:31 PM


Custom Attach: link

Is it possible to customise the insertion Attach link, eg I would like to insert (:thumb "file.jpg" :) instead. Thanks simon August 18, 2012, at 05:10 AM

Not at the moment. This would require major changes of the recipe if you want custom insertions for selected file extensions. --Petko


Drop zone directive

The recipe really rocks. I'm using it on a club website and it makes it so much easier for people.

We use a page that has a small dialogue to attach files directly. Is it possible to have a directive that would insert a file drop zone in the dialogue? (see example)

simon September 30, 2012, at 09:27 PM

Yes, I was thinking that too often I'd like to drop a file on a page without having to go into edit or upload mode, so I'll think of something. (Not this week.) --Petko October 01, 2012, at 05:59 AM

This feature was added in the latest version. --Petko August 14, 2017, at 08:55 AM


Replaces existing files of the same name

If you drag and drop a file, and a file of the same name already exists, the uploaded file replaces the previous file. (actually I'd prefer an option to turn this behaviour off)

simon November 25, 2012, at 03:05 AM

This is a PmWiki option, not DDMU. See $EnableUploadOverwrite. --Petko November 25, 2012, at 07:59 AM


Still beta?

Hi Petko, that's a great recipe!

I wonder why it's still marked "beta" - do you see any risk using it?

OliverBetz 2012-12-27

No, there are no known problems or risks. But I feel it is not yet extensively tested, and I have some ideas for improvements (unfortunately not too easy to do). It should be about as bad as my other recipes. --Petko December 26, 2012, at 12:36 PM


File sizes larger than 50000 bytes

HI! Thanks for the recipe! I'd like to know if I can add things like powerpoint presentations using this recipe. The files are larger than the 50000 byte limit, so I'd either have to change the limit (which I haven't figured out how to do), or refer to another recipe. Can you please advise me?

This is a PmWiki setting, not a DDMU one. See UploadsAdmin about the variable $UploadMaxSize. --Petko March 08, 2013, at 11:46 AM


I have

  $UploadMaxSize = 10000000; ## bytes 10MB 
  $UploadExtSize['jpeg'] = 10000000; #  limit .jpeg files to 10MB 
  $UploadExtSize['jpg'] = 10000000; #  limit .jpg files to 10MB 

but I get file too large error for files > 4MB. What settings/variables controls the maximum file size for this recipe?

thanks, simon April 30, 2013, at 05:02 AM

The recipe doesn't set filesize limits, it uses the limits set for the upload function in PmWiki. If you can upload larger files with ?action=upload, I'll look into it - it may be possible that your browser doesn't see the correct filesize (if that's the case I don't know how could I fix it). If you cannot upload larger files with ?action=upload, see SystemLimits. --Petko April 30, 2013, at 07:38 AM


Not working on Snow Leopard Safari (5.1.10)

I thought there was something wrong with the recipe, but it works fine in Chrome. My Safari is the latest available for my OS (5.1.10). Xes? December 23, 2013, at 12:22 PM


Wondering if there is a unicode problem? simon February 15, 2014, at 11:32 PM

Probably: modern browsers are unicode, and the files on your operating system have unicode names; if your wiki doesn't have UTF-8 enabled, and if you drop files with international characters, and if you have changed $UploadNameChars, the default filename characters allowed by PmWiki, chances are that you'll see some problems. --Petko February 16, 2014, at 03:39 AM

Talk page for the DragDropMultiUpload recipe (users).