Extension talk:SimpleBatchUpload

Jump to navigation Jump to search

About this board

Regis May (talkcontribs)

I was quite surprised to learn that files are uploaded immediately as soon as you drag&drop files. This was all the more surprising as my first two uploads failed because of a CSRF token error (as the token has timed out already).

If this immediate upload behavior is intended, I'd expect it at least to be ...

  • documented on the MediaWiki extension description page and
  • even more important: documented on the special page <tt>Spezial:BatchUpload</tt> itself.

It is a good extension - thank you very much for that! But please explain the behavior so that users know what will happen if they use this extension.

Every single upload normally would be implemented with first providing the files, then submitting them. That's what users would expect. That's what they assume in the first place. It's okay if this extension differs from this expected behavior, but then please document it/explain it! ;-)

Nevertheless: Thank you again, nice extension!

F.trott (talkcontribs)

Well, it is called Simple for a reason. :)

But you may have a point. Could you add a note to the Extension's wiki page?

For adding the note to Spezial:BatchUpload you could raise an issue (or even a pull request) at https://github.com/ProfessionalWiki/SimpleBatchUpload

As a stop-gap measure, maybe you could customize the button text by changing the MediaWiki:Simplebatchupload-buttonlabel page in your wiki. Something like "Drop files for immediate upload". See Help:System message#Overriding messages on-wiki

Reply to "This is irritating"

id attribute on textarea makes the HTML invalid with multiple batch upload forms

1
Joeytje50 (talkcontribs)

With the change that implemented a textarea that allows you to customise the description for uploads, without needing to edit the page, the simple batch upload currently features an element with a non-unique id attribute. This makes the HTML invalid, which may cause unexpected behaviour when trying to run JavaScript applicable to #wfUploadDescription, since that id will be reused for every batch upload textarea.

The solution would be to simply remove the id attribute from the textarea, or to give the id a unique number, for example by keeping track of a counter variable within the extension.

Reply to "id attribute on textarea makes the HTML invalid with multiple batch upload forms"

No thumbnail created for PDFs uploaded using SimpleBatchUpload

1
Jonathan3 (talkcontribs)

Do you know why this might be? I'm using MW1.34 and SBU 1.7.0-alpha. Thanks.

Mostly on my wiki thumbnails are created on upload. When I purge the File: page they get created also.

Reply to "No thumbnail created for PDFs uploaded using SimpleBatchUpload"

Comments without curly brackets

2
77.59.183.2 (talkcontribs)

Is there a way to add comments without automatically adding curly brackets? For example, i want the files comment to say: [[Category:Some Category]] {{some page}}

Joeytje50 (talkcontribs)

Yes, there is, although it's a pretty convoluted system. The way to do this is to make a kind of wrapper template, let's say we call that Template:Plaintext. Then if you use a BatchUpload box like this:

{{#batchupload:subst:plaintext|[[Some Category]] {{some page}}}}

and simply put {{{1|}}} on the template page, that should just output whatever you entered as the first parameter.

Note that it might also be useful to use the same trick on MediaWiki:Licenses (and possibly change MediaWiki:License accordingly). The template you're substituting can be as complicated as you want. It's also possible to use switch statements in that plaintext template, for example. As a demonstration of one implementation you can see this template (also see the relevant MediaWiki messages I linked on that wiki).

Reply to "Comments without curly brackets"

Server communication failed

5
Summary last edited by MyWikis-JeffreyWang 07:05, 8 December 2020 5 months ago

SimpleBatchUpload seems not to play well with MW 1.31.1 + PHP 7.3. Fixed with MediaWiki 1.31.10 + PHP 7.4.

FrugalTPH (talkcontribs)

I keep experiencing an ERROR: Server communication failed, for any file I try to upload. I can upload the files in question successfully using the default mw file uploader, though. Any idea what could be causing this?

I have the following set in my Localsettings.php: $wgEnableUploads = true; $wgEnableWriteAPI = true;

F.trott (talkcontribs)

No idea, unfortunately.

FrugalTPH (talkcontribs)

Thanks for getting back to me. I actually resolved this myself last week.

The issue was my shared hosting was set to use PHP7.3, and I my wiki is on version 1.31.1, which had some known bugs regarding PHP7.3. I tried updating to mw 1.31.4 & 1.31.5 (which apparently have fixed the bugs), but then I had other compatibility issues involving other extensions. In the end I rolled back to 1.31.1, and changed my server's PHP version to 7.0, which seems to be better supported on the whole.

Madrigal84 (talkcontribs)

Our group has been using Extension:SimpleBatchUpload (1.5.0) extensively, but unfortunately we are running into an issue where files are uploaded but fail to be written as a row in the **_fileData** MW db table or saved to our Cargo db table. To the end user error appears as red highlighted text: ERROR: Server communication failed. We have checked our web server logs during uploads but cannot identify any server issues. Currently running MediaWiki 1.31.1, PHP 7.2.11 (apache2handler). Thank you for your help.

MyWikis-JeffreyWang (talkcontribs)

PHP 7.4 + MediaWiki 1.31.0 was broken. Upgrading to 1.31.10 fixed it.

breaks on Mediawiki 1.31.0

9
Summary by MyWikis-JeffreyWang

Fixed by upgrading to MediaWiki 1.31.1+

Postprefix (talkcontribs)

[05-Jun-2019 15:19:54 America/New_York] PHP Fatal error:  Uncaught UnexpectedValueException: callback 'SimpleBatchUpload\SimpleBatchUpload::initCallback' is not callable in /home/riotawfb/nosubject.com/includes/registration/ExtensionRegistry.php:360


possible conflict with other extensions...

Revansx (talkcontribs)

*follows* I'm setting up a new MW 1.31 system and have had problems with this as well. Haven't had time to troubleshoot it yet. All I know is that it fails to load for some reason.

Mitchell316 (talkcontribs)

I'm also having the same issue with the SimpleBatchUpload extension. Any word on a fix or new version?

F.trott (talkcontribs)
F.trott (talkcontribs)

Can you all confirm that you installed either the SimpleBatchUpload.1.4.0.with.dependencies.tar.gz or the SimpleBatchUpload.1.4.0.with.dependencies.zip file or used Composer for installation.

In particular, can you confirm that you did NOT

  • do a git clone
  • use the "Download ZIP" link on GitHub.
Mitchell316 (talkcontribs)

Yes, I downloaded from the .tar.gz file.

Revansx (talkcontribs)

I'm running this successfully on 1.31.1 fwiw

F.trott (talkcontribs)

I updated the extension over the summer to simplify installation and do CI testing (incl. on MW 1.31). I intend to release v1.5 in the next days.

Revansx (talkcontribs)

Troubleshooting "ERROR: Invalid token"

1
Summary by Oznogon

Try clearing all browser cookies for the wiki in question if uploads fail with "ERROR: Invalid token".

Oznogon (talkcontribs)

No action necessary, just writing this down in case it helps anyone else.

Uploading via SimpleBatchUpload might fail with "ERROR: Invalid token", confirmable from watching network requests in browser devtools for a 200-code response to upload POST requests that notes the invalid token in the response body.

It might happen if user groups or rights for that user are modified during an active session. Logging out and logging back in does not resolve the problem; you must also clear all browser cookies for the wiki in question.

Issue with latest version of SimpleBatchUpload on MW 1.35

2
Ti infotrad (talkcontribs)

MW 1.35, SimpleBatchUpload 1.6

Symptoms: No drop area on upload page (just a file upload button), error on Chrome console stating jquery.ui.widget is deprecated


Fix: in src/SimpleBatchUpload.php, replace

'dependencies' => [ 'jquery.ui.widget' ],

with

'dependencies' => [ 'jquery.ui' ],

Kghbln (talkcontribs)
Reply to "Issue with latest version of SimpleBatchUpload on MW 1.35"
Jonathan3 (talkcontribs)

Would it be possible to add this as an option in the extension? See below:

"I edited res/ext.SimpleBatchUpload.js around line 54 to include this new parameter ("sequentialUploads: true,": ... dropZone: $( '.fileupload-dropzone', container $ sequentialUploads: true, progressInterval: 100,"

See: https://github.com/ProfessionalWiki/SimpleBatchUpload/issues/25

Reply to "Option for sequential uploads"

ERROR: Could not delete lock file for "mwstore://local-backend/local-public/archive".

6
Jonathan3 (talkcontribs)

I get this message for about a tenth of files uploaded, at various upload "percentage" stages.

The files themselves are uploaded all right.

But I wonder whether there will be any consequences of the error. Can anyone let me know? Thanks.

F.trott (talkcontribs)
Jonathan3 (talkcontribs)

Thanks. I'll have a look at that. I have also put this on on the Support Desk at Topic:Vtttk3n0syhmo99l in case it's a more general problem.

Jonathan3 (talkcontribs)

Thank you for the almost-immediate response! I have made the same change as suggested by the user there (i.e. sequential uploads only) and for the first time had no errors when uploading my next batch of 10 files.

Would it be possible to add this to the extension as an option? Otherwise I'll lose it on each upgrade... Thanks.

Jonathan3 (talkcontribs)

I uploaded a further batch of 20. Four of them didn't go as far as "OK"... they were 99, 93, 99, 98%... but the files, as before, were uploaded OK.

So maybe some underlying problem is causing both problems (i.e. the original lock error, and the non-OK text).

Jonathan3 (talkcontribs)

On the latest batch, of 18, only one didn't say "OK" (the 8th one went to 97%).

For some reason, I'm happier with this than I was with the database lock error, though I suspect it's the same problem!

I would be happy to turn on any debugging mode you suggest to help you get to the bottom of it.

Reply to "ERROR: Could not delete lock file for "mwstore://local-backend/local-public/archive"."