@zero-24 states on behalf of the JSST:

it was the intention to not allow core folders other than images given that by changing that folder you could upload, remove, replace etc stuff on core folders that are not intended to hold image files. Will add a reply to that ticket too.

So the JSST INTENDED to introduce an undocumented backward incompatible change in a point release, breaking a Joomla 3 feature, at the end of its lifecycle of releases…. /facepalm…

Yes it is intended to limit the image folder to the folders that are intended to hold images.

Since when has it been the JSST right to dictate which folders are the folders intended to hold images? Maybe someone wants to use /media or /media/images or /media/myimages instead of /images...

That will break many extensions. Surely we had learned the lesson from the previous security fix that prevented access to symlinked folder.

That will break many extensions.

We have this behind an optional additional xml setting so where should 3rd party extensions be affected to this?

Since when has it been the JSST right to dictate which folders are the folders intended to hold images? Maybe someone wants to use /media or /media/images or /media/myimages instead of /images...

Well historically joomla uses the images folder for images and the media folder for "media" files shipped with extensions so no change here intended.

Well historically joomla uses the images folder for images and the media folder for "media" files shipped with extensions so no change here intended.

Correction to that comment

Well historically joomla CORE uses the images folder for images and INTENDED the media folder for "media" files shipped with extensions so no change here intended.

rightly or wrongly many extensions have (ab)used the media folder.

rightly or wrongly many extensions have (ab)used the media folder.

Maybe but extensions are not affected by this change given that the new validation is only taken effect once you choose to add the (optional) exclude validation regex + the filePath validation in the first place to your very own extension.

Joomla might historically use the images folder for images, but IN THE REAL WORLD its up to site admins where they place images. It could. literally. be. anywhere. Thats their choice.

This is still a undocumented backward incompatible change in a point release

Joomla might historically use the images folder for images, but IN THE REAL WORLD its up to site admins where they place images. It could. literally. be. anywhere. Thats their choi

Yes and no while it might be possible to break out of the intended paths in the past i dont see an issue that we make sure that this does not happen again. You are still free to change the configuration.php to any value you want.
And we only make sure you dont choose an path that is already taken by the joomla core, any other path can still be choosen on the admins whish.

This is still a undocumented backward incompatible change in a point release

I'm happy to help to add such documentation from my understanding the usage difference between images and media is the intended way of doing things from the beginning and that was never questioned but when there is need for more details to be documented we can do that for sure.

So you are perfectly happy to accept that you have broken Joomla for sites where they chose to store their images in the "/media/myImages/" folder historically. Historically, in all other Joomla versions, this has been acceptable.

These people can no no longer save their Media Global Configuration, they can no longer make changes to their configurations unless they change their folder name to a top level folder that is not /media or any of the Joomla folders including tmp and cache, and move all their images manually.

And you, the Joomla Project, are happy that this is resolved just by documenting the breaking backward compatibility change in a point release at the end of a major series release cycle... Got it. Im done.

I think that this change does not limit where you can place images as an extension developer. This only stops you as a website builder, meaning content creators from placing images in core directories. This is a good practice and does not nearly deserve this much attention.

If you have a website that has placed images in the media folder, and all those links are now in the database you can with a SQL script easy update those, something like this:

UPDATE #__content
SET introtext = REPLACE(introtext, '<img src="/media/myImages/','<img src="/images/myImages/')

But as an extension developer you can still add images to the media, any folder if you like, just not via the media manger, and all those links will still work. Since you can write your own rule.. very easy if it is all about the FilePathRule.

Keeping user content out of the core folders is good practice, but this change does not enforce that system wide, it just does it for the media manger, and the core FilePathRule. But Like I said you can extend the FilePathRule into a custom rule, and remove those lines that you don't like in large production site. This will take five minutes if that much.

This [...] does not nearly deserve this much attention.

This will take five minutes if that much.

That is not the point. This IS a backward compatibility change that breaks functionality on sites that have previously been able to locate their images in other places. This is mass-distributed software. These kind of b/c breaks should not happen in a small point release.

Since this change was released under the false premise of being a security fix, please disclose the details pertaining to the security issue that necessitated this uncommunicated and half-ass-documented API break.

What a nice response to a request for information ?

So is this a won't fix then?

If you have a website that has placed images in the media folder, and all those links are now in the database you can with a SQL script easy update those, something like this:

Easily for someone with the required skills
Impossible for a very large percentage of the userbase

Backwards compatibility is a promise between the Joomla and the User. People dont like it when promises are broken

Closing as the project has declared this is a won't fix and (newly) expected behaviour - although everyone agrees its a b/c break.