I have tested this item successfully on 27f3371

I have tested this item unsuccessfully on 27f3371

The select and delete work but the message is wrong
It only shows

Message
Delete Complete: /sampledata/fruitshop/tamarind.jpg

It would be better if it was to say something like "Multiple selected files deleted"

Ah, good catch. I'll fix this.

@brianteeman Actually... that has nothing to do with this PR. Multiple selection/deletion is already a thing and this poor message is the status quo. I can fix it in this PR though.

This PR has received new commits.

CC: @brianteeman, @NLRoosj

I'm updating both the 'file' controller and the 'folder' controller to report all deleted files and folders but, in fact, the 'file' controller is never actually used. Actually, a lot of things in this component are outdated or could use some work. For example, JError is still used quite a lot.

print_r($app); die();

The component is scheduled for replacement but I guess not till 3.6 now

On 22 January 2016 at 09:48, infograf768 notifications@github.com wrote:

print_r($app); die();

[image: ]

—
Reply to this email directly or view it on GitHub
#8852 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

lol! Epic fail.

This PR has received new commits.

CC: @brianteeman, @NLRoosj

I have tested this item successfully on 6c71696

I have tested this item successfully on 6c71696

It works like a charm!

RTC thanks

I'm sorry @okonomiyaki3000 but there are conflicts - so I can't merge it - can you rebase please?

This PR has received new commits.

CC: @brianteeman, @genesisfan, @NLRoosj

This is a new feature so it has to go into 3.6.x ?

Personally its more of a bug fix than a feature as this should have always been there and it cant be said to have any effect in anything else.

"It should have been there" fits for or lot of issues :-)

Anyway I checked the last commits, there are files renamed, so when someone has overwritten a layout it fails (chances are low I know). I also think it should be testet again.

If we are strict with semver then this is a interface change and allows a different way of doing something so it isn't bugfix it is a new way and so it is a new feature.

Wow - didnt actually spot that this (small change) had so many edits. Seeing all the file changes I agree with you 3.6 and will retest

I have tested this item unsuccessfully on 2c272f1

Came across a problem when deleting invalid files

Create a file caled test (1).jpg and add to the images folder manually

If you try to delete it you will correctly get a message
Unable to delete: . File name must only contain alphanumeric characters and no spaces.

Now try to use the delete all checkbox on the folder and you get a message
Unable to delete: .

When you try to delete multiple files you get a success message for each file with the filename as expected
But if you have multiple files that cannot be deleted like above then you only get the one message
Unable to delete: .

I'll have a look at that but maybe we should address the issue of being unable to delete files because of their names. Is there any reason for that?

The reason is that there has always been the view that media manager should
only delete files that it can create.

BUT as this has now been pushed to 3.6 and @dgt41 is working on a new Media
Manager for 3.6 maybe any further new work on the existing Media Manager is
pointless

@dgt41 Thoughts?

On 13 April 2016 at 07:55, Elijah Madden notifications@github.com wrote:

I'll have a look at that but maybe we should address the issue of being
unable to delete files because of their names. Is there any reason for
that?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8852 (comment)

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

It's perfectly fine with me to drop this PR if the functionality is being included in the new version.

On the other hand, if there's a chance that the rewrite would be delayed and get pushed back to whatever version comes after 3.6, I can easily brush this up to make sure at least this feature gets in.

I would wait for a comment from @dgt41

On 13 April 2016 at 09:03, Elijah Madden notifications@github.com wrote:

On the other hand, if there's a chance that the rewrite would be delayed
and get pushed back to whatever version comes after 3.6, I can easily brush
this up to make sure at least this feature gets in.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8852 (comment)

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Setting to Needs Review by @dgt41 ;)

I am in the loop for the new Media Manager as well, work is being done for it but it isn't implemented until finished. Until then I would like to see this go in as it enhances the user experience.

@okonomiyaki3000 Could you please brush op this PR so we can get it tested and merged? Thank you.

P.s. if you are interested in contributing to the new media manager, let me know.

I'll get this PR ready then. I might be interested in the new one but not sure if I have much time to work on it.

@okonomiyaki3000 Thank you, I will let Jisse contact you and you guys can figure it out the options.

@brianteeman In the case that you try to delete a badly named file along with some properly named files, do you think it's best to abort all delete operations or just skip the badly named file(s)?

This PR has received new commits.

CC: @brianteeman, @genesisfan, @NLRoosj

For now, I've gone with deleting what can be deleted and displaying errors for what can't but I wrote it in such a way that it's very simple to abort before deleting anything in case of errors.

There's something else to consider though. We decide which files are good and which files are bad before firing any events. We then warn about the bad files and do nothing else with them. The good files get events fired for them at which time path to the file to delete can be changed (by a a plugin). So, a good path may become bad (because of a plugin) but a bad path has no chance to be made good.

Also, MediaControllerFile and MediaControllerFolder both have identical delete functions. One is used when deleting a single file, the other for multiple. It's kind of nonsense. I'm not going to fix it now because it's not a big deal and anyway a new media manager is being developed. Let's hope we can avoid this kind of thing in the new one.

I have tested this item successfully on 3ec14a0

I have tested this item ✅ successfully on 3ec14a0

RTC

Merged with c0aadb2. Thanks!

Changed milestone as it was merged early

3.7.x branch :)

Oops my mistake. Github doesn't show the bramch