New Media Manager for Joomla! CMS

[Buddhima Wijeweera]

Hi Devs,

I'm so happy to inform you that, I was able to complete the Media Manager project. This project carried out during last 6 months by myself and now I'm unveiling it. With this project I have introduced 12 new things to Joomla! existing Media Manager. Those 12 things include; Drag & Drop uploader, New MVC for Media Manager, Image Editor, ...etc. which were requested by community from a long time.

Complete details about this project can be found in the following document:

https://docs.google.com/document/d/1mZMwBU_hW7AshL5rkAdIyswQmzBmP1L8L1PdM093rB0/edit?usp=sharing

Pull Request for the implementation:

https://github.com/joomla/joomla-cms/pull/3839

Please follow the test instructions before testing:

=== Testing instructions ===

It is highly recommended to go through following instructions before testing.

1. The recommended way to test this project is to get a clone of project branch separately. And then add the above (point 12 in doc) mentioned content-types into content-type table in joomla database. since this implementation will add new entries to database, this method will not affect your ongoing development.

2. Still, you can also use PR tester or any other preferred method, and you need to add above (point 12 in doc) mentioned content-types into content-type table in joomla database. If you do not worry about adding new entries into your database, you can go ahead with this method.

As the conclusion, I'm expecting your constructive feedback on this implementation to make this success.

Thank You!

[Leo Lammerink]

Buddhi,
This is Awesome ! I have read through your document and I am very much excited to test this new Media Manager and it's features. From what I have seen this looks real GOOD as is already and way better compared to what we have now. I am also glad you open the door by asking for support on features you like to add and where you need additional guidance. You can be very, very proud of yourself for bringing this to this community notwithstanding the comments that will certainly come rest assured.

@ PLT: Can we please take this on very, very seriously since this is a major development and assist Buddhi wherever we can?

@ Buddhi,
Gonna go and read again and test this for sure the next days....... Thank you so much for all you have done and the extensive contribution to the project!

--

Leo Lammerink
MD GWS - Enterprise Ltd
Skype: gwsgroup
www.gws-desk.com | www.gws-host.com | www.gws-deals.today

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[Bakual]

I agree, please test this out if you have some spare time.

It looks very promising so far and Buddhima did an awesome job there.

[Matt Thomas]

Awesome work Buddhima! I look forward to testing this tomorrow morning (GMT - 5).

Matt Thomas
203.632.9322
http://betweenbrain.com/

Sent from mobile. Please pardon any typos or brevity.

--

[Viktor Vogel]

Hello Buddhima,

thank you for your hard work! I will test your implementation as soon as possible.

Regards
Viktor

[AlexRed]

Fantastic!   :)

In my test I can't "resize" and "rotate" the images. But "Crop" and "Filter" is ok.

[Troy]

looking good.  Can we please include the ability to upload a raw bmp with space in the name and convert it into a .jpg or .png whichever with the space removed and replaced with some alternate char ( - or _ ) perhaps?
This is something my members run into daily

Bear

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4592 / Virus Database: 3986/7764 - Release Date: 06/29/14

[Paul Orwig]

Hi Buddhima,

Thank you for sharing your work, along with the supporting documentation! Including significant media manager improvements would be a major step forward for Joomla.

Thanks also to the people who you mentioned have helped you with this project: Elin, Chad, Janich and David!

I hope your code will make it into Joomla if it passes tests and meets other requirements. If that happens I hope that others will volunteer to implement more improvements including those mentioned in your supporting document.

Best regards,

paul

[Nick Savov]

Hi Buddhima,

Excellent! Great job! I'm going to schedule time to test it for you.

Kind regards,
Nick

On Sun, June 29, 2014 12:15 pm, Buddhima Wijeweera wrote:
> Hi Devs,
>
>
> I'm so happy to inform you that, I was able to complete the Media Manager
> project. This project carried out during last 6 months by myself and now

> I'm unveiling it. With this project I have introduced *12 new things* to

> Joomla! existing Media Manager. Those 12 things include; Drag & Drop
> uploader, New MVC for Media Manager, Image Editor, ...etc. which were
> requested by community from a long time.
>
> Complete details about this project can be found in the following
> document:
> https://docs.google.com/document/d/1mZMwBU_hW7AshL5rkAdIyswQmzBmP1L8L1PdM0
> 93rB0/edit?usp=sharing
>
>
> Pull Request for the implementation:
> https://github.com/joomla/joomla-cms/pull/3839
>
>
> Please follow the test instructions before testing:
>
>

> *=== Testing instructions ===*

> It is highly recommended to go through following instructions before
> testing.
>
> 1. The recommended way to test this project is to get a clone of project
> branch separately. And then add the above (point 12 in doc) mentioned
> content-types into content-type table in joomla database. since this
> implementation will add new entries to database, this method will not
> affect your ongoing development.
>
> 2. Still, you can also use PR tester or any other preferred method, and
> you need to add above (point 12 in doc) mentioned content-types into
> content-type table in joomla database. If you do not worry about adding
> new entries into your database, you can go ahead with this method.
>
>
> As the conclusion, I'm expecting your constructive feedback on this
> implementation to make this success.
>
> Thank You!
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to joomla-dev-cm...@googlegroups.com. To post to this

> group, send an email to joomla-...@googlegroups.com. Visit this group

[Buddhima Wijeweera]

Hi All,

I felt really happy about the appreciations! Thank you so much !

Let me have a look at issues mentioned here:

@AlexRed:

I didn't get this problem from anyone else. Can you please check that this type of form-fields work properly ?

https://github.com/Buddhima/joomla-cms/blob/new_com_media/administrator/components/com_media/view/editor/tmpl/default.php#L174

It seems your template CSS does affect the appearance of those fields. Some tool like Inspect Element in Chrome & Firefox will help you.

@Bear:

I like that too! But I think it should be implemented in the libraries. Following link will direct you to a similar case in JoomlaCode.

http://joomlacode.org/gf/project/joomla/tracker/%3Faction%3DTrackerItemEdit&tracker_item_id%3D13890/?action=TrackerItemEdit&tracker_item_id=32863&start=8150

From the Github discussions I feel 2 points need more concentration:

1. Fixing issue with Drag & Drop Uploader. Need someone has JS knowledge to have a look.

2. Hashing file names. - I still think it is important to concentrate more on security. 

At here I would like to propose a solution, which has both original file name and hash. (eg:- sunshine-hash.jpg for uploaded file sunshine.jpg ). Hope this will not affect SEO negatively.

Also, I'm thankful to everyone who tried to make the document better.

Thank You!

[Bakual]

I don't really understand yet why you even want to hash the filenames. I don't see any security risk with using original filenames.

Hashing the filenames for security reasons sounds like "security through obscurity" which is a false sense of security in most cases.

[Nathan Hawks]

If filenames are stored hashed, and only the hashed names are checked for collision, it prevents an (eventually ACL-enabled) Media Manager from exposing other users' filenames during existence checks.

[brian teeman]

On Wednesday, 2 July 2014 21:28:16 UTC+1, Nathan Hawks wrote:

If filenames are stored hashed, and only the hashed names are checked for collision, it prevents an (eventually ACL-enabled) Media Manager from exposing other users' filenames during existence checks.

On what basis can you possibly make that statement

[Nathan Hawks]

If/when collisions (overwrites) start to be trapped against for e.g. ACL purposes, there'll either be a layer of abstraction (involving a hash in the filename) separating the user inputted filename from the destination filename. Thus if someone wanted to try and guess filenames in a protected use case, they would be up against the hash in addition to guessing an existing source filename.

Seemed too obvious to explain, honestly.

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/nYM85PxNTi8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Nathan Hawks]

I'm always forgetting bits of emails I can't understand why it's necessary to write.

"either be" ... "or there won't. If there is, then the hash that got added, becomes part of the guesswork."

[Bakual]

If you want to protect access to the files based on ACL, then yes hashing would help that a bit. It's exactly the "security by obscurity" I mentioned. One should really not rely on that form of security. Personally I think it should also not be the scope of the media manager to have this kind of ACL (basically it's view levels). And the current proposal doesn't have that.

That should be the realm of download extensions, where the files are stored outside the web root and served by the component dynamically. This is the only way you can protect files from access in a secure way.

For catching overwrites and applying create/edit/delete ACL, you don't need a hash at all. You can check that perfectly using the original filename with an accompagning database entry.

To unsubscribe from this group and all its topics, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

[Dan Walker]

Another reason not to add hashes to file names is that we have many clients who update various document or image files by uploading files of the exact same name. In this way, they do not have to change links in menus or various articles/modules. If each filename had a hash added to the filename, this would not be possible. I do not think that adding hashes to filenames is a good idea at all.

[Sergio Manzi]

+1000

[Buddhima Wijeweera]

Hi,

@Bakul:

What I think is filename-hash.jpg (hash shouldn't be too long) will give extra advantage too. It will allow users to upload files with same name to same location.

@Dan Walker & @Sergio Manzi:

I wonder how that can happen! Currently Media Manager doesn't allow uploading files with existing file-names.

Thank You!

On Sunday, June 29, 2014 10:45:47 PM UTC+5:30, Buddhima Wijeweera wrote:

[Dan Walker]

You delete the file and then immediately upload the replacement file. Didn't think I'd have to explain that. So, this is a valid point, confirmed by our clients and our own experience. filename-hash.jpg will be negative for SEO, as well as taking the naming of images out of the hands of the webmaster and making it arbitrary. I am not aware of any other major CMS that adds hashes to images. Finally, I see no benefit in being able to upload files with the same filename and different hashes to the same location. 

[Bakual]

There is actually a PR which would allow to overwrite files with com_media: https://github.com/joomla/joomla-cms/pull/3637

Imho, it would make more sense to warn the user and allow to overwrite the file than magically add a hash to it to prevent overwriting. It would be more intuitive as every OS works the same.

[Paulo Faustino]

Hi Guys,

 

 

I would just like to know, what is the downsize to allow the user / webmaster to choose if he wants to add a hash when uploading a file?.

For example the gallery extension from Rockettheme renames the files, I don’t see their users complaining. Adding the possibility to do it or not would be the extra step to make everyone happy.

 

If I am not mistaken the proposed  code already handles the addition of the hash tag, so it would just be a matter to activate that portion only if the users wants.

 

 

It just seems to me that you guys are using too much energy and time discussing something that you can fix with just a portion of the energy and time already spent discussing it.

 

 

Com os meus melhores cumprimentos,

Paulo Faustino

 

www.newjamp.pt

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

[Bakual]

An option would be possible, I was thinking about that as well. However I'm not a fan of adding (imho) useless options. We already have enough of those. :)

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send email to joomla-dev-cms@googlegroups.com.

[Beat]

H Buddhima (and all other participants in here),

That sounds like awesome work on the Media manger, and if everyone discusses about one detail, that means that all the rest is great !

2 more cents re hashign: While filename random hashing may be of benefit for storing a file in a hard-to-guess-manner in a non-protected directory, it can have its usefulness for non-public content (how many time did someone guess how a new product looks like by just editing the URL of the picture of the previous version of a product?). But then most new content on a website is first non-public until ready to be published.

For public published articles and categories it is very very important that images filenames do not get hashed.

For most sites not important, and for a few sites as important, is that for non-published articles/categories, image urls can't be guessed.

So here my proposal to solve this problem without additional setting:

1. When media is uploaded as an explicitly referenced image for a non-published or non-public article, hash
2. When media is uploaded as an explicitly referenced image for a publishde and public article, don't hash
3. When an article/category is made published and public, rename file and reference in article from hashed to non-hashed
   
4. When an article/category is made  not public or unpubished, rename file and reference in article to hashed if not hashed, or if hashed, re-hash randomly to a new random hash.
   

I know that this isn't as simple as it sounds, but imho it would be the wanted behavior for 99.999% of Joomla! users.

Best Regards,
Beat
http://www.joomlapolis.com/

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.

[Bakual]

Sounds a bit complicate to change file names based on publish state of the article. Also it ask for trouble as soon as you use the same file in multiple articles (like translations for example), you'd need to check if the file is used in another article as well.

Given that currently the files are referenced directly hardcoded this would be nearly impossible to be achieved. Even if you referenced them using a content plugin which replaces a file id with the actual file path, it would still be possible that article reference files directly.

Personally I disagree that this would be a wanted behavior of most users. I'd say most users don't even care about direct access to files. Nobody should put up sensitive information on a public available site, even if the URL is not easy to guess. You can be sure someone will detect it anyway. If you have a new product which should not be leaked prior to launch, you should create the article and everything in your internal enviroment and put it to public once it's ready to be published. Or serve the image directly from the database where you can have all the ACL you want.

[Troy]

please dont' add some obscure hash tag to uploaded files.. that would be a nightmare for me adding images to my content.. which image is the one I want???
do it the way jce does, which is allow me to rename / overwrite if its the same file name.

Bear

No virus found in this message.

Checked by AVG - www.avg.com

Version: 2014.0.4716 / Virus Database: 3986/7792 - Release Date: 07/03/14

[rolandd]

+100 on that Bear !!

[Youjoomla.com]

No hashing please. Keep it as it was. I upload an image name my_joomla_crew.jpg I expect that image name to be in images folder. 

If you have to hash it give admin and option to do it. Set default to No hashing. 

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--

Best Regards
Dan Casky
Youjoomla Customer Service
1670 Southgate Mill DR NW
Duluth ,GA
30096
-------------------------------
www.youjoomla.com
Professional Joomla Web Design Services

[Beat]

Hi Thomas (Bakual),

I agree with your good imlpementation analysis, and thus I also agree that it does not make sense to hash the filenames.

If someone wants it hashed, he can rename it before or after upload!

So my vote goes for removing completely the hashing.

Sometimes (actually often) removing a seldomly needed feature improves a product, its usability and its testability and maintainability!

Best Regards,
Beat
http://www.joomlapolis.com/

[Aerendir]

About the hashing, i agree with the ones who think it's unuseful: i've ever hated this kind of naming conventions: it's complicate to find an image navigating the folders and the names so built aren't descriptive and we loose an opportunity for seo improvement.

[Buddhima Wijeweera]

Hi All,

With latest commit, I cancelled hashing.

Also fixed issues reported about Drag&Drop uploader, coding-styles.

Also need to mention that I changed "JHelperMedia::canUpload" to a static method.

Thank You!

On Sunday, June 29, 2014 10:45:47 PM UTC+5:30, Buddhima Wijeweera wrote:

Hi Devs,

I'm so happy to inform you that, I was able to complete the Media Manager project. This project carried out during last 6 months by myself and now I'm unveiling it. With this project I have introduced 12 new things to Joomla! existing Media Manager. Those 12 things include; Drag & Drop uploader, New MVC for Media Manager, Image Editor, ...etc. which were requested by community from a long time.

Complete details about this project can be found in the following document:

https://docs.google.com/document/d/1mZMwBU_hW7AshL5rkAdIyswQmzBmP1L8L1PdM093rB0/edit?usp=sharing

Pull Request for the implementation:

https://github.com/joomla/joomla-cms/pull/3839

Please follow the test instructions before testing:

=== Testing instructions ===

It is highly recommended to go through following instructions before testing.

1. The recommended way to test this project is to get a clone of project branch separately. And then add the above (point 12 in doc) mentioned content-types into content-type table in joomla database. since this implementation will add new entries to database, this method will not affect your ongoing development.

2. Still, you can also use PR tester or any other preferred method, and you need to add above (point 12 in doc) mentioned content-types into content-type table in joomla database. If you do not worry about adding new entries into your database, you can go ahead with this method.

As the conclusion, I'm expecting your constructive feedback on this implementation to make this success.

Thank You!

On Sunday, June 29, 2014 10:45:47 PM UTC+5:30, Buddhima Wijeweera wrote:

[Thomas J]

I did a fresh install of XAMPP on my Windows 7 computer, together with a fresh install of Joomla 3.3.2.

Per the testing instructions, I modified the content-type table in the joomla database to add the two additional content types.

I then tested the functionality of the new Media Manager. I went through the testing document and tested the various categories.

All of it worked well. This is a substantially better user experience than the existing one. I have two comments (neither of which are critical):

1. In the detailed view, would it be possible to also have a column showing the category of each picture?

2. In looking at the UI, when you are looking at the Media area, the Media Folders listing shows the various subfolders. However, when you click on one of the subfolders, there is no where to click on the left column to get back to the root media folder other than clicking on the word "Media" on top. Would it be possible to add the root media folder to the list of folders in the left column?

In general, this is outstanding work.

[Buddhima Wijeweera]

Hi All,

It has been a long period of silence on this project. But I have done several changes throughout last few weeks. So I'm going to summarize them here.

1. Modify image editor toolbar with new icons

2. Resized modals to fit small-screen sizes

3. Totally refactored  using tags in this com_media, so that now images can be seen when click on tags-list-items at the FE

4. Update sql files to insert entries need for content-type table

5. Fixing FTP uploads

At last I would like to thank everyone who tested and presented suggestions here. 

Thank you!

[yannick berges]

hello just for infos => this big feature is realy planned for 3.9 ?
any news about it ?
Thanks your fantastic work

[Allrude]

Hi Buddhima, thanks for all your hard work on this, 

since we wont get this in joomla before ... nows wen, is it perhaps an idea to, build this as a component/plugin so people can choose to to install it as a replacement for the current MM (you know the "mambo version" ;-)  )

it will then also be tested more so you/we can improve on it

greetings

[Roland Dalmulder]

Hello all,

 

Since the media manager is based on the currently non-existing new MVC in the core it can’t be merged, same as the use of the UCM tables instead of it’s own media tables. I would love to see this go into the core. Either this PR needs to be rewritten to use the existing core and it’s own media tables.

 

That is the only way I see this being merged into the core at this point.

 

What are your plans for this PR Buddhima? As you know I tested it a lot and like it as well J

 

From: joomla-...@googlegroups.com [mailto:joomla-...@googlegroups.com] On Behalf Of Allrude
Sent: woensdag 3 december 2014 00:22
To: joomla-...@googlegroups.com
Subject: [jcms] Re: New Media Manager for Joomla! CMS

 

Hi Buddhima, thanks for all your hard work on this, 

--

[George Wilson]

Hi

 

Since the media manager is based on the currently non-existing new MVC in the core it can’t be merged, same as the use of the UCM tables instead of it’s own media tables. I would love to see this go into the core. Either this PR needs to be rewritten to use the existing core and it’s own media tables.

I think there are two separate issues here. The use of new MVC is something that is only an issue whilst we don't have a "new" MVC implementation in core. There is nothing wrong with using it in itself. And I hope by 3.5 when this comes in we will have a much more firm idea about what the new MVC implementation is that we will use - whether my own from GSOC or Buddhima's similar one that is already been used in com_config with a reasonable amount of success.

The UCM tables for me is a non-issue. I feel that UCM is actually in a much better position than it was a year ago. I don't see any reason why we can't integrate that with the media manager. The more core components we have using the UCM tables the better for getting it stable in my opinion. We have tags and content history successfully using it and I don't see why we can't trial expanding it with the media manager.

Kind Regards,

George 

[Bakual]

The media manager extends classes from com_config. Which is just not acceptable. It should either extend from the library ones or wait for hte ones from George.

As for UCM: com_tags still has more issues than I like. The duplicated data we have all over the place due to this implementation also isn't what I love to see spread more.

For the media manager I mainly think we will limit ourself in future if we use the UCM tables to store the media informations. It sounds tempting now because content types sound similar to media types. But what if you want for example search for images of a specific size? The data will be all in a JSON string which you can't really search for.

Also tags and history both have own tables as well. They only use the UCM tables to store the data from the various extensions. That's a very different use case from what the media manager will need.

[George Wilson]

The media manager extends classes from com_config. Which is just not acceptable. It should either extend from the library ones or wait for hte ones from George.

I agree but it's just about making a decision about what set of classes we are going to take forward. Both have their own strengths and weaknesses..... It's such a touchy subject no one wants to bring it up and so nothing gets done. We need to have a constructive community discussion about this after 3.4 gets out the door

 

As for UCM: com_tags still has more issues than I like. The duplicated data we have all over the place due to this implementation also isn't what I love to see spread more.

The duplicated information isn't really a fault of UCM - just the way com_tags did it. I mean we should write an SQL script tomorrow that moves all the com_content stuff over tomorrow to use the main #__ucm_content table instead of #__content table. But the reality is it would kill plugins and extensions that rely on those things existing. I don't think UCM is flawed in that sense. It's just been introduced a bit before it's time. I think it's important we get the concept into our heads that 

 

For the media manager I mainly think we will limit ourself in future if we use the UCM tables to store the media informations. It sounds tempting now because content types sound similar to media types. But what if you want for example search for images of a specific size? The data will be all in a JSON string which you can't really search for.

 You can still extend out any row in the #__ucm_content table into a custom one - just like the way we do at the moment with tags etc. except in this case we don't need the duplicated data. You can just have an id, a fk to the #__ucm_content table and then the extra columns you want to add. Easy peasy, next to no duplicated data - but the full UCM power

Kind Regards,

George

[Johan Janssens]

+1 

The UCM is all what you can call SOLID. We still have the opportunity to deprecated it. Lets not consider this lightly. If (and I hope not) we decide to further extend upon it the implementation needs a serious cleanup. If not we will be dealing with the technical debt for years to come. 

-- Pretty please.

[Bakual]

 I don't think UCM is flawed in that sense. It's just been introduced a bit before it's time. I think it's important we get the concept into our heads that

It was rushed in during beta of 3.2 (I think). And it looks exactly like that.

If we really need UCM in Joomla, then it has to be architected from ground up fresh with proper discussions beforehand. Sneaking it in as part of com_tags a week or two before release without proper testing is the wrong way. And gives exactly the outcome we have now.

Personally, I'm not that convinced yet that we need UCM. We don't have to adopt everything WP and Drupal do if there is not really a reason to it. Sure, it has some nice things you can do with it, but you always pay a cost for it. One of it is the performance impact you get with more complicated queries. Another is the complexity of our database struture and code needed. Did you ever try to explain how our UCM works? How all those tables relate to eachother? It's crazy :)

[Michael Babker]

In it's current form, it definitely isn't an optimal structure.  I wouldn't use the current structure as an argument though to never have some form of UCM in Joomla.

--

[Johan Janssens]

Michael, Thomas, George,

The concept of content modelling based on a database schema (as implemented in the UCM) is an old (in web terms prehistoric) concept found in many of the legacy enterprise CMS systems build more then a decade ago, systems like Vignette, Documentum etc. 

Content modelling based on a data schema stems from a time when database queries where expensive and limiting the amount of queries to generate a html page was key. This was a time of monolithic systems build around relational database schema's. A time where 'joins' ruled and (object relational mapping) ORM was the star of the show and json nor ajax hadn't been invented yet.

Times have changed. Databases, PHP, ... and the web have become faster. Caching mechanisms have improved. Monolithic systems have been replaced by individual (micro) services. Today, 'urls' rule and linked data (LD) is the star of the show. 

In the world of today a database schema oriented content modelling approach no longer makes sense. Content modelling today is done on a HTTP level using REST and linked data resource schema's like JSON-LD

Don't get me wrong content modelling is a very important aspect of the web. Just not any more a database level, solutions like NoSQL show databases are being dumbed down to mere data storage systems. Relations between resources are handled on a higher level.

Lets not make the mistake in believing that the UCM is ahead of it's time. It's not. It's an outdated approach for content modelling. 

Joomla is the one which is ahead of it's time, we never relied on a database schema centric content modelling approach. Instead Joomla components are loosely coupled and highly cohesive applications that related to each other on an object level through a well architected API. 

The next step is to further decouple the database schema and expose object relations not only through the API but also through linked data that can be generated out of the box. 

Specifically to the discussion about a new media manager what interests me and what I'm missing from the discussion here and the one on Github is how the new media manager exposes an API that can easily be leveraged by developers and how it exposes linked data that can easily be consumed. The only discussion and documentation I see is one about end user features. 

Johan

[brian teeman]

Can you guys start a new thread about the UCM data model etc. 

That will let other people who are not following the media manager topic be informed and involved.

Thanks

[Johan Janssens]

Hi Brian, my apologies. This should go into a different thread indeed. I'm just a bit frustrated to see that each time any new feature discussion comes up the UCM is bikeshedded into the convo. 

To bring things back on track. Can someone please point me to developer documentation about the new media manager ? I cannot find anything ? Does this exists or has work only been focussed on features ? I would like to evaluate the code being proposed from the developer perspective and see if this is re-usable in other components or not. 

Thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/nYM85PxNTi8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Michael Babker]

Buddhima wrote up this document (https://docs.google.com/document/d/1mZMwBU_hW7AshL5rkAdIyswQmzBmP1L8L1PdM093rB0/edit?usp=sharing) to go with the pull request (https://github.com/joomla/joomla-cms/pull/3839).  I think that's everything I'm aware of though.

--

You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.

[Buddhima Wijeweera]

Hi All,

Thank you Michael for providing information to Johan and willing to hear your experience.

Also appreciate George's effort on explaining things clearly. I really missed this since I was out-of-focus on this.

I got several suggestions on this implementation and I tried to work on as much as possible. But its sad to say that some were not feasible.

But within last 2 months I have made several changes to the PR, specially make Drag & Drop uploader to work fine.

Thank You!

[Buddhima Wijeweera]

Hi All,

This project has been evolved for about a year and came across various changes and improvement. So today, I would like to announce a significant change done recently. It’s about copy and move media among folders. With this improvement user will be able to;

• Copy and move one or more images across folders
  
• Not just images, but images with folders also can be moved and copied
  

I believe this feature will uplift user experience with media manager. And would like to know your thoughts on that.

Thank You!

[Goyat LLC-吉田憲人]

Very Good! I would like to see it happen in ver.3.5.

Goyat

On 2015/01/04 22:57, Buddhima Wijeweera wrote:
> Hi All,
>
> This project has been evolved for about a year and came across various
> changes and improvement. So today, I would like to announce a

> significant change done recently. It’s about *_copy and move media_*

> among folders. With this improvement user will be able to;
>

> * Copy and move one or more images across folders
> * Not just images, but images with folders also can be moved and copied

>
> I believe this feature will uplift user experience with media manager.
> And would like to know your thoughts on that.
>
> Thank You!
>

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cm...@googlegroups.com>.

> To post to this group, send email to joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/d/optout.

--

---
Goyat LLC, Yokohama, Japan
Norito H.Yoshida 吉田憲人
http://www.joomlajp.org/
http://goyat.jp/

"Happiness is a perfume you can not pour on others
without getting a few drops on yourself."

幸福は香水のごときものである
人に振りかけると
自分に必ずかかる

[yannick berges]

great !!!

2015-01-04 15:05 GMT+01:00 Goyat LLC-吉田憲人 <nor...@gmail.com>:

Very Good! I would like to see it happen in ver.3.5.

Goyat

On 2015/01/04 22:57, Buddhima Wijeweera wrote:

Hi All,

This project has been evolved for about a year and came across various
changes and improvement. So today, I would like to announce a
significant change done recently. It’s about *_copy and move media_*
among folders. With this improvement user will be able to;

  * Copy and move one or more images across folders
  * Not just images, but images with folders also can be moved and copied

I believe this feature will uplift user experience with media manager.
And would like to know your thoughts on that.

Thank You!

--
You received this message because you are subscribed to the Google
Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send

an email to joomla-dev-cms+unsubscribe@googlegroups.com
<mailto:joomla-dev-cms+unsub...@googlegroups.com>.
To post to this group, send email to joomla-dev-cms@googlegroups.com
<mailto:joomla-dev-cms@googlegroups.com>.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--

---
Goyat LLC, Yokohama, Japan
Norito H.Yoshida 吉田憲人
http://www.joomlajp.org/
http://goyat.jp/

"Happiness is a perfume you can not pour on others
without getting a few drops on yourself."

幸福は香水のごときものである
人に振りかけると
自分に必ずかかる

--

You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/nYM85PxNTi8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

[Buddhima Wijeweera]

Hi All,

This project has been out-of-sync with master branch for about 2 months, and now that's fine.

Meanwhile I added new changes, which have not mentioned in this mail-thread.

1. Adding Flip action in Image Editor

2. Rotate direction selector

3. Changes in Image Editor will not change original image until you click Save or Save & Close.

With those, I tried to fulfill few requested features in this implementation.

I have seen recently, that J!3.5 discussions mentioning about this implementation. So, I'm happy to say that this is currently synced with current master.

And appreciate people who have tested this so far.

Thank you!