• View
• Edit
• History
• Attach
• Print
• Backlinks

DragDropMultiUpload-Talk

Please open a new section below this line.

Core configuration

Fantastic to see this recipe built-in, thanks.
Are the configuration $variables still functional or required?

No, the other configuration variables are no longer used. A dropzone is enabled but not for the "browse" action; queue is always enabled (rewritten and better); absolute attach links are inserted if the Ctrl key is held down; there are no icons to preload. --Petko August 10, 2024, at 07:46 PM

To enable a dropzone in a "browsed" page (in addition to the edit/upload forms), use something like this:

(:input form action={*$PageUrl}?action=postupload:)
Your name: (:input e_author form=none:)
(:input end:)

The e_author field is only needed if $EnableUploadAuthorRequired or $EnablePostAuthorRequired are enabled. --Petko August 10, 2024, at 09:10 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

$UploadNameChars = "-\\w. "; # unless you have a custom one
$MakeUploadNamePatterns = array(
    "/[^$UploadNameChars]/" => '',
    '/(\\.[^.]*)$/' => 'cb_tolower',
    '/^[^[:alnum:]_]+/' => '',
    '/[^[:alnum:]_]+$/' => '',
    '/ +/' => '_');

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

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

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

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

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

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

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

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

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...

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

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

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

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

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)

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)

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?

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