Widget upload description (filesize, allowed extensions).

1. +++ b/modules/eb_widget/src/Plugin/EntityBrowser/Widget/DropzoneJsEbWidget.php
   @@ -126,6 +126,18 @@ class DropzoneJsEbWidget extends WidgetBase {
   +      $descriptions[] = t('@size limit.', array('@size' => format_size(Bytes::toInt($config['settings']['max_filesize']))));
   

   Use array shorthand ['@size' => ...]

2. +++ b/modules/eb_widget/src/Plugin/EntityBrowser/Widget/DropzoneJsEbWidget.php
   @@ -126,6 +126,18 @@ class DropzoneJsEbWidget extends WidgetBase {
   +      $descriptions[] = t('Allowed types: @extensions.', array('@extensions' => $config['settings']['extensions']));
   

   Use array shorthand ['@extensions' => ...]

3. +++ b/modules/eb_widget/src/Plugin/EntityBrowser/Widget/DropzoneJsEbWidget.php
   @@ -126,6 +126,18 @@ class DropzoneJsEbWidget extends WidgetBase {
   +    $form['descriptions'] = [
   

   Would be cleaner not to add this if $descriptions is empty.

Thanks for this improvement. Would it make sense to add that in the dropzone element in dictDefaultMessage? This would then apply to all widgets and it might be a bit better from UX perspective.

Putting this to Needs work. IMHO that's the right approach, happy to hear other arguments though.

Tried #8 - the
tags are rendered as a plain text. Adding a new patch

Hard coding these in the template doesn't seem flexible enough to me. Could it be abstracted in some way so it's easy to extend in future or by other modules? Something like:

$variables['file_info']['max_filesize'] = [
  'label' => t('Maximum filesize') . ': ',
  'value' => format_size(Bytes::toInt($element['#max_filesize']))
];
$variables['file_info']['extensions'] = [
  'label' => t('Extensions') . ': ',
  'value' =>  $element['#extensions']
];

{% for item in file_info %}
  <div>{{ item.label }}{{ item.value }}<div>
{% endfor %}

@imclean anybody can easily extend any template by simply copying it in the theme folder.

@a.milkovsky, true but there's less to modify if we don't have to update the template each time. I guess I was thinking longer term it could be good to extract any extra field information provided by any modules (e.g. base file field settings) from the context and automatically display them with no modifications to DropzoneJS.

Added fields where description text can be adjusted

As an example of what I mean in #14, say you've installed a module which adds certain specific information. You then want to install another module which can also add some of its own information. How could either module modify the template so the data from both modules is displayed?

There can be only one template file used. If the data can be added in a hook somewhere then the information from both modules could easily be displayed without interfering with the other.

@imclean, I agree. Makes sense. Could you provide a patch? The idea of #15 looks good as well.

Added missing schema changes for the description configs from #15. Also re-lolled the patch for the latest version - it should fix failing tests as well.

Oops, forgot to adjust the test form. Here is new patch.

Here is new patch for version 8.x-2.1. I recreate from #21.

Here is the new patch for version 8.x-2.3. I recreated from #22.

reroll

Getting `Maximum size of files: 0 bytes`
Fixing this by checking if the field has a max_filesize setting set. fallback to the environment value set in the base plugin.

Needed a re-roll.

@hieuntnguyen, could you please elaborate why you uploaded 3 patches and what is different with #30?

Patch in #30 still applies just fine. I'm hiding 31-33.

Thanks @heddn, we're using patch from #30 and works as expected and is a really nice addition.
Setting version to 2.X-dev as this only applies on latest dev. Let's hope this is added quickly.

The patch needs work for coding standards and the dependency for the module token is missing in the test module.

Re-roll of #30.

Re-roll of #39

A little bit of a safer approach since render element is used in several places.

Looks good, but will need config schema update as this prints out an error when validating with Config Inspector.

Apologies, looks good for the schema part.

Re-roll of #42

In our eyes this is an important improvement to the module. We would love to see this committed. What can be done to get this committed?

Updated patch for D11 format_size() deprecation - the only difference in this patch and #45 is the inclusion of:
use Drupal\Core\StringTranslation\ByteSizeMarkup;
&
$replacements[$original] = ByteSizeMarkup::create(Bytes::toNumber($data['max_filesize']));

It appears that patch #47 missed a few files, but it does resolve the D11 issue.

Thanks for the updated patch. I added this as a MR for a start point.

But we should build in the BC as this module still supports ^9.3 and ^10 and the new method only exist from 10.2 and upwards, see https://www.drupal.org/node/2999981

Please work in the MR from now on.

Made patch from #45 visible again as that is the one supporting untill D11.