NICE, this was bugging me since the beginning. Next step would then be to offer plugins a way to add custom actions :-)

Next step would then be to offer plugins a way to add custom actions

I was thinking the same as I was reviewing the code here. Also, it shouldn't be that hard but it requires some changes in the PHP world as described here: #34634 (comment)
Basically the supported extensions data struct should be something like

{
  supported: [
    {
      extension: 'png',
      mime: 'image/png',
      preview: true,
      upload: true,
      edit: true
    }
  ]
}

I was more referring to custom actions like "Send by Mail" or "Tweet picture" which can be added by plugins.

You still need some of the buttons to be able to act on specific media types or else the API will be an all or nothing. The media types object that I proposed above can be extended by the plugins to add the button name and enable it for whatever extension needs to be enabled (basically the plugin will have to register itself for whatever media type is supporting and append the vue js part before the mediamanager.js)

@dgrammatiko agree. But lets discuss this on another day to not disturb this pr.

@dgrammatiko do you think an intermediate solution would be to define extra fields, in installation/sql/mysql/base.sql with image_extensions_editable: "jpg,jpeg,png", then retrieving them in a template file and so make it visible to the client? With that one could get rid of the hardcoded editable file extensions for now.
A new data structure like you proposed it would make lots of sense in my eyes for the long-term but maybe this could be a short-term solution?

With that one could get rid of the hardcoded editable file extensions for now.

We already do something similar, check #34634

A new data structure like you proposed it would make lots of sense in my eyes for the long-term but maybe this could be a short-term solution?

The short-time solution is already in place, what is needed (check my last comment in the other PR) is a way to have a pool of the mime/extentions and then a field in the media manager option where users could pick the extensions they want. Since we will provide the pool (similar to apache's or nginx mime.conf) we could hardcode there the buttons: preview, edit, etc and then the plugins would have only to append their name on the supported formats and register the .js file.

@JenSeReal some feedback here, regarding the comment of @laoneo about custom buttons:

It would make sense to have the button components registered async ( https://vuejs.org/v2/guide/components-dynamic-async.html#Async-Components )like:

// These will be fetched from the mediamanager options rendered as json in the template layout
const buttons = [
{
  name: edit,
  url: '',
},
];

// The registration
for (button of buttons) {
  Vue.component(
    button.name,
    // A dynamic import returns a Promise.
    () => import(button.url)
  );
}

This way you have the foundation for any custom button

@bembelimen when you have a look at #35451, then you will see why this one here is needed.

I'm just waiting for the 2 tests to merge ;)

@bembelimen I would trust more the system tests than the human tests ?

@dgrammatiko do you give a ? for this PR to merge or do you think we should update with your suggestion first? (probably you could then deliver some code, which we can merge with this PR?)

@bembelimen my suggestions can go later, so this one it's fine as is.

Probably it would be a good idea to open a project in the GitHub to list the things that should be fixed/improved, get the discussion there and leave the PRs for the code part

Thx, then we just need some approved tests and we're good to go.

Anyone with some successful tests? Would really like to merge it.

We have 6 conflicting vue files. Maybe @dgrammatiko can help to solve the conflicts? I have no knowledge in vue.

@richard67 I don't have sufficient permissions to do anything here, maybe @laoneo could fix the conflict if @JenSeReal can't do it

Closing in favour of #35887 . Thanks @JenSeReal for your contribution.

P.S.: The new PR still contains the commit history of this one here, so @JenSeReal will be at least mentioned as co-author of the new PR when it gets merged.