Extension talk:SimpleBatchUpload

Jump to navigation Jump to search

About this board

blank page after entering wfLoadExtension( 'SimpleBatchUpload' );

Summary by Kghbln

Make sure that Compser is either installed globally or in the correct directory.

Onebigear (talkcontribs)

I installed it with composer, and there is a SimpleBatchUpload directory in the extensions folder. However, as soon as I proceed to add the configuration to LocalSetting.php, my wiki page turns blank...

does anyone know what causes this problem?


php: v7.3.14-1~deb10u1

Kghbln (talkcontribs)

What does the server say? You should enable error reporting. I most cases this already will provide the decisive clues.

Onebigear (talkcontribs)

yes, here it is:

Fatal error: Uncaught UnexpectedValueException: callback 'SimpleBatchUpload\SimpleBatchUpload::initCallback' is not callable in /var/lib/mediawiki/includes/registration/ExtensionRegistry.php:438 Stack trace: #0 /var/lib/mediawiki/includes/registration/ExtensionRegistry.php(187): ExtensionRegistry->exportExtractedData(Array) #1 /var/lib/mediawiki/includes/Setup.php(143): ExtensionRegistry->loadFromQueue() #2 /var/lib/mediawiki/includes/WebStart.php(81): require_once('/var/lib/mediaw...') #3 /var/lib/mediawiki/index.php(41): require('/var/lib/mediaw...') #4 {main} thrown in /var/lib/mediawiki/includes/registration/ExtensionRegistry.php on line 438

Onebigear (talkcontribs)

I don't know if this helps: when composer installed the extension, SimpleBatchUpload is stored in a newly created extensions directory parallel to the mediawiki directory. I did the installation in /var/lib which contains both mediawiki and composer.phar

Inside mediawiki directory, there is original extensions directory that came with mediawiki installation. I moved SimpleBatchUpload to that directory.

Kghbln (talkcontribs)

> I don't know if this helps:

This explains why all of this is failing.

> I moved SimpleBatchUpload to that directory.

What happens if you do not move the files?

If this does not help I guess that the extension does not support the environment structure you are using. Not sure how to tell composer to adapt to it. Worth creating an issue report on GitHub for this.

Onebigear (talkcontribs)

I deleted the SimpleBatchUpload directory in mediawiki extensions. the error complained about the removal of the directory:

Fatal error: Uncaught Exception: Unable to open file /var/lib/mediawiki/extensions/SimpleBatchUpload/extension.json: filemtime(): stat failed for /var/lib/mediawiki/extensions/SimpleBatchUpload/extension.json in /var/lib/mediawiki/includes/registration/ExtensionRegistry.php:136 Stack trace: #0 /var/lib/mediawiki/includes/GlobalFunctions.php(52): ExtensionRegistry->queue('/var/lib/mediaw...') #1 /var/lib/mediawiki/LocalSettings.php(131): wfLoadExtension('SimpleBatchUplo...') #2 /var/lib/mediawiki/includes/Setup.php(124): require_once('/var/lib/mediaw...') #3 /var/lib/mediawiki/includes/WebStart.php(81): require_once('/var/lib/mediaw...') #4 /var/lib/mediawiki/index.php(45): require('/var/lib/mediaw...') #5 {main} thrown in /var/lib/mediawiki/includes/registration/ExtensionRegistry.php on line 136

I will try to:

  1. install composer for another time and try again.
  2. if above fails, I try to download the extension tar ball and extract
Onebigear (talkcontribs)

for reference:

after removal of the directory and I run php composer.phar update mediawiki/simple-batch-download

it complains: Package "mediawiki/simple-batch-download" listed for update is not installed. Ignoring.

Onebigear (talkcontribs)


thanks for identifying the directory problem in the first place.

I uninstalled composer, installed it in the /var/lib/mediawiki again. everything works fine now.

Kghbln (talkcontribs)

Yeah, indeed there is a difference in installing Composer globally or not. Great that it worked out. This will help others, too. Thanks for providing feedback!

Comments without curly brackets

1 (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}}

Reply to "Comments without curly brackets"

User name as upload comment

6 (talkcontribs)

I cannot figure out how to use a parameter for upload comments so the upload comment will be the username of the user who uploaded a file.

F.trott (talkcontribs)

You could try using ~~~ as upload comment. Not sure if that'll work, though. (talkcontribs)

Ok - but how? How to set up this as parameter? The manual is way too short on how to do this - at least for me. (talkcontribs)

I could figure it out how to set up parameters; ~~~ is not working correctly. I installed the extension MyVariables and tried \{\{CURRENTUSER\}\}, but after uploading this template is not used, it is not replaced by the username, instead the template name is printed out literally.

F.trott (talkcontribs)

The only other thing I could think of would be to try using <nowiki>~~~</nowiki>. (talkcontribs)

Thank you for your idea - but didn't help. :-|

Reply to "User name as upload comment"

Server communication failed

Summary by F.trott

SimpleBatchUpload seems not to play well with MW 1.31.1 + PHP 7.3.

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.

Reply to "Server communication failed"
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)
Reply to "breaks on Mediawiki 1.31.0"

New feature: Rename the filename with a regular-expression

Ankostis (talkcontribs)

Are there any thoughts for providing a method to modify the filename of the uploaded file with some kind of user-defined callback function (in javascript, lua, template) accepting the original file and converting it into the final one?

F.trott (talkcontribs)

It's not currently planned, but you're welcome to submit a patch.

Ankostis (talkcontribs)

But i wouldn't know how to go about doing it. Maybe allow a new "special" parameter `@fnametemplate` in {{#batchupload}}? Would it be possible for javascrript code to call back to server to discover the filename? Or better allow a parameter named `@fnamefun` and let the user attach such a global javascript function? Or to the prototype of the upload??

F.trott (talkcontribs)

There's probably a number of ways to go about it. One of the main points to consider is security. Allowing batch uploading dozens of files is already borderline dangerous and probably not a good idea to activate for public wikis.You have to carefully consider how to implement your functionality without opening additional attack vectors.

Ankostis (talkcontribs)

FYI, you may review my take on this problem in this commit: https://github.com/ankostis/SimpleBatchUpload/commit/2bd2c7c It is not for the wider public (e.g. it uses ES template literals) but you can get what i wanted to achieve:

Add a new parameter that specifies a regular expression for renaming the uploaded file-names:

{{#batchupload: ...|+rename= #pattern#flags -->replace-string}}
  • Patterns can be surrounded with #/@! chars, and
  • can be followed by regex-flags 'idmuy', while
  • all spaces in the replace-string after the --> are significant (and respected).


Here it is the ''regex'' i use to embed the page-name of the page holding the upload-control into the start of the uploaded-filename, erasing any extra spaces or punctuation-chars supplied by the user:

{{#batchupload:ItemDoc|owner={{PAGENAME}}|+rename= !^({{PAGENAME}}[ -_./+]*)?!iu -->{{PAGENAME}}-}}
Longphile (talkcontribs)

@Ankostis The rename with regex feature is a great addition; unfortunately, it is not working for me when I tried your fork. I am running MW 1.31.1 with php 7.2.11. Using drag and drop or browsing to select a file to upload, I get "ERROR: The filename is not allowed." I would like to be able to rename uploaded files to ensure unique filenames in our wiki.

Ankostis (talkcontribs)

Please take the very latest from rename-files branch. I had indeed a bug when you didn't specify a rename.

Revansx (talkcontribs)

Hi @Ankostis, Does your "rename-files" branch work with MW 1.30?

...also, how hard would it be for you incorporate a new switch that won't let it upload a file that already exist?

Is that something I could tempt you to add? :-)

Ankostis (talkcontribs)

With my basic knowledge of mw and how to debug it, it should be a day's work, which i don't have for the foreseeable future. But you can give it a try: first locate the JS-API that searches if a page exists (eg exists()), and then use chrome's dev-tools in debug-mode to craft the javascipt code for the following actions:

  • Specify a regular expression to extract the new switch-parameter (i would call it `+skip if exists` or `+new files only`)
  • call the API discovered above,
  • avoid the upload and just set a message in the returned result explaining why the upload was denied.
Revansx (talkcontribs)

sounds easy. I really need to figure this out.

Would I be making this change to your 'rename-files' branch or would I be making a branch of your branch? This is where I get confused about git.

Revansx (talkcontribs)

@Ankostis .. so.. I just downloaded and tested your "rename-files" branch... and I love it! .. thank you!

Quick question .. what would happen if the PAGENAME contains "/" characters? (I.e. subpages) would that break anything?

Revansx (talkcontribs)

I just tested it and see that it converts the "/" to "-". Perfect!

Revansx (talkcontribs)

Can you tell us how to write the' 'regex'' part so that all files dropped on the button are set to the same name? (I don't envision using it for multiple files, but I would like to create an upload button that exists to upload one and one one file of a specific name. Thank you!

Revansx (talkcontribs)

I'm really proud of myself. I did it :-)

Here is the 'regex' I used to upload files to a fixed filename regardless of what the supplied filename is:

{{#batchupload:ItemDoc|owner={{PAGENAME}}|+rename= !([a-z0-9_ ()-.&]*)?!iu -->myfilename.xyz|}}
Ankostis (talkcontribs)

> Would I be making this change to your 'rename-files' branch or would I be making a branch of your branch? This is where I get confused about git.

You got to clone my repo to your own github accont and push there a new branch.

> I'm really proud of myself. I did it :-)

Great! Is that enough for you? I mean, don't you want to deny uploads if files exist?

Revansx (talkcontribs)

I do. I do.. but baby steps.. for now site's needs are met by checking for the expected file using the following:

| [[Media:somefile.xyz]]
| {{#batchupload:ItemDoc|owner={{PAGENAME}}|+rename= !([a-z0-9_ ()-.&]*)?!iu -->myfilename.xyz|}}

But it's on my list of things to do to learn to clone the repo and push a new branch.. and then.. make the commits and test it.. I'm eager to try. would you be willing to review my commits when I have them?

Ankostis (talkcontribs)

Sure. But better ask the original author to do that - i have as much experience in mw/smw as you do :-)

Revansx (talkcontribs)

aye. fair enough. Nonetheless. I'll let you know when I do so.

F.trott (talkcontribs)

I am always happy to review pull requests.

Regarding checking and rejecting uploads I am not sure if the proposed approach would be the best solution and if SimpleBatchUpload would be the best place to put it:

  1. Any such functionality that is implemented client-side in JavaScript is easy to circumvent, so is at best a cosmetical measure.
  2. Each file check would require an additional request to the server, making the whole thing inefficient.
  3. The functionality would only affect uploads by SimpleBatchUpload. Standard uploads would still be possible.

A better way might be to find a hook in the upload process that checks an upload and blocks it if necessary. Manual:Hooks/UploadVerifyUpload and Manual:Hooks/UploadVerifyFile look both promising.

It might also be worth to look for an extension that already provides this or a similar functionality, to use it as is or take it as a template for a dedicated extension providing this functionality. What about Extension:UploadBlacklist?

Revansx (talkcontribs)

@F.trott, Thanks for weighing in.

[Security] - My problem is not with security as much as it is with cosmetics/logistics so this would be fine for me.

[Efficiency] - The time it takes for a user to upload the file is likely much longer than the time it takes the script to do the check. This is not a concern for me.

[only works for this SimpleBatchUpload] - yes, exactly. That's a feature not a bug :-)

That said, I've researched and tested so many upload extensions and SimpleBatchUpload is really the best for my application. None of my users want to touch the Upload Wizard or the Standard Upload.. I can add your SimpleBatchUpload buttons to templates and SMW page classes and build amazing tools to solit file from people. With @Ankostis's branch I can force filenames and with the expensive file checking in the template i can disable the button with page logic. That said I'd *really* like to have this feature.. So I hope to add it as discussed.. and I do hope you'll be willing to include these features into your master branch even if it does come with some caveats on security and efficiency and completeness.

F.trott (talkcontribs)
Revansx (talkcontribs)

F.trott, you rock! ... I'll test it soon enough, but what kind of error message would SimpleBatchUpload show in such a case? ... that and (since I haven't read everything on the topic yet) do you know if there is any way of enabling the re-upload permission for the creator (aka original uploader) of each file? i.e. UserX can re-upload UserX's files, and UserY can re-upload UserY's files but neither can re-upload the others files. Is that possible?

Revansx (talkcontribs)

@Ankostis, I'm using your version of SimpleBatchUpload that allows a name change and specifically I'm using your example of adding the pagename as a prefix per:

{{#batchupload:ItemDoc|owner={{PAGENAME}}|+rename= !^({{PAGENAME}}[ -_./+]*)?!iu -->{{PAGENAME}}-}}

The problem I'm having now is that when someone "re-uploads" a file that already has the pagename as a prefix, the regular expression does something strange and produces a file that has no filename at all.

Am I doing something wrong? .. Have you considered this case where a file that has been uploaded with the "add pagename prefix" is downloaded (with the prefixed name) and re-uplaoded with the same tool?

any thoughts on how to handle this?

Ankostis (talkcontribs)

Yes i have, and should be working. Just make sure you have latest commit of the branch, since there was a bug in the intermediate commit i mentioned in my initial post.

Revansx (talkcontribs)

looks like this works well:

|+rename= !^({{PAGENAME}}-)?!iu -->{{PAGENAME}}-}}
Revansx (talkcontribs)

is there any progress on getting this feature included in the main extension?

Revansx (talkcontribs)
Reply to "New feature: Rename the filename with a regular-expression"

need to alter the CSS for VisualEditor

Summary by Revansx

I fixed this on my installation by making edits to ../rev/ext.SimpleBatchUpload.css

Revansx (talkcontribs)

Hi. This extension has become an important part of my site. Continued thanks for providing it :-) .. One way I use it is to allow uploads that "pre-tag" images with semantic properties based on the page that the #batchupload is used on.

This works wonderfully, however, the number of characters involved in the additional properties can be quite long. This is of course transparent in use, but when a user edits the page using VisualEditor (VE) the template for #batchupload renders with the css settings white-space:nowrap; on the span.uploadzone element.

I can verify this by using the browser developer mode and altering this css setting manually, and I have tried to implement it in Mediawiki:Common.css without success. I'm not sure what the expected behavior is for Common.css in VE edit mode, but I'm wondering if this could be most easily solved in the extension itself?

Here is a screenshot of the issue as it appears on my site in VE edit mode:

Notice how the horizontal scroll bar is about 5% of the screen and will scroll waaaay more to the right.. this is the problem. Anyone have any advice on how to fix this with CSS?

F.trott (talkcontribs)

Not sure that this is really a problem of the SimpleBatchUpload extension. I don't have too much experience with VE, but as I see it it should not spell out the input tag at all. If VE would actually show the file-upload button, then the CSS might have a chance to catch and hide it. As it is, this is just more text, so the CSS is not seeing it.

Revansx (talkcontribs)

well.. I know that there is a special Print.css page for CSS that is only used when printing a page. I'm not sure if Common.css is used when in VE edit mode. If it is, then I think I just need someone to help me determine how to refer to the SimpleBatchUpload element better. I'm not super savvy with CSS and this one is hard to identify for me.

Summary by Revansx

I don't understand it, but i am clearly mistaken. The code works great. Thanks!

Revansx (talkcontribs)

Clean installation on MW 1.33, upload button not rendered

Tommyheyser (talkcontribs)

I did a clean install of MediaWiki 1.33 on Windows Server 2016. Installed the extension via composer.local.json, ran composer update --no-dev and added the wfLoadExtension( 'SimpleBatchUpload' ); line to LocalSettings.php.

Extension is shown on the Version page, but Special:BatchUpload only shows the text "Select files (or drop them here)...", a button with text "Choose Files" and "No file chosen".

The error log shows the following:

[resourceloader] Unexpected general module "ext.SimpleBatchUpload" in styles queue.
[resourceloader] Unexpected general module "ext.SimpleBatchUpload.jquery-file-upload" in styles queue.

I didn't have this problem in MW 1.31. Has there been any breaking changes since?

F.trott (talkcontribs)

If you install dev-master instead of ~1.4, does that help?

Tommyheyser (talkcontribs)

Yup, that fixed it. I'm guessing it has something to do with the change in 1.32 related to api that was fixed with Fix #21. Thanks. I hadn't thought of switching to dev-master, should've read the commits.

Reply to "Clean installation on MW 1.33, upload button not rendered"

Latest version does not work on MediaWiki 1.33

Summary by F.trott

Bug is fixed. Available in master now or in the next release when it comes out.

Ti infotrad (talkcontribs)

Dragging and dropping a file does not do anything. Upon debugging, find the following error in the console

load.php?lang=en&modules=startup&only=scripts&skin=vector:2 Error: Unknown module: mediawiki.api.edit

   at sortDependencies (load.php?lang=en&modules=startup&only=scripts&skin=vector:8)
   at sortDependencies (load.php?lang=en&modules=startup&only=scripts&skin=vector:9)
   at resolveStubbornly (load.php?lang=en&modules=startup&only=scripts&skin=vector:9)
   at Object.load (load.php?lang=en&modules=startup&only=scripts&skin=vector:21)
   at index.php?title=Special:BatchUpload:9
   at Array.RLQ.push (load.php?lang=en&modules=startup&only=scripts&skin=vector:48)
   at load.php?lang=en&modules=startup&only=scripts&skin=vector:48
   at load.php?lang=en&modules=startup&only=scripts&skin=vector:48

Find this module and others are deprecated (https://phabricator.wikimedia.org/T196802)

Fix by modifying as follows:

Change the line in src/SimpleBatchUpload.php

'dependencies' => [ 'ext.SimpleBatchUpload.jquery-file-upload', 'mediawiki.Title', 'mediawiki.api.edit', 'mediawiki.jqueryMsg' ],


'dependencies' => [ 'ext.SimpleBatchUpload.jquery-file-upload', 'mediawiki.Title', 'mediawiki.api', 'mediawiki.jqueryMsg' ],

Revansx (talkcontribs)
Ti infotrad (talkcontribs)
F.trott (talkcontribs)