@Fedik please add the files folder also here:

FWIW I would prefer the folder to be named user_uploads than files

Added.

I think files is a good name, it also will produce a good links.
Let's say Company Site uploads a document, then link will be kind of example.com/files/foo-bar.pdf.
example.com/user_uploads/foo-bar.pdf will not looks "professional" ?

Currently there still a limitation (pretty huge), the custom field for Media does not allow to select anything else than folders under /images.
It is hardcoded

I think it will need another field to allow to pick folders from Media manager adapters, but that something for another PR.

Currently there still a limitation (pretty huge), the custom field for Media does not allow to select anything else than folders under /images

You're right, there's a @TODO for this:

One more thing, could you add an .htaccess file inside the files folder with content:

<Files *.php>
  deny from all
</Files>

Since this is a new folder we can restrict it to ONLY static files. (the same should be applied to images and media folders but that's irrelevant to this PR)

there's a TODO for this

Actualy, that "todo" can be already trashed, since we have type="images,documents", attribute.
What i meant, is media field configuration for Custom fields.

One more thing, could you add an .htaccess file inside the files folder

Hmhm, I can, but this can affect people who already have /files folder, and use it on its own purpuse.
Not sure here.

It seems the system tests need to be adapted, too. Currently they fail at file api/com_media/Files.cy.js:

Test that media files API endpoint
    1) can deliver a list of files
    2) can deliver a list of files in a subfolder
    ✓ can deliver a list of files with an adapter (346ms)
    3) can search in filenames
    4) can deliver a single file
    5) can deliver a single file with the url
    6) can deliver a single folder
    7) can create a file without adapter
    8) can create a folder without adapter
    9) can create a file with adapter
    10) can create a folder with adapter
    11) can update a file without adapter
    12) can update a folder without adapter
    13) can update a file with adapter
    14) can update a folder with adapter
    15) can delete a file without adapter
    16) can delete a folder without adapter
    ✓ can delete a file with adapter (325ms)
    ✓ can delete a folder with adapter (315ms)

  3 passing (38s)
  16 failing

It seems the system tests need to be adapted, too

Yeap, I will look on it later

@brianteeman ?

I really like it, just the name is for me too generic. I would rather go with documents, if you name them files, then should the images also be moved there. Or you can go with /files/images and /files/documents. But having a generic files in root which directly contains everything except images is for me not logical.

I will keep it generic.
We definitely can do /files/images, sometime in future. 1 step at time :)

I found a bug in media manager API, it always return path without adapter

And when you doing API call with non default adapter,
like rename folder local-potato:/folder to local-potato:/folder-new it produces 404 error.
Because it looking in default adapter local-files:/folder-new instead of requested local-potato:/folder-new.

I am a bit confused about the need for this PR.

If I create a folder myself in the root of the web space then I can already achieve everything that this PR does - what am i missing?

what am i missing?

You need to create the folder by yourself. That what you missing ?
I offer to have it in the core by default, so you do not have to create it by yourself every time.

what am i missing?

You need to create the folder by yourself. That what you missing ? I offer to have it in the core by default, so you do not have to create it by yourself every time.

Then I dont see the point in adding this

I do not know, man. I do not know what to say.
It is absolutely basic thing that should be done a decades ago.

Look, we have allowed uploads bmp,gif,jpg,jpeg,png,webp,avif,ico, mp3,m4a,mp4a,ogg, mp4,mp4v,mpeg,mov, odg,odp,ods,odt,pdf, png,ppt,txt,xcf,xls,csv
And by default all goes in to /images folder, it confuses newcomer very much.

There still limitation that need to address, like hardcoded /images path in many places, but that for the future.

It is absolutely basic thing that should be done a decades ago.

It was and we removed it

From a Joomla extension developer view, this change is much needed. It is helpful not only for the core com_media. Thank you for adding it.

I have tested this item ✅ successfully on 2c7e0af

Tested on 5.2 Alpha 2

I have tested this item ✅ successfully on 2c7e0af

@MacJoom This pull request has a conflicting file, so I can't set it to RTC.

@MacJoom This pull request has a conflicting file, so I can't set it to RTC.

Yeah just noticed, set back to untested

I have tested this item ✅ successfully on 2c7e0af

@Fedik Could you fix the conflict in the integration test file? When that is done this PR can be set to RTC. Human test are valid as the conflict is only in that file which does not have effect on the tested functionality.

I have tested this item ✅ successfully on 2c7e0af

synced

RTC

Please do not merge till there is an agreement in production about our future folder strategy.

There still is no agreement in production about this feature. Since we had a feature freeze, I'm moving this to 5.3.

Thanks to all who have worked in this