First of all, let me say I like what I saw so far. Good job
Especially the image editor is really fancy!

Some things I noticed during tests in no particular order

• The folder and navigation icons in the "Thumbnail View" are smaller than currently, which I think is a step back. Was there a reason to resize them? I think it makes it harder to navigate.
• Since the category is a required field in the image editor view, I would suggest to add the default category "Uncategorised" like we have in all other components.
• I saw you put three new model classes into the library. There is currently a GSoC project done by George Willson who will also create classes for the new MVC. To avoid multiple new classes which in the end do the same, you should contact George and see that you can create one set of classes only . Until that happens, you should put your new classes into the media component so we don't end up with incompatibilities later on.
• For some reason, the /libraries/cms/model folder is deleted when I click on the extension manager -> database and use the fix button there (which adds the missing content types). Unfortunately this makes it hard to use the patchtester and database fix to apply the PR, since it will create a fatal error afterwards due to missing model.
• I have to say I'm not a big fan of using the current #__ucm_... tables. I think the current UCM is a bit a half baked solution and I have a feeling that we will cripple ourself in future if we start using it to much. But lets see what others think.

Another thing I noted:

• The modal you get when you select a picture using the picture formfield (eg for select an article intro image) does seem to use the regular view. That's especially bad since on that small modal, you get two an additional vertical scrollbar. This is quite awful to use. I guess it just uses a wrong layout here.
• You also get that scrollbar in the regular media manager view when you resize the browser or have many images. That's not related to your PR thought. It also happens with current media manager. But maybe it can be improved.
• The modal you get when using the editor-xtd button is to wide. It does work well on big screens, but fails already on a screen with 1280*1024 pixels.

First: thanks for your awesome work! This is a huge step forward!

A feature that I would like to see implemented is the usage of data-uris for the thumbnail view. By embedding the data-uris for all thumbnails visible in a single json document we could dramatically improve the client-side performance.

This may sound silly , but have a question:
it still support other file types? (pdf, doc, videos and so one)
if yes, then content type com_media.file (or around) would be more logical

Some more observations

• With the new drag and drop uploader there is no error message when the upload fails for whatever reason. Like if you try to upload an mp3 (which by default isn't allowed). It just shows the progress bar with an "OK" label but doesn't actually upload it. The regular uploader will show an error message.
• The drag and drop uploader still shows recently uploaded files when you open it a second time. Imho it should reset the status window.
• Files other than pictures can't be categorised or tagged at all. I think there should at least be a generic "file" content type which allows the basic actions. After all an entry in the db is created with names and such.
• Tags work in backend as you can assign them to a picture. In Frontend it shows up as an item, but only the title and label (as description) is shown, the actual image isn't shown in the list. And when clicking on the title you get an invalid link (index.php/component/media/?view=image&id=0) which results in an "you are not authorised" warning.
• The hashing of uploaded files makes the thumbnail view unuseable for files other than images. Try selecting an audio or pdf file by just the hash, it's bound to fail. The detail view is better because it actually displays the stored name and shows the filename as tooltip. However it will also fail for custom extensions which use the filelist formfield or rely on JFolder to catch the files in the folder.

I don't think it's really needed to hash the filename. It will likely generate more trouble than it solves.
I'm also not sure if Google will like that when they index the pictures. Maybe someone with SEO knowledge knows if the filename matters for pictures.
Personally I like descriptive filenames more.

I don't think it's really needed to hash the filename. It will likely generate more trouble than it solves.
I'm also not sure if Google will like that when they index the pictures. Maybe someone with SEO knowledge knows if the filename matters for pictures.

Google does like the filenames

source http://static.googleusercontent.com/media/www.google.co.uk/en/uk/webmasters/docs/search-engine-optimization-starter-guide.pdf

Thanks Brian! To quote from the Google Best Practice (page 19):

Use brief, but descriptive filenames and alt text

Like many of the other parts of the page targeted for optimization, filenames and alt text (for ASCII
languages) are best when they're short, but descriptive.

Avoid:

• using generic filenames like "image1.jpg", "pic.gif", "1.jpg" when possible—some sites with thousands of images might consider automating the naming of images
• writing extremely lengthy filenames
• stuffing keywords into alt text or copying and pasting entire sentences

So it looks like hashed filenames are a bad idea for several reasons.

Since the category is a required field in the image editor view, I would suggest to add the default category "Uncategorised" like we have in all other components.

+1

Great work Buddhima! I'm testing this now, and this is a great start.

I may be misunderstanding something, but I don't see how I can use media categories. I am able to create a new one, but I don't see how or when I can assign a media object to a category and then how to use a category. In your document, I see you mention a category view in the media manager, but that doesn't seem to work for me. Can you explain this a bit further?

I also noticed that when clicking the link under a media thumbnail, I get Fatal error: Class 'JModelCmsitem' not found in /administrator/components/com_media/model/editor.php on line 20. Clicking the thumbnail work fine.

I have to say I'm not a big fan of using the current #__ucm_... tables. I think the current UCM is a bit a half baked solution and I have a feeling that we will cripple ourself in future if we start using it to much. But lets see what others think.

I do agree with @Bakual about this. I'd be leary to depend on it too much.

I also noticed that when clicking the link under a media thumbnail, I get Fatal error: Class 'JModelCmsitem' not found in /administrator/components/com_media/model/editor.php on line 20. Clicking the thumbnail work fine.

@betweenbrain That is because you probably used that database fix button in the extensions manager. It deletes the three new models in /libraries/cms/models for some reaon. You can revert the PR and apply it again and it will work (as long as you don't press the button again )

@Buddhima Job well done. Let me give you some feedback too.

Applying the PR I see a few codestyle issues:
D:\wamp\www\newmedia>curl https://github.com/joomla/joomla-cms/pull/3839.diff |
git apply
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 304k 100 304k 0 0 201k 0 0:00:01 0:00:01 --:--:-- 219k
:1310: trailing whitespace.

:2412: trailing whitespace.

:2448: trailing whitespace.
<?php echo $title; ?>">
:2479: trailing whitespace.
<?php echo $title; ?>">
:2503: trailing whitespace.
<?php echo $title; ?>">
warning: squelched 210 whitespace errors
warning: 215 lines add whitespace errors.

Show the Filter value only if required:

When I click crop I get this message:
Error
Error in crop area

Might be an idea to extend this message to include something like "Error in crop area. You must select an area to crop."

Creating thumbnails
The popup box can be bigger I think to prevent having to scroll:

I also have no idea what to put in the Thumbnail folder. Does it have to be the full path on the server? Is it a subfolder from an existing folder?

A possible language issue:
Creating thumbs Successful --> Creating Thumbs Successful

Ask for confirmation
Should we add a "Are you sure?" before deleting images/folders?

Generic error message
I uploaded a large image (2.8MB) and that worked fine but when I clicked on the title to edit it, I get this page:

To add to the "hashed filenames" issue... I'm working on the migration of the JCM to 3.x. At first the new Media Manager seemed promising to me. But as I think about hashed filenames, I wonder how backward compatible that will be in terms of media assets - the JCM has literally thousands of images stored and referenced within text. Does the Media Manager address how it handles sites with legacy content? I also wonder about how well JCE and its plugins will work with media that has been added through Media Manager.

Does the Media Manager address how it handles sites with legacy content?

That at least isn't a problem. Existing files aren't renamed and are added to the database with the current filename. You can test this fine with the existing sample media for example. The hashed filename would only be for newly uploaded files and only when uploaded using the media manager.

Great job @Buddhima!

Just took your PR for a short spin. Some great new features! As some already has been discussing, hashed filenames is absolutely a no go regarding SEO, so please reconsider that :)

I my opinion the image editor view is a bit confusing and so I tried to tweak it a bit, so it resembles what we know from the article view. Perhaps the image field / crop field should be highlighted even more:

It would a great feature to have the possibility to rotate clockwise and counterclockwise, mainly to speed up the process.

I'm missing some sort of warning or dialog box, when deleting images.

Just some short comments. I'm going to move on with the testing

Thank you for all the work.

In your PR MediaModelMedia and MediaModelMedialist are extended from ConfigModelForm. Is that intended as a temporary solution? Is ConfgModelForm intended to be transformed to JModelCmsForm and put in /libraries/cms/model or something like that? Or will the media-models in the future be extendended from JModelCmsList and JModelCmsItem?

The hashed filename would only be for newly uploaded files and only when uploaded using the media manager.

That's interesting. But if I will rename file using FTP what will happen?

I also wonder about how well JCE and its plugins will work with media that has been added through Media Manager.

Good question!

Hi All,
First of all, Thank you very much for testing this PR. I'll try to answer questions as much as possible.

@all : In last commit, I added Uncategorised category for com_media

@brianteeman : I did language changes, Thank You!

@Bakual : It seems you had a great time with new media manager :-D, let me go through issues you mentioned.
1. Folder icon size is fixed. Finally, I found the way to resize them
2. Uncategorised added
3. (also @HermanPeeren )At the time I started this, using those model classes was the best choice. I'm aware about new MVC project. I have mentioned that this is not THE FINAL in the doc. After completing new MVC project, this also will need to refactor.
4. "Select Image" popup is something I missed, will fix it soon
5. About image-manager size: I need to check and change if required.
6. I'm aware about the Drag & Drop issues. That's mentioned under "Improve Drag & Drop" topic. But I don't want to miss this feature. What I need is constructive feedback to make this working, since I have less experience in JS.
https://github.com/Buddhima/joomla-cms/blob/new_com_media/media/media/js/dragndrop_upload.js
7. Also relates to @Fedik , allowed file types can be configured via Global Config. -> Media Manager. I agree there should be more content-types in future such as com_media.video, com_media.audio, ... etc. depending on the necessity, and com_media.file as the fallback.
8. Tagging & Categorising other than images means those types also need editor(s). That's good for Media Manager, but too much for this PR.
9. Tag link issue need to take care (something I haven't checked at all). If you have a solution, let me know.
10. Finally, hashed-filename,( @brianteeman , @rcarey ), It's up to developers to discuss and let me know. What I see is that's a trade-off between security vs SEO.

@betweenbrain : Sorry about issue with model classes, that's something unexpected. You can assign category and tags to images inside the Editor.

@roland-d :
1. Would be better if you can send me code-style issues more descriptive way. I tried my best to minimize those.
2. About filter modal: Currently there's not form field type to satisfy this requirement.
3. Language issues fixed with the latest commit.
4. Thumbnails modal : I'll resize the height. Thumbnail folder is created with respect to where the image is. That seems matching with JImage default way of creating thumbnail folder.
https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/image/image.php#L255
5. (also @losedk )Confirmation at deleting files will be a good idea, and would be useful if someone can add it to existing media manager too.
6. Generic error: would be great if you can help to find where it comes from.

@losedk : Showing image information is good, but I think JImage doesn't carry that much information.

@b2z : In the doc. under "Image file manipulations" I tried to explain it. In your case, media manager will treat renamed file as a new file and creates a new record in table.

@SniperSister : Thanks for testing, but I'm not clear about your new idea.

Thanks a lot all of you for testing, and I would appreciate if you can help to improve this specially with JS issues.

Sorry but you have misunderstood the security concerns in the owasp document and the hashing of filenames will have minimal impact increasing the security issues addressed in that document. In fact we already address all of those issues in joomla core today WITHOUT any filename mangling or hashing

Unfortunately my JS knowledge is close to zero
For the error message, there is a JS method in the core.js which allows to insert a message into the message area. See https://github.com/joomla/joomla-cms/blob/staging/media/system/js/core-uncompressed.js#L124. Maybe that helps.

@Buddhima

1. The most code style issues are whitespace at the end of the line. You may want to set your editor to remove trailing whitespace on save. If your editor supports that of course. The easiest way to check this is to download a diff of your pull request with cURL for example:

curl https://github.com/joomla/joomla-cms/pull/3839.diff > media.diff

After that you can apply the diff like this:

git apply media.diff

This will show you the warnings like this:

D:\wamp\www\newmedia>git apply media.diff
media.diff:10: trailing whitespace.
INSERT INTO `#__categories`(`id`, `asset_id`, `parent_id`, `lft`, `rgt`, `level`
, `path`, `extension`, `title`, `alias`, `published`, `access`, `params`, `metad
ata`, `created_user_id`, `hits`, `language`, `version`) VALUES
media.diff:21: trailing whitespace.
INSERT INTO "#__categories"("id", "asset_id", "parent_id", "lft", "rgt", "level"
, "path", "extension", "title", "alias", "published", "access", "params", "metad
ata", "created_user_id", "hits", "language", "version") VALUES
media.diff:1321: trailing whitespace.

media.diff:2423: trailing whitespace.

media.diff:2459: trailing whitespace.
        <?php echo $title; ?>"></i>
warning: squelched 211 whitespace errors
warning: 216 lines add whitespace errors.

Hopefully that helps :)

1. We can't do this with JavaScript?
2. Thanks
3. I understand this from the code but it might be good to tell users somehow. In a tooltip this should be possible, or not?
4. Thanks
5. It really is no different than what I described, you upload the image and then click on the title to edit the image and it happens. Now I noticed, it doesn't happen with all images. I found the problem. If you have an image like image.JPG it fails but image.jpg works. Notice the capital extension.

Congratulations Buddhima ^_^

Regarding the code style automatic checker, please have a look at http://docs.joomla.org/Joomla_CodeSniffer

1. Also relates to @Fedik , allowed file types can be configured via Global Config. -> Media Manager. I agree there should be more content-types in future such as com_media.video, com_media.audio, ... etc. depending on the necessity, and com_media.file as the fallback.

I was doing some things the other day and noticed something odd. Although I hardly pay attention to something like this, it now sits with me as something that I think needs to change.

I noticed the fact that Joomla Media Manager uses the images directory as its root directory. For some odd reason I thought it used media. The directory naming for Media Manager in my mind should be "media". As such, the idea of having multiple file types supported (video, audio, imanges, files, ect.), and to achieve some consistency across component developers, would it be possible for a name change? My interpretation of a definition that can be applied to media is anything that has the intent to be editable and consumed and thus managed. Ideally we would need a good standardization of subfolders and structure in general.

Ideally I like media in its current state to be renamed to assets and images to be renamed to media. Although I can imagine some issues in regards to third parties that have been using the directory pathing It is not an easy change, I can only imagine the difficulty there, but it is something that I think will improve the meaning behind the directory naming conventions.

My reason for commenting here is this could be changed with the inclusion of the new media manager.

Changing images to media and media to assets does sound like a good change but I fear that this would be a backwards compatible break so would have to wait to J4

Hey @brianteeman , yeah I figured that was going to be an issue. Maybe introduce a new name? Maybe mediav2, media_manager, do not know. I guess where my consistency OCD kicks in is the directory images does not fit really well with the naming Joomla conveys as the "Media" Manger.

Also why do we not have any PATH Constants for MEDIA and LAYOUTS. If we encouraged developers to use these, the change could be fairly straight forward for future considerations. Instead we would just need to maintain sub-directory structure from the specified ROOT path specified in each CONSTANT. We could freely reorganize the roots of these paths.

Found that a bit interesting...

Any change would be a B/C issue

I agree with Brian. Changing folder names is certainly out of dicussion. It would break more extensions than you can think of
We can discuss this for Joomla 4.0 earliest.
As for the folder for the media manager: You can customise that one already in the settings of the media manager. So feel free to change it on your site.

Hi,
With last commit (#e3fdf0c) I have fulfilled some of your requests:
@Bakual :
Now drag&drop uploader reports errors.
@brianteeman :
Hashing cancelled (hope attacks can be handle by JHelperMedia::canUpload ).
@roland-d :
Some code-style issues wrt sql files fixed.
Modal heights adjusted.
Tooltip for thumbnail folder field can't add since Joomla doesn't support tooltips inside modals.

Some more to solve. But feel free to test current status.

awesome job @Buddhima !

@Buddhima
Second round of testing :)

Codestyle

D:\wamp\www\newmedia>git apply 3839.diff
3839.diff:1321: trailing whitespace.

3839.diff:2459: trailing whitespace.

3839.diff:2495: trailing whitespace.
<?php echo $title; ?>">
3839.diff:2526: trailing whitespace.
<?php echo $title; ?>">
3839.diff:2550: trailing whitespace.
<?php echo $title; ?>">
warning: squelched 224 whitespace errors
warning: 229 lines add whitespace errors.

As you can see there are another 224 whitespace errors, they really must be fixed. In this output I downloaded the diff file to a local file and applied it. Then you can see exactly which line number has the problem in the diff. In this case it is line 1321 in 3839.diff. If you check there you will see that the problem is in the file administrator/components/com_media/controller/media/delete.php

Missing file
"NetworkError: 404 Not Found - http://localhost/newmedia/media/system/css/Jcrop.gif"

Size of input fields
For the Resize option the input fields have a logical width but for Rotate its too long and with Create thumbnails the Thumbnail size field can be shorter.

Tooltip in modal
I was able to see the tooltip at some point but it was behind the modal and in black. So not very visible. What we might do is add a little description below the Thumbnail folder to indicate to the user where this will be created.

Mixed case filenames
Just wondering if we should use mixed case filenames. I would prefer to just have lowercase filenames. Any ideas on this guys?

Untranslated strings
In the file \administrator\components\com_media\model\field\mediathumbs.php method getInput() there are strings that cannot be translated. This file is also missing the empty line at the end of the file.

That is all I have time for today :)

Changing to all lower case names would introduce b/c issues

New files need to be lowercased for sure. Existing files can't be renamed due to backward compatibility.

So the newly added file ftpValidate.php needs to have a lowercased name.

Why do new files have to be lowercased? What is the advantage?

Why do new files have to be lowercased? What is the advantage?

To clarify. My comment was about files included with this PR, not about files uploaded with the Media Manager.
This is to avoid possible problems with different enviroments. Especially Windows machines which don't threat uppercase filenames as different from lowercased ones, whereas Linux machines will look at them as two different files.

For user uploaded files, I usually recommend to use lowercased filenames and no spaces and no special characters, just to avoid possible problems. But I don't care if that is enforced or not. That may well be a users choice.

On Jul 6, 2014 11:26 AM, "Thomas Hunziker" notifications@github.com wrote:

For user uploaded files, I usually recommend to use lowercased filenames
and no spaces and no special characters, just to avoid possible problems.
But I don't care if that is enforced or not. That may well be a users
choice.

I would personally like see this enforced for consistency with URLs to the
files. Maybe something like stringURLSafe.

Matt Thomas
203.632.9322
http://betweenbrain.com/

Sent from mobile. Please pardon any typos or brevity.

I wasn't clear in my statement about the filenames, I meant the name of the files added by this PR, not the user uploaded files.

Sorry for my misunderstanding

I would personally like see this enforced for consistency with URLs to the files. Maybe something like stringURLSafe.

It would certainly be a nice feature. I would however make it an option in the media manager so the admin can decide if he wants to enforce that or not.

@Buddhima Wow! Great work!

For the thumbnails I would like to suggest that the checkbox and delete buttons are moved up to the top of the thumbnail. Traditionally that is where they belong and it would also allow for showing longer files names which would be super nice.

http://i.imgur.com/t1Dqca3.png

I would also recommend that names should be allowed to be quite a bit longer before they are truncated by PHP and then instead use CSS overflow:hidden on the parent element as this will allow the longest possible file names.

For the image editor I would like to recommend using the following icons for the buttons:

Crop: glyphicon-move
Resize: glyphicon-resize-small
Rotate: glyphicon-refresh
Filter: glyphicon-filter
Create thumbs: glyphicon-th-large

@aDaneInSpain I don't think glypicons are included in Joomla. All others are IcoMoon. Perhaps:

Crop: There is a crop icon in the free version of IcoMoon, but it isn't in the Joomla version. Perhaps we can introduce this?
Resize: icon-contract-2
Rotate: icon-loop
Filter: icon-equalizer

@Buddhima Just have a few issues:

1. When uploading an image in a subfolder, I'm automatically being redirected back to main folder view.
2. COM_MEDIA_FIELD_MODIFIED_DESC is missing a translation
3. Jcrop.gif is still missing
4. The modal window in the editor plugin is way too big. See the screenshot:

@Buddhima There is an issue in the current media manager where the FTP username/password are not being used because it is in a form of it's own rather than in the same form where the upload option is. Please check if the new media manager works with the FTP layer and the credentials entered in the media manager upload form. Thanks.

Hi,
Thank you all for suggestions !

@losedk & @aDaneInSpain : Considering both of your suggestions, I have changed toolbar icons. So now they looks like this:

@roland-d : I'll check FTP & Code-style issues as the next step.

@Bakual : During last few weeks I was working on displaying images when click in tags list at FE. It was not just fixing FE com_images. I had to completely change the way how com_media was using tags. After all and with the PR to fix a bug in TagsHelper : #4059 , I managed to get the thing work.
So now at the FE, the image can be seen as follow:

Thanks!

Hi,
I have done some changes to make FTP work. Still it works as a separate form where user can enter credentials and submit (to get saved in the session).
@roland-d : Can you please check FTP with media manager now?
Currently form looks as follows:

Thanks!

@Buddhima I am having several issues. All tests have been done using the FTP layer.

Saving credentials
Saving the credentials in the session is problematic for when you make a mistake. You need to log out and login to be able to re-enter, not intuitive for users.

Creating a folder via FTP

This works but the trailing slash should be shown for clarity.

| Create Complete: \test1
Would be good I think to show the full path to rule out any confusion as to where it is created

File upload drag n drop

The 2 files in green uploaded fine but the 2 files in read did not upload to the site and no message either. Only difference is their size so I checked and the upload_max_filesize is set to 2MB. This explains the failed upload but some kind of failure notice would be good. Increasing the upload_max_filesize to 14MB and restarting the server still won't let me upload the files. The upload limit in the media manager settings is set to 10MB.

When I close the upload modal and later reopen, the old uploads are there. Would be good to empty the list when the users clicks on Close. The list may get very long and with every upload being added to the bottom you can't see them. Adding the last uploaded file to the top will also be useful.

File upload regular
This results in a page with the message "The most recent request was denied because it contained an invalid security token. Please refresh the page and try again." in green. Should be red since it's an error.

So much for now, sorry for the bad news.

Hi @roland-d ,

• Slash at the end was added with last commit.
• Now latest upload displays at the top of the list
• Made the 'message' to 'error' as you mentioned

Saving credentials:
If credentials are wrong, it won't save at all. Once you save credentials, it remains until session expires. If you go through code related to ftp (in libraries) you will see that, this is the way how it supposed to work.

Uploading issue:
As far as I know, there are 3 upload limits. They should be ordered by size as follows:
Joomla! limit < upload_max_filesize (in server) < post_max_size (in server)

I tried uploading images with different sizes and faced the similar situation when file size exceeding post_max_size
Below post_max_size limit and above Joomla! limit, you'll get uploading failed error in both Drag&Drop and Regular uploader.

Thank you!

@Buddhima Thanks for the update, found some time again to test. Here goes ;)

Fancy uploader

See here the result of my upload using the fancy uploader. The first file shows as uploaded but it never did because the size is too large. This is wrong, if the file can't be uploaded it should give an error, not OK.

The second file is an error and that is good but it renders partially off the screen.

Having these scrollbars give other problems.

Regular uploader
First clicking on the Browse button and selecting 20 files to upload for example and then click the Upload button, I get this screen:

Can we deal with this in a more graceful way?

Resizing images
After I uploaded an image I click on the name to edit the image. Now I can't save the image because the category is required and I have not defined any categories. However, I can still resize the image. I wonder if we should have a category selector in the upload screen. That way we can also mass upload into a selected category.

Creating thumbnails
When I enter a size, the thumbnail is created to exactly that size. I believe it would be better if the thumbnails would be proportionally resized so I don't end up with deformed images. For example I enter 100x100 and the thumbnail is either on the left or the right side max 100 pixels, whichever comes first.

Image options
Not sure what to think of this. Once I choose a filter, there is no way back. I can't undo the filter, I will have to re-upload the image again. The same goes for some of the other image options. Perhaps, we can keep a copy and once the image is saved we delete the copy otherwise restore the copy.

FTP credentials
Works fine, well done.

Last used folder
I would like to see if we canremember the last used media folder, that way users don't have to navigate all the way back to the image. For example, I am in a sub/sub/subfolder and find out I need to create a category. Going to the categories and then back to media, I start from the top again.

Detail view
In other views in Joomla! the checkboxes are the first column, we should keep the same layout.

That is all for now as I think I have covered what I wanted to cover. Well done on the work and we are almost there ;)

Hi @roland-d ,

I fixed the issue showing wrong message with large file uploading.
For renders partially off the screen, I had no option other than slicing file name. (Usually 28 characters are fair enough to identify a file uniquely)

Resizing Images
Currently Saving means saving image related data. Not the changes done to the image.
I recently added uncategorized category for media.

Creating Thumbnails
You are free to select any Thumbnailing Method which is available in Joomla, so give a try with another method. Also I think constants at here: JImage , should be mentioned descriptively.

FTP Credentials
Thank You!

Last used folder
Good suggestion, but still you can use tree-view to do deep at once.

Detail view
In media those checkboxes are still not using other than delete, so there won't be any use case of this.

Image options
Again a good suggestion. I think such implementation should be align with versioning in contents.

Thanks!

Joomla! 3.3.4
Media manger file upload does not work for me.
Page not found after click on upload button.
I am getting this url, beginning with
"undefined://index.phpundefinedundefined?option=com_media&task=file.upload&tmpl=component&.............."

@test
Environment: Joomla! 3.3.6 with test data loaded - PHP 5.5.10 - MySQL 5.5.34 - Apache 2.2.26 -> MAMP Server on OSX 10.9.5 - Browser Safari 7.1
Issues:
1. Media Editor:

1. doesn't have an undo function
2. the Resize doesn't have a checkbox for proportional scaling (user expects to can resize proportional or the dimensions separated)
3. the Crop icon is not intuitive; losedk suggestion of Jul 13 is consistent to user's experience in other environments than Joomla!
4. Thumbnail -> field Thumbnail folder: would be better a drop-down with folder structure: a normal user doesn't open a FTP session, to see where to save the image
5. Rotate could have the standard 90 right, 90 left, 180 options (eg. radio buttons) to fasten most used rotations
6. Crop is behaving different from the other functionalities: all other open a popup to do their job, crop gives an error message "select an area to crop" when clicking on the button. This is a little confusing. User expects also to open a pop-up and then do something.
7. the window is not mandatory, it's possible to select a menu entry eg. System/Global Configuration and open that window. So all changes to the image will be lost. If you do the same in Articles, the menubar is disabled until you save and close or close the window.

1. Media Manager:
   1. by clicking on detail view button following error message arises: An error has occurred. 0 Layout Path Not Found
   2. the same happens from the detail view by clicking on the thumbnail view button
   3. Categories doesn't have the default "uncategorized" entry. I suppose it depends, that the patch was uploaded with Joomla! Patch Tester
2. Uploader:
   1. Regular uploader: doesn't work; an error message appears, saying that there is no application to open that url. This is the url: undefined:///pizza/administrator/index.php?option=com_media&controller=media.upload.media&format=html&folder=banners
   2. I suppose that drag&drop upload is not ready jet: it's just possible to drag files on that or to remove them, nothing more happens
3. File names of media: please keep in mind that also grandma' could use media manager to upload files to her album about her grandchildren, and she doesn't know about uppercase/lowercase/spaces and so on. She picks her photos form the camera and uploads them! Also keep in mind that 70% of user came from Windows and they expect to have the same behavior of the software as big daddy's software does. Good experience, good software... ;)

Sorry if I can't contribute with technical infos. I hope my feedback will help the project. I think this is a really great step forward for Joomla!, because a good web presence is based on images, so a good media management tool in combination with photo galleries, sliders and so on is absolutely a must to be in the core of a CMS. Thanks to Buddhima for his work, and I hope to see soon this extension in Joomla!. :)

P.S.: when ready, also testing to upload more than 1000 photos at once. All existing components have problems to handle this, but grandma' will try to do it! :D

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3839.

@catanet Thanks for your testing as well :)

P.S.: when ready, also testing to upload more than 1000 photos at once. All existing components have problems to handle this, but grandma' will try to do it! :D

@Buddhima Can you resolve the merge conflicts?

@gmng Did you use the repository mentioned in the document?

@Buddhima Did a little more testing
The JImage page you linked is superslow to load. Not sure what is happening there.

Last used folder
Yes we can use the tree but if it is remembered it will be more user-friendly.

Image options
Using the versioning here might be a good idea.

Upload window
The upload window still has some quirks:

So, when I am hovering over the table rows, I see this screen, when I go to the slider the table takes it normal size and I can see it all. I think the hover shouldn't have an effect on the table so it always fits nicely.

The error message is as expected! So that is good, only thing I would want to suggest is to center the message.

That is all for now, I think we are almost ready to go :)

I wonder if it's possible to split this PR into some smaller ones. Like one for the UI changes and one for the drag and drop uploader and so on.

Currently I still have some fundamental issues with this PR:

• First it extends from classes in com_config. I understood that the intent is to use the new MVC class from @wilsonge new MVC project. Until that is done I would be strongly against merging this PR as extending classes from another component is only going to give us trouble later on.
• Second I really question the use of the #__ucm tables to store the media informations. I would much prefer to use own tables for the media manager and only use the #__ucm ones for tags and history. I have the impression those tables need a full rework (or even drop) at least for 4.0 and I'd rather not add more to the plate here.

I haven't looked at the code but just tested the functionality but looking at the arguments made by @Bakual I do agree with them. Rather use media tables than the UCM tables as the future is unsure for that. As for the new MVC, it is not even part of the core, so we shouldn't be using that.

I think UCM tables make sense to use. I disagree I think it was buggy (like most new features when they come into the CMS). However they are stabilising and it makes sense to take them a step further by moving a component across to use it and see how that runs

I kind of agree with MVC - but new MVC I'm working on is gonna need some more time before it's ready for mass market - we had a couple of hours one evening discussing it at the code style sprint actually working out where we came improve without effecting users too badly.

Using the UCM tables will primary limit us in what we can do later on with that media data.

Try for example adding a filtering for a filesize or something like that. With own tables, we could do that since we can have a "size" database field, With UCM tables you would have to filter by part of a metatext field which is not something you should do at all.

I also think that put the data from the different Content Types in to the one table not very good idea...
And in theory should be no problem define a standalone table in the Content Type mapping

@Bakual you'll always still be able to "extend" from the UCM tables. Just because all the common data is in #__ucm doesn't mean that ALL of it must be stored there. If there are surplus columns then you can extend that out with. For example the special fields in com_banners - it's never intended that all those fields will be put into #__ucm_content - only the ones where it makes sense to do so - so you can see in the field_mapping column the standard fields are in the "common" section and the extra fields in the "special" which will stay in the #__banners table

I know, but I find it stupid to store that stuff in two tables which you can't join easily.
You need the #__ucm_base table to join a #__media table with the #__ucm_content table. And you likely need to throw in #__content_types as well or you end up filtering using the type_alias (a text field!). However as soon as we're talking about multiple content types for com_media, the whole thing gets out of hand.

The current UCM tables were buiilt as a bandaid for tags. They should have never been called UCM. And imho they're not a good fit for a MediaManager anyway.

Well then if you know that then you know the thing about storing in metadata is simply not true....

I have to say I'm not quite sure what the deal with #__ucm_base is as #__ucm_content contains langauge and content type id. But based on that you'd need a 3 way join. #__ucm_content, #__content_types and the third 'special' table. And tbh I think that's about right.... You don't wanna have the content type info stored with each item.

I disagree as well. The fact most components have been able to merge in with tags without too many issues to me proves that actually they aren't all that bad. My argument would also be that we have to give UCM to the 50% and not the 99% (see http://blog.ircmaxell.com/2014/10/an-open-letter-to-php-fig.html) and I think the current implementation (whilst buggy sure) does that to a reasonable extent. Look how easy it was to plug content history in after tags as evidence of that....

Ah true, you don't really need the base one. #__ucm_content also stores the item id. It's crazies than I thought.... Wanna talk about duplicated data in the database?
You still need it if you want to create efficient filters, because filtering by the type alias isn't really nice. But maybe it's better than doing that join over the base table.

The reason why tags work relatively simple is because it duplicates all the data from the extensions into its own (UCM) tables. And it is also part of the reason for many of the issues we still have with tags (and history).
Again, want to talk about duplicated data in the database?

Hi All,

With in last commit there are some changes I did for style and several issues raised.

@roland-d : I did some changes in uploader styles.

Thank you!

@Buddhima this looks out of sync. Can you resync?

maybe we need also to apply Media manager: hide the Up button when in base directory #5704

Hi @zero-24 ,
Now this is synced back and included the mentioned change.
Thanks!

sorry @Buddhima just one hour ago @infograf768 merge another fix for com_media #5722 can you have a look into it?

If i get some free time i will test it. Thank you so much for your work here!!

Hi @zero-24 ,
I added changes in given PR .Thank you for pointing it and appreciate for paying your attention on this.

Hi,

here are some results / issues

The create and delete message don't include that ist was a folder that was deleted or added.

if you press the delete button without make a selection you get this view.

The create folder modal on windows. The folder looks a bit messed up.

Can we make the images better ti overlab with the select and delet buttons.

Can we have a look into the sidebar? It looks we have min a line to much here.

Can we add here a decription that explains what is the stating point?
\www\... or \images\... or \banners\ etc.

can we make the uploader / the progressbars better? The successful is very smal and the errord have not the same length.
maybe we can make the progressbars a bit bigger and with rounded.

I will do more testing if i get time again

@Buddhima

can you add the default category uncategorised category to the install sql files?

maybe we should use Uncategorised instead of uncategorised @brianteeman ?

Hi @zero-24 ,
I already have added that : https://github.com/Buddhima/joomla-cms/blob/new_com_media/administrator/components/com_admin/sql/updates/mysql/3.5.0-2014-06-28.sql#L4
Thank You!

I already have added that : https://github.com/Buddhima/joomla-cms/blob/new_com_media/administrator/components/com_admin/sql/updates/mysql/3.5.0-2014-06-28.sql#L4

Yes. But this is only for updates

We need it also here:
https://github.com/joomla/joomla-cms/tree/staging/installation/sql

IIRC at the joomla.sql something like:
https://github.com/joomla/joomla-cms/blob/staging/installation/sql/mysql/joomla.sql#L240-L246

Hi @zero-24 ,

Thank you for the feedback, it took a bit long period to have a look at those. So following are the main changes done so far.
1. Create & Delete messages for folders added separately.
2. Redirection after delete (false situation) is working fine with an error message
3. Create folder path fixed. Have to use / since all operating systems supports that. I appreciate if you can have a check on that since I'm currently working on Linux.
4. Thumbnails refactored once again.
5. Starting point to Create Thumbnails added.
6. Uploader progress bar always caused problems :( . Since now modal supports responsiveness, moved back to %-based separation

Also, I think there's no need to change uncatagorised term. It has no difference from other cases.

I think moving these to installation file should be done at the end, else this PR will get conflicts more frequently.

Would like to know your thoughts and experience with current implementation.

Thank you!

How can we move this awesome contribution by @Buddhima ahead?

@losedk Unfortunately this PR can't move ahead as it stands now because it is depending on other code changes that have not yet been decided upon and in addition it is extending from com_config which is not preferable.

Personally I would love to see this go into Joomla, hence all the testing I have done, but code-wise it isn't there yet. If we are to move ahead, the code changes should be updated to fit into the current codebase of Joomla.

I need to put my 2 cents in to this conversation. So at least later on I can say I tried to prevent this.

The single task controller design in com_config and this component is flawed. 21 controllers to push 2 models with 4 views in the admin area is just not sustainable.

Please do not merge this feature without carefully considering the conversations 6 months from now when the joy of a shiny new feature turns into the grind of maintaining another overly complex system.

I know a lot of people want this new feature, but I ask them to consider how useful it will be if every few minor releases it breaks unintentionally. Simply because in the 8000+ new lines, someone didn't realize changing X here would break Z there.

@Buddhima I appreciate the hard work and initiative that it took to bring this much desired upgrade to the Joomla community.

So please don't be offend by my comments. The architectural design is the recipient of my criticism. It is not directed at you or your code.

If you haven't heard me ranting on twitter or the google group, I've come up with an alternative approach to single task controllers. I'm calling it MVSC.

If you are interested in looking at the design check out the com_config rebuild, It isn't complete but it should give you a good idea of how MVSC is different from your approach.

https://github.com/icarus/logical-j/tree/com_config

Hi @losedk , @roland-d , @Mathewlenning et al.,

I thought of raising my voice at this point since discussions flow seems forgetting the initial point.
In my comment 1st July, 2014, I have clearly stated that "After completing new MVC project, this also will need to refactor. "

New MVC in Joomla is an effort to introduce single task controllers. I have done it for com_config. As you have done with sample, in com_config refactoring, I initially put base classes to lib. But unfortunately have to take them out at the end. I know @wilsonge continued it and I also know @Mathewlenning helped @wilsonge a lot during his project.

Also I have mentioned in the doc that, this is ti stimulate the necessity of single task controllers (I refer as new MVC and @Mathewlenning refers as MVSC).

Finally what I need to see is that, when single task controllers in the Joomla! core, this need to be modified accordingly and merged to Joomla! CMS.

Thank you!

Greetings from JUC-Munich we tested your new Mediamanager with 6 people.
We are happy with the new media manage and happy that you extend it - the current one really needs some work.
Thanks for the good work we hope that this patch will be released as soon as possible.

Bugs:

• After scrolling down (on a big image) the editor buttons (Save, Crop, Resize….) are not clickable anymore.

• After uploading files, the file extension should always be lower case - and if someone uploads the file the first time, the media manager should rename the file extension to lower case. Otherwise there will be issues on linux. (will not open the image on linux and Joomla will throw a JERROR)

Suggestions:

1) Rotate/Crop/Resize
All features should not overwrite the original image while live editing the file but store a copy of the file the first time and on further editing it should overwrite the first/manipulated copy of the file. Not the original one.

Example:
I uploaded a picture, and rotate it now. While i click the rotate button it overwrites my original file. Which is not good.

It basicly should always keep the original file and should store the changed image as a new version (as a copy).
Also while editing the image chan on the fly should not change the file in the file system. It should save the (new copy) as soon as I apply/save the changes of my image.

2) Image Thumbnail Folder
The thumbnail folder should be a (global) option of com_media. Therefore we don’t have to type the folderpath every time.

3) Rotating
Add Buttons for: „90-Degree left“, „90-Degree right“, „Flip horizontaly“, „Flip verticaly"

Usability enhancements:
For the usebility approvments it would be nice to add folowing features:
The options for the Rotate/Crop/Resize tools are currently opend in a modal box. It would be better to implement them differently for better usability:

Option 1:
Options for the Buttons will be show as slideout/dropdown after clicking the button like it is the case in com_articles list when you click on „Search Tools“

Option 2:
Use „Tabs“ for the Buttons and place the Image on the left side and the options for the tools on the right sidebar

Optional for better usability you can take a look at this script See here

NO NO NO.. do NOT make a copy with every edit.. good grief man!!! you
could easily wind up with 100 copies of the same damn file!!
when you hit SAVE you save OVER the original file. and you don't touch
that file UNTIL the user has hit save.
if a temp file is needed for edits, thats fine, but don't overwrite the
original until "save"
Bear
On 3/14/2015 12:03, Patrick wrote:

Greetings from JUC-München we tested your new Mediamanager with 6 people.
We are happy with the new media manage and happy that you extend it -
the current one really needs some work.
Thanks for the good work we hope that this patch will be released as
soon as possible.

Suggestions:

1) Rotate/Crop/Resize
All features should not overwrite the original image while live
editing the file but store a copy of the file.

/Example:
I uploaded a picture, and rotate it now. While i click the rotate
button it overwrites my original file. Which is not good./

It basicly should always keep the original file and should store the
changed image as a new version (as a copy).
Also while editing the image chan on the fly should not change the
file in the file system. It should save the (new copy) as soon as I
apply/save the changes of my image.

@N6REJ Maybe you missunderstood us, or i missunderstand you.

But that's how it should work in our opinion:
1. You upload an image (original file)
It saves this one. (just like it always does)
2. You edit the file (rotate it) and ONCE you click save it stores a copy and NOT right after you edit the file.
3. You edit it again, you overwrite the first/manipulated copy. So the copy is always the current, but changed version. And this way you always have the original file backed up. And you don't get 100s of copies since you overwrite the manipulated version.

Why should it be like this?
Well, you ALWAYS need a copy of the original file for being able to restore the changes you did. Let's say the user edits his uploaded image - for example crops it - and then the media manager overwrites the changed file right away and replaces the original file (like it is currently the case) - then you can NEVER go back to the original file. That is just bad in terms of usability.

You NEVER NEVER NEVER do that. Not in Photoshop (keyword: nondestructive/descructive workflow) nor in any other (web) based image editor. Every serios image editor keeps the original file so the user can always restore to it's original state. (in case of photoshop the user should work nondestructive)

Current state (Bad):
The user changes his uploaded file, for example crops it and the original file is overwritten. He can NEVER go back to the original one unless he reuploads his file.
Worse:
Currently the media manager saves every single change right AFTER you manipulated the file. You don't even have to click "Apply" or "Save". So once you croped your file, there is no chance in going back, you can't even use the "Cancel" button. You have to reupload the original file.

+1 for this change proposed. It doesn't really make sense to overwrite the old file until the user clicks save

hello some return about end user mode
1 i think we have too much view => it will be better to drag and drop for upload on main view without open popup
2 rezize option isn't realy good end user don't whant too typ zsize => it will be better to have a dropdown list with more commun size and custom value to display field for custom size (with a default value checked in params)
it realy a wonderfull work !!! very important adding for j3.5 i hope

Hi All,

With the recent commits to this, I would like to introduce you 3 new things to this project.

1. Undo changes
   From here onwards, when you do change image (eg: crop, resize) through Editor, it won't affect the original image. Once you click Save, modified image will replace the original image. If you click Cancel, modified one will be discarded.
   Talking in technical terms, the modified images will get saved under '/tmp/com_media' folder. So that will be replaced original or discarded on the interest.

2. Image flip functionality
   This was a missing function in JImage. So I included it in a separate PR for JImage, and use that in here as well. Please refer PR #6571 for further clarifications.

3. Add image rotate direction selection & convert image extensions to lower-case on upload.

Thank you all of you @N6REJ , @micker & @Chalkin (for JUC-Munich) for testing this. I will try to fulfill requested features as much as possible.

I also like to see this in Joomla! 3.5

Thank you!

i like new features - nice job! :)

one big issue right now is that there isn't a good solution where users can access only specified folder... generated user folder during registration would be also good option. this helps to prevent case where there is one monster heavy picture folder and users can find their files/photos easy.

or nice option would be also if user wants upload photo to article then in upload window user sees only upload tab, in second tab is my uploaded files and third tab is all folders (if admin allows it) ---same solution is in google docs :)

Hi All,

With recent commits I added video preview, and audio preview support for the new media manager. I believe it would help to provide better user experience.

Video Preview :

Audio Preview :

Thank you!

@Buddhima
Looking good!
Can you take a look at #5871 and also incorporate the changes I made there in the file controller.php here?

Also you are using mootools modal here, we are trying to render everything with bootstrap. I can make a PR changing that, if you want...

@dgt41
I'll have a look at your implementation as well. I would appreciate if you can send a PR.
Thank you!

@Buddhima will do that this weekend. Are there any other places where you use mootools modal?

@dgt41 I don't think so, because I used bootstrap modals for Media Editor popups. For video & audio popups, they need to come-out-of iframe as well. At the moment I wasn't able to do with mootools.

@Buddhima any idea when we can expect this to be merged? 3.5 or later? We need a more advanced Media manager for a project and this sounds exactly like what we need. But considering deadlines it might come to late.

Hi @danielsmink , According to the discussions above, it's sad to say that still this is not planned for Joomla! 3.5. For your case, you can take this and modify accordingly.

if its ready, why is it being stopped?
Bear
On 9/8/2015 02:58, Buddhima Wijeweera wrote:

Hi @danielsmink https://github.com/danielsmink , According to the
discussions above, it's sad to say that still this is not planned for
Joomla! 3.5. For your case, you can take this and modify accordingly.

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

if its ready, why is it being stopped?

It's not ready due to two main points. Those are code/architecture issues and not user interface issues.

It depends a lot on classes from com_config, which is a no-go.
It either has to

• wait for the "new MVC" classes @wilsonge wanted to write, and then be rewritten to extend those,
• rewite the whole thing to directly use the base classes for the "new MVC" in the library folders
• or rewrite the whole thing to use the legacy MVC

It also still uses the UCM tables to store the data, which I would prefer when it would not do that. UCM as it is of today will likely be changed or even removed with J4. So we would face a rewrite then again.

damn, ok.

Bear
On 9/8/2015 09:32, Thomas Hunziker wrote:

if its ready, why is it being stopped?

It's not ready due to two main points. Those are code/architecture
issues and not user interface issues.

It depends a lot on classes from com_config, which is a no-go.
It either has to

• wait for the "new MVC" classes @wilsonge https://github.com/wilsonge wanted to write, and then be rewritten to extend those,
• rewite the whole thing to directly use the base classes for the "new MVC" in the library folders
• or rewrite the whole thing to use the legacy MVC

It also still uses the UCM tables to store the data, which I would
prefer when it would not do that. UCM as it is of today will likely be
changed or even removed with J4. So we would face a rewrite then again.

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

Since this PR is never going to be merged as-is I am going to close it. @Buddhima thank you for your work and I will continue to work on trying to get features moved over into the Joomla core.

Those of you who want to work further with this code can go to Buddhimas' repo at: https://github.com/Buddhima/joomla-cms/tree/new_com_media

Thanks everybody for the feedback.

Come on - obviously there are several considerations to this PR, but there is a tremendous amount of work put toward this product that would transform Joomla! usability. Merge this thing and let the community contribute to the updates afterwards rather than killing the momentum. Good job @Buddhima.

yes dont kill this important feature all users need it

Just to clarify. Is not a close forever. Is just a delay. We really appreciate the work done here and we all what to see it happening soon.

Any news on this?

We're working on porting the features back into the existing MVC system here https://github.com/joomla-projects/media-manager-improvement but progress at the moment is reasonably slow. We are aiming to have most of the things from this PR ported into that for 3.6 in the next month or so however

The latest code for this is here: https://github.com/jissereitsma/media-manager-improvement

If you have a little time to spare, please test and provide feedback. Thanks.

why two separate repos?

Why just have one when you can have two or more ;)

It may be late suggestion, but are there any reasons for not creating just an extension repo, similar to joomla-extensions/weblinks?

Because it's not a properly decoupled extension like weblinks.

From brief look at the diff, it looks like two changes preventing decoupling are:

• libraries/cms/form/field/media.php
• libraries/cms/helper/media.php

The rest considers com_media or may be added as pull requests to Joomla core (JImage::flip, added CSS, drag'n'drop upload).

I'm interested in decoupling for testing purposes. IMHO this component is too tightly integrated with core to decouple it in sense of removing from distribution.

Imho, you can't decouple com_media. It's an extension like com_categories which always should be present. Various 3rd party extension will also depend on it being present (and be it only by using the formfield).
Personally speaking, I'd say it's wasted time trying to decouple the media manager.

from the theory point of view, it could be similar to Captcha:
Joomla itself provide just the "media" field, that display the input depend from which "Media manager" are default.

My motivation in decoupling is to be able to install new media manager snapshot in J3.5 installation (before it's released in J3.6, if it is).

As I've written before, I consider media manager as a core component, like com_config and for sure it shouldn't be distributed separately but developed atomically.

You can just download and install the entire branch

On 28 April 2016 at 14:06, Piotr notifications@github.com wrote:

My motivation in decoupling is to be able to install new media manager
snapshot in J3.5 installation (before it's released in J3.6, if it is).

As I've written before, I consider media manager as a core component, like
com_config and for sure it shouldn't be distributed separately but
developed atomically.

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

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