As most of you probably already know we already started to think about media in Drupal 8. Next major release of Drupal is getting closer and closer, but we still have enough time to improve media handling and fix problems that we face ATM before Drupal 8 ships.
A bit of background....
Back at DrupalCon Prague we had a core convo, where we discussed same questions. Very productive planning sprint happened two days after, where we created a more or less concrete battle plan. In order to learn more about that part check [1], [2], [3], [4].
Media entity project was born as a result of things that happened in Prague. Media entity is first piece in whole media ecosystem mosaic in Drupal 8. It has been born based on inspiration that comes from existing media solutions in Drupal 7. Some work has already been done on it. project page and [5] if you want to learn more.
Architecture design
When disusing architecture we try to take the best out of each current solution. While I believe we have lots of consensus about current decisions it still looks that there are some people that are not happy with some individual aspects about it.
Purpose of this discussion is to evaluate basic architectural decisions once again and achieve enough consensus to prevent formation of incompatible media solutions that would compete for entire Drupal 8 cycle and waste our resources this way (which is basically happening in Drupal 7).
1. Ecosystem needs to consist out of decoupled components with very limited scope
Media is a huge problem space. There is absolutely no way to handle most of use cases with one generic solution. Solution to that is an ecosystem, that consists out of many decoupled components. This components should be built in a way that allows us to mix them in many different ways. This would effectively allow us to have multiple
media solutions, that are built on the common foundation. If we do this right it will be possible to add or remove this components as site grows and/or it's requirements change. This way we also prevent over-complicating configuration and UI for simple sites, but still allow them to become more complex in the future.
We would have few media solutions, which would actually be "visible" to an inexperienced users/site builders. This solutions would be nothing else than a glue that brings all components together with some sane default configuration. Image below shows this idea in a more graphical way:
This idea is heavily based on the approach that Drupal Commerce takes (lots of individual components), while we add the principle of "feature modules", which currently do not exists in Drupal Commerce ecosystem AFAIK.
More smaller components are also much easier to maintain than one (or two) big solutions, as it is easier to involve more people and spread load this way (yes... it is called load balancer :)). Pace of development was definitely one of bigger problem with solutions in Drupal 7 and this will hopefully help us to fix that in 8.
Media entity is first of this components that is responsible for storage part.
2. Basic components of the described ecosystem need to be available soon in Drupal 8 release cycle
People will need media solution when they start building sites on Drupal 8, which means we have to provide them. This is very important when it comes to basic components, which take care about basic things (storage, library, media selection and usage, basic display configuration, WYSIWYG integration, ...).
Is it OK if we wait with more complex components a bit longer. It should be perfectly possible to build them as separate projects once somebody needs them. Another big benefit of a "decoupled" approach ...
3. Use existing tools as much as we can
Use things that come with Drupal. Entity API, Field API, Entity reference, Views, plugin system, configuration entities, ... are great. We should use those as much as we can, which will hopefully save us a lot of resources. If there is a part of this system that could be built with both existing tools or custom solution we definitely should go the "standard" route.
4. Storage should be based on a structure that does not assume all media are files
Media entity (which is meant to play this role) is slightly different to File entity (which we know form Drupal 7 world), as local files represent only one of it's subsets. Media can, in theory, relate to just any form of media (local files, remotely hosted videos, galleries, tweets, ...). Even other articles could be used as media (this is not very common use
case, but we should not assume that nobody will need something as funky as this). With other words: media entity can definitely work with local files without assuming this will be the only type of media ever used on the site. I see it as an evolution (or extension) of File entity, as it provides more power and flexibility while not introducing any additional
complexity for the user (if done right). Users who only deal with local files should not be aware of other options until they need them. I believe it can be done in a way that will make this possible.
This part is definitely the most problematic in terms of agreement. Some people think that this is not the way to go and advocate approach that File entity takes. File entity basically treats everything as a local file. It then works with custom stream wrappers to bring remote media to a Drupal site.
NOTE: I personally believe that media entity is the way to go. I was actually on the "File entity" side until recently. I was convinced the other way after discussing this with various people from very different backgrounds (and companies if you want). I agree that it is possible to treat almost everything via stream wrappers and there are cases where it makes sense even for remote media. But there are cases where it simply doesn't make sense to do that. There are also some use-cases where it is not even possible. The only real argument against media entity approach that I see ATM is potential additional complexity, but I strongly believe that it can be done in a way that would make it at least as simple for users as File entity is now.
Let's have another round of discussion, which will hopefully result in a unified approach that will be supported by all sides. I'd like to encourage everyone to help us make this discussion constructive, somewhat pragmatic and without unnecessary emotions involved.
References
[1] - DrupalCon Prague core convo - http://www.youtube.com/watch?v=4giCe2GNnLQ
[2] - DrupalCon Prague gdoc - https://docs.google.com/document/d/1PGj2rjkY_a1FJnhqvwoA-d_BGCjPgl1uwow7...
[3] - DrupalCon Prague report - https://groups.drupal.org/node/327768 and http://janezurevc.name/drupal-bootstrap-drupal-gr8-media
[4] - Survey about media in Drupal - http://janezurevc.name/lets-fix-file-and-media-handling-once-and-all-pt-1 and http://janezurevc.name/why-do-we-complain-about-drupal-media-solutions-a...
[5] - DC Vienna Drupal 8 media sprint report - http://janezurevc.name/drupal-8-media-sprint-dc-vienna-0
| Attachment | Size |
|---|---|
| media_components.png | 61.53 KB |
Comments
What happens to file entities?
I've been trying to follow this debate, but I'm still having some trouble understanding the difference between the approaches, other than semantics.
In the Media Entity approach, are there still file entities as we now know them? Are they fieldable? Do we still have stream wrappers?
This is only my
This is only my understanding, but yes, there is still file entities which are still fieldable. And yes, there is still stream wrapper.
A file entity holds information about a file, a media entity holds information about a media. A media could be represented by a file, but there is not necessarily a one-to-one relation.
Correct. There can be media
Correct. There can be media entities that use a file entity (in case of local files) and the ones that don't (remote media, etc.)
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
I'd like to see the Media,
I'd like to see the Media, Scald and Asset maintainers chime in here so that they 1/ give their take about the above approach 2/ argue with any other approach they'd believe is better and give pros/cons for the community to form an opinion 3/ express their will to unify all modules into a standard D8 solution.
Then, when people have agreed on a battle plan, there'll be a path to move forward. Without all of this, I don't see a very bright future for a unified solution.
There was MediaBox
There was MediaBox maintainer. There were also a few people from Scald team on that sprint, and the plan above is what we have agreed on.
Some people think that this
I think it's still unclear (at least for me) who disagrees with the above approach and why.
Is there more to it than File entity?
Thank you for this post Janez
You're taking much of your spare time to make things move forward and I really appreciate it.
I was (modestly) part of the core convo and sprint in DCPrague and it is clear that the architecture of Media Entity came up from these discussions, not only from maintainers/users of one existing solution, but also from end users and project managers dealing with medium to big media projects. All these people wanted Media to rock in Drupal 8 !
I am myself a project manager (a bit of a coder too, you can't leave an addiction so easily :) ), and was very happy to have had discussions there with people having significant experience with media/asset management on drupal. And to make things clear, it was not "scald guys" taking over a discussion to push forward their own solution as people tend to think. It is not also a "Europe vs US" debate, the debate was also opened in Portland.
As @jcisio already said, there were contributors from : Media (Janez), MediaBox and Scald. There also were users from these 3 modules. The above architecture is a result of 2 days of constructive discussion.
@anavarre AFAIK, the pros ans cons of File Entity vs Media Entity approaches are, from my humble point of view :
File Entity
Pros
Cons
Media Entity
Pros
** a tweet
** a third party video (like youtube or like a private cloud solution with a professionnal service provider like BrightCove)
** a soundcloud playlist
** a multimedia gallery
** an article coming from the internal information system of a big newspaper
** name it...
Cons
These are just my 2 (euro-)cents, I am not a maintainer...
The file table structure in
Can you please clarify?
Limiting how? I don't even know what the limitation is causing this to be a con.
Should not be a con because this is the same as D7 and D8 will make this easier to change due to the swap-ability of a lot of the architecture provided by core.
Again I think all these could or can already be handled by oEmbed.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
One of the last big con I've
One of the last big con I've forgotten to list is that if you make the assumption that every media is a file, you implicitly make the assumption that every file is a media. And that is very annoying in some situations, because with that design, every uploaded file in drupal ends up in the media library. And in many use cases, you don't want your media library (which has extended features like CRUD, ownership, workflow, copyrights) be polluted by one-shot pdf files used by users to detail the program of a contributed event for example. File Fields on nodes should not create medias, it's unrelated.
Below are my answers to your questions :
From my small point of view, if you take a look at the file_managed table in D7, I don't know how to store non file media information in that without having to tweak the initial usage of the fields.
Let us talk about sounds for example. An user want to use a sound media, without having to make a distinction between an mp3 file, a .wav file, or a sound hosted on soundloud. In the mimetype approach, these 3 cases have 3 different mimetypes, whereas IMHO, they should be in the "sound" bundle
I think that relying on a third party API, that is, in many cases I've seen, not very well implemented by the provider, is something to build a robust solution on.
And that is very annoying in
This workflow seems to work pretty well for Wordpress so I don't think it's a wrong solution. The use case you describe of a one-shot PDF file means it should be a file field and nothing else. But why couldn't they re-use that same PDF in a media field if they wanted to? Many of the extended features are optional or can be skipped as well. I think you are overestimating the complexity required here.
This is why we added the file_metadata table in the File entity module so we can store stuff like image/video height and width, track length, ID3 tags, etc.
This is exactly how File entity works. It has an 'Audio' bundle that anything that has a mimetype of audio/* (mp3 = audio/mpeg, wav = audio/wav, soundcloud with oembed = audio/oembed) get assigned the same bundle. Users can create new bundles if they need to have more separation.
A unified API let's us treat all the external stuff the same way though, and I've found that it works for most end users.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
With the File Entity as media
With the File Entity as media approach, a media is always a single file and a file is always a single media. While this likely cover
~80% of the uses cases, this is a limitation. But you cannot have a media which is several files. For instance, it would likely be better to be able to define a video file and its subtitles files as a single media. The media is neither the video file, neither the subtitles files. And the video media is more than just the collection of these files.
But yes, the Media Entity adds an additional layers and thus, IMHO, more complexity which is unecessary for ~80% of the uses cases. I think that the idea is that this complexity could be hidden to the end user with a proper UX (which I doubt).
That said, File Entity and Media in D7 provivdes the proper tools to work with file meta-data and file bundles. IMHO, for the uses cases where a media is a file and a file is a media, the Media Entity approach does not provide any additional value.
And that is very annoying in
The converse of this is the following: I had a Drupal site I've managed for a year or so but I just discovered Media. I installed it but none of my files or images that I've uploaded over the past year are visible in my Media library.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
It wouldn't be a problem to
It wouldn't be a problem to address that using a little migration script since migrate will be in core for D8. It's better than having the opposite: I'm adding a media management solution and suddenly all these irrelevant files from other parts of the website are showing up in my library and I have no way of removing them from the library without removing the file completely.
The process for UI and storage works in opposite directions, because extending storage is much more difficult. For the UI, you want to provide a basic interface that can be extended to meet complex requirements. For the storage, you want to provide a powerful structure that meets all requirements, the basic case just not taking advantage of all possibilities.
I'm adding a media management
You could always update the default view to handle your custom requirements.
I had a Drupal site I've
It is a quite limited and not flexible solution. With Media Entity approach, we can easily convert a subset of files (in a certain fields, attached on a certain entity types) into Media Entities. I wrote 30 lines of code to migrate (possibily selectively) existing files into Media Entities (Scald atoms, precisely) using the Migrate module.
So I don't think migration is a big problem.
Functionality, dependencies and location
Thanks @slashrsm and everyone else who has worked or commented on all of the proposals, diagrams and plans for media handling in Drupal 8!
My vision of media in Drupal 8 is very similar to the architecture diagram outlined in the original post and may only differ in potential dependencies or location:
Modules/Components
Dependencies
I don't think that there are really that many issues preventing the combination of efforts towards a unified media solution for Drupal 8. My only thoughts/concerns include:
Thoughts/Concerns
If Media entity items are truly just collections of media then I'd say that our plan for Drupal 8 is to:
Tasks
Finally, I think that abstracting the entity collection and entity embed functionality will attract a much wider base of users and contributors. I can see site users creating entity collection bundles for image galleries, video galleries, featured products, favourite tweets, etc and embedding them in their content.
I also believe that not placing any strict limits on "media" entities will allow developers to create their own solutions to handling media as they require, for example: writing a stream wrapper to handle reading/saving tweets as text files in file entities, using oEmbed to store all remote media (including tweets) in oEmbed entities, writing a specific tweet entity that uses its own database tables to handle all of the specific functionality available through authenticated Twitter APIs.
I think Media Entities are
I think Media Entities are more than entities references collection. A media entity is a collection of qualified media ressource references and the (meta-)data about the media. The title or the cast of a video are (meta-)data of the video, the mime-type is a meta-data of the File entity used as media ressource.
Eventually, we may come to the conclusion that all media ressource are better implemented as entities. But I guess this would have to be experienced in the wild at first. Then this could be changed in a future release of Media Entity (perhaps for Drupal 9).
I like the idea of components depending on abstracted/generic concepts. I think it would be possible to develop most of the components needed/wanted here to work on abstracted interface. Each component could define its own interface for what they need a 'Media' to be. Plugins can be then provided to adapt concrete implementation of 'Media'. For instance, a oEmbed endpoint plugin could rely its own "embedable media" interface. This interface could then be implemented for File Entitiy, Media Entity or any else (eg. oEmbed Views without requiring a Views to be a media) through an adapter plugin. This generic endpoint could then be used by a oEmbed WYSIWYG plugin which would only depends on the generic interface of the endpoin, and would not be tied to any specific media implementation. If done from the start, this can of approach does not make developpement harder but provide propre decoupling of the components and increase their re-usability (hence the chance that more people use them and collaborate on them).
I think there are a few
I think there are a few points that need to be detailed:
The difference between Media Entity (and File Entity, as a maintainer you surely know) and a "regular" entity is that the entity itself (fields not included) can be rendered in different ways, through different "players", and those rendered entities (without fields configured via Field UI) can incorporate fields. That's why integration with Media Entity is special.
Thoughts from a Media/File entity maintainer
So as someone who's worked on Media and File entity for quite a while, I make no attempt to hide that I think basing a media solution on files is still what I consider the "right" approach.
I do wish that the original maintainers of the Media module (aaronwinborn, Jacob Singh, effulgentsia) could comment on this issue because the irony is that the Media module when first started to be ported to D7 actually used the concept of a media entity in-between files and content. It was then changed to just extend the file entities in core and moved forward from there. I don't have a ton of information why that change was made, but I find it very ironic that this is actually what Media used to be.
I think a lot of the more advanced things that are identified as wanting to be in the media library are things like galleries, tweets, remote video, etc. For these things I still think that the oEmbed standard is the ideal solution for all of the above. We already have pretty good oEmbed integration with Media and treating them as 'files' which works well. It would be good to get input from the oEmbed maintainers as well on a unified solution.
I fully admit that Media (and File entity) have taken a long time, haven't really ever been "finished," etc. I think that problem is more related to time and financial support rather than "this is the wrong solution". Granted, there are lot of things about the Media module that I just want to burn to the ground. With D8 I'd want a fresh start with only using CKEditor for WYSIWYG integration, better embedding support, better library and UI/UX with Views and modal support in core, etc. But I still do believe that basing the entire solution on files solves the wide majority of use cases that our actual end users have. And we've done a crap tone of work to make the Media/File entity stack extendable for the more advanced use cases. I've written quite complex media asset system integrations and never had any major problems with the technology underneath. Had I encountered major problems in anything I've done over the last three or four years, I would be on the side of wanting a different architecture approach.
I do definitely recognize that there is an unsolved problem by using File entities and it's an issue of inline data: "I want to use this file in this field but provide a special caption only in this one place and not anywhere else this file is used." However I don't think this problem is unique to Media. A generalized solution like Field Collection, Multifield, or something new in D8 that could take any entity reference field and add 'field value data' to it would be ideal. I'd like to take a node reference field and be able to override the node title when used in a slideshow so I could use something shorter that one specific place.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
Should have had a summary
What I think this comes down to for me is the assumption that "Storage should be based on a structure that does not assume all media are files" is something I strongly disagree with. In my experience files + oEmbed files handles the large, if not entire percentage of uses cases that end users have.
The most problematic things I think we have in the Media/File entity module are the following:
I think these are solvable with enough help, and could fit the 80% use case need.
My biggest concern about the proposal above are that while it has a good vision, it does not appear to give more effort to solve the actual problems our end users have, which are mostly UI/UX and WYSIWYG related. I would be more interested to hear what the WYSIWYG solution for the proposal would involve because once you no longer have a field for your data, things start to go out the window.
EDIT: Added private files to list of nagging Media/File entity issues
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
I think these are solvable
IMHO, the problem is that the remaining 20% are the big medias/companies that make a heavy use of drupal, and want to have a media solution in D8 that fits their needs. Because they already love the CMS, but not the media management part unfortunately. And these drupal users did find time and a bit of money in D7 to develop alternative solutions because the cons of the File Entity approach were too limitative for their needs. Otherwise why wouldn't have they chosen a media management solution installed on tens of thousands D7 ?
I've never found it
I've never found it successful for the remaining 20% very advanced use cases to ever be able to use something "out of the box". So we should continue to write for the 80% use case and have something flexible that allows the 20% use case to be possible with custom code.
I need to see data and research behind what needs actually need to be met in this case.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
And these drupal users did
I also highly doubt that we're ever going to hear from the big media companies that have worked successfully with File entity because they have a working solution and don't need to get involved. That's part of the problem. This entire approach, we're only going to hear from people that had problems with the File entity approach and it's a very one-sided conversation.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
It's true that people who had
It's true that people who had problems are much more vocal than those who don't. At the same time, a quick survey among people who have worked on large media projects shows that most of them have had issues with the current structure or have at least found it to be a limitation that led to suboptimal solutions (like adding a flickr field to a file entity in order to have remote images).
One of the argument against file entities is remote media. Everybody talks about youtube videos, flickr images and such, but I think the much more common case are the asset management systems used by many publications from which the websites pull content. I'm not talking about migrations or content synchronisation, but of accessing an asset library that you wouldn't want import completely. While these do need custom development in almost all cases, it would be nice if that work consisted of using an existing API and data structure (like media entities) rather than having to build a completely custom solution.
Maybe the clients for large scale media projects (typically magazines, newspapers, etc), represent a minority of the cases, but they are the one who have the means to fund development. That's why Scald is still successful despite having an install base that's an order of magnitude lower than the Media module's. By using a base structure that addresses the pain points these large clients are having, we are making sure that the funding they have can be used in a way that everybody profits from it. This could be the solution to the lack of funding that's plagued the Media module up to now.
Media:Flickr
I just wanted to point out that there's a Media:Flickr module that provides (or does in theory) a mechanism to load images straight off Flickr, so adding a field to add remote images to a file entity is completely daft.
Thanks for pointing out
Thanks for pointing out Media:Flickr. I wouldn't want anyone to think that a flickr field on a file entity is the right way to do that kind of thing.
However, storing a reference to a flickr gallery as the filename of a "file" entity in the database is semantically identical (it's an entity property rather than an entity field, but the distinction is just a Drupal implementation detail), and that's what Media:Flickr is doing.
Better separation
While the biggest point of discussion has been the storage structure (file entities vs media entities), I think you are right that most of the pain points for the end users are related to front-end topics such as UI/UX and WYSIWYG. The problem though, is that these tend to be use-case-specific (this was one of the first realizations from the Prague workshop).
From there we went on to try to figure out the common base that would allow different solutions, from simple media management to full-blown media libraries for complex organisations, and we drew the line at the storage. In order to be able to have a pluggable user interface (so that we can meet very different use cases), we need the storage structure to cover all cases. By treating local files as the special case of remote entities, we have both an increased flexibility and consistency.
I understand how having media entities feels like a step backwards when a step away from that structure has been done in the past. However, back then the entity system was from far not as mature as it has now become. Today, we would be able to have media entities that don't do much by themselves, but take advantage of other standard solutions like entity reference widgets or inline entity widgets. The basic solution should cover the 80% (or even 50%) for that matter, but it should be possible to cover the rest by extending it rather than using a completely different system like what is currently done with Scald.
Keeping file entities as the main data structure around which Media is built doesn't seem to be a good solution. Except for wanting to keep structure simple for a simple use case (for which a simple file field would be better), all participants in the workshop had agreed that a separate media entity makes more sense. Having been involved in a good amount of media-heavy projects myself I am convinced that not all media are files and that not all files are media. Having files as the primary entity also restricts us to whatever Drupal core is defining, and as you mentioned the needs don't quite match.
The current maintainers have put a huge amount of effort in the Media module, but the monolithic structure puts a very heavy load on a few shoulders. The media entity would be much leaner, just a little bit of code to define the entity, and a set of conventions on how to extend it using standard Drupal tools like the Entity and Field API. This would make it a lot easier to solve the various UX/UI challenges, without having to learn/fight yet another API.
This structure only provides tools though, and it's not a ready-made solution for any use case. We would provide an example that defines a simple media entity bundle using the core image field, and it definitely would make sense to have further "feature-like" modules that put together a standard configuration for more advanced situations.
In conclusion I believe we all have the same goals: we want to be able to improve the user experience because that's what really matters (and what's currently lacking). The change in storage structure is made so that we can also include contributions from other media management projects (Scald, MediaBox, etc) which are in some aspects much more advanced in terms of usability.
The current maintainers have
I'm unclear on how File Entity is not exactly what you describe as the "lean" entity. It provides an API that core is lacking, is completely clear on how to extend it using the standard Drupal APIs.
To be fair, the UI for administrating File Entity proves challenging, particularly for integration with Media. However these are challenges with the core of Drupal not with File Entity. A "lean" entity would have exactly the same problems that File Entity does.
Since Media is a layer on top of File Entity it should be possible to allow Media to integrate with non file entities. While I personally don't see much use of this, it's clear from this thread that its desirable for some.
At the end of it, Drupal's core file entities need what File Entity provides. If there needs to be something beyond it for some use cases that seems like reasonable work to abstract the UX of Media to handle other entities.
http://24b6.net
I'm unclear on how File
The File Entity is definitely providing certain things that Drupal core is lacking, and that is a good thing. However, the File Entity is not "lean" because it has a lot of baggage coming from Drupal core's File handling system. Using an extension of this as the main data structure to manage any kind of media will of course be a limiting factor, because there are things that should work with any file (copying for example) that will not work with any media. We can extend Drupal's file entities, but if we do so we also have to abide by its rules, so all defined operations should continue to work.
Working with remote data is not the typical use case, but it is a use case which is common enough and it is one that shows why the File Entity model is not a good fit as a common storage structure for arbitrary media types. This distinction between File Entities and Media Entities can be compared to the differentiation done in core between Interface Language and Content Language (introduced in D7): in the majority of cases they are the same thing, but by assuming they are the same thing we are forcing developers to hack around the API to build solutions to perfectly valid use cases.
Using an extension of this as
I'm unclear on why this is the case.
I'm unclear on why there is any issue with copying files. There is a unique URI requirement in the file database table but that does not limit copying.
I've worked extensively with remote resources on large public media sites and do not have any of the issues you describe. Some of the work that was done with Marketplace contributed to remote file handing in the File Entity project. This work was completed more than two years ago by Dave Reid.
I'm unclear on what actual use case there is that requires hacking that is the fault of File Entity and would not be applicable to some other type of entity.
As an aside, can't you just use ECK to build the type of entity that you want? What wouldn't work with that solution.
While I'm hearing that people don't want the File Entity solution I'm still not clear on what File Entity does not provide and what a different entity would.
It seems like there is quite a bit of focus on what File Entity "can't do" while not much understanding of what it actually does. The insistence that file entities can't reference external resources is just misinformation. For what it's worth, when aaron, drewish, zroger, dopry, myself, and a host of others first started work on Media we saw that stream wrappers were the critical element for accessing external resources as files. We pushed for URI's to be central to the way that we thought about files. This has aways been a central understanding of the work on these modules.
http://24b6.net
I'm not sure where best to
I'm not sure where best to weigh in here, but I just want to add that I've been wrestling with Media + File Entity for over 2 years now on some very large sites (such as EPA.gov) and have recently decided to move away from it.
While there have been plenty of pains over the years (mostly around file_usage and WYSIWYG integration) my biggest complaint from an architectural standpoint is along the same lines as Slybud's: not all files should be considered "media". File Entity takes over handling of all files and it's tough to get File Entity to play nicely with other contrib modules. You end up with all kinds of UX gaps if you want to use any functionality that's not expressly written to integrate with File Entity. If File Entity can make it into D8 core then I'm optimistic that these things can be worked out since contrib will have to be written with its features in mind, but without it in core I'm thinking it's a bit of a lost cause.
As it stands, I think the approach taken by Scald and Asset (Asset being my current favorite solution) to provide an intermediate entity is much cleaner.
it's tough to get File Entity
Could you provide a couple examples please?
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
If you want to use any
If you want to use any special input widgets or file formatters like those for cropping images it's a problem. Multiple-upload tools (like Plupload) have to be made to work with it and have some issues. Getting things like colorbox to work easily isn't always a joy. Throw proper handling of file entity's access layer into the mix and things get pretty hairy.
If you have one mime type map to multiple bundles then any non-File-Entity-aware upload interface won't give you the chance to map to the correct bundle without custom code. Likewise, if you have required fields on your File Entities then any non-File-Entity-aware upload interface won't be able to enforce that, thus allowing "invalid" files into the system.
Those are just a few things off the top of my head. I felt like I saw the vision when File Entity first came out, but after living with it in the trenches I'm pretty convinced that a separate media entity is the best approach.
This is a problem that will
This is a problem that will always happen with any solution in contrib and the only way to solve it is to get something in core. The proposed media entity for D8 will likely be in contrib until D9, so I'm not sure how it would solve that problem?
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
I think there's a need for
I think there's a need for the media entity regardless of whether File Entity gets into core. Trying to support everyone's various media-related needs in a file entity is pushing it, I think. Separating the notion of file handling from media handling has the further advantage of allowing extensions that only want to work with files to do just that without having to concern themselves with the overhead of everything that a Media entity has to contend with. With Media/File Entity's current architecture, if you want to allow someone to use a cropping widget somewhere on a simple file field you may have "broken" your media library by allowing items in that don't conform to your business rules (i.e., they're missing required fields or something).
Essentially I'm strongly agreeing with what some others have said that not all files are media and not all media are files. This is basically what Scald and Asset have done, and, as I've used them, I've found them superior to Media/File Entity as a result.
Multiple-upload tools (like
I think a correlation to core and Drupal itself is appropriate. Before D8 we've had X number of WYSIWYG solutions and trying to support all of them has been an incredible challenge and not something I would consider successful. Likewise, with File entity, because Plupload is not in core, and cannot be easily bundled with the module, we have to support it optionally, where as if we could just always depend on it being there, we could ensure everything works with it all the time. If we can standardize on one tool rather than try and support everything, it is much more successful. We can do that with a lot of things with File Entity itself in D8.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
Meanwhile in related
Meanwhile in related news.
There is a patch at https://drupal.org/node/2061377#comment-8258425 for D8 that lets you choose an image formatter when inserting an image into a body using Ckeditor.
It needs review and/or re-roll.
Not really related to the
Not really related to the current discussion, but appreciated.
Senior Drupal Developer for Lullabot | www.davereid.net | @davereid
Storage is not the only problem we need to discuss
I am very glad to see such an active discussion. It is much needed! A lot has been said about "File entity vs. Media entity" question, but I think it is definitely not the only part of the story that we should talk about. A lot of good arguments has been said about that topic and I'll try to collect all pros and cons of both approaches in a wiki page, which will hopefully help us to see bigger picture. I would, however, like to talk about another thing - plug-ability.
One of the conclusions in Prague was that we definitely need pluggable ecosystem that consists out of independent components. My drawing explains that:
I see all D7 solutions as big monolithic "handle-everything" pieces, which is bad in many ways. Big chunk of code is much harder to maintain and control than smaller pieces. Also, smaller pieces can be maintained by different people, which spreads load and helps the whole ecosystem become sustainable.
Every site can decide for different subset of components that work for their needs. This solves "we will never solve cases of that 20% of cases" problems. The most important thing in this aspect is common foundation. All solutions (i.e. subsets of components) need to share common ground, which prevents re-implementation of same code all over again and also makes development more sustainable.
Since components should only deal with very limited scope it will be tricky to build a media solution from scratch. A lot of background knowledge and configuration will be needed for that. This will work for bigger sites with big and experienced teams, while it will be problematic for smaller sites. That's why we need to provide few "feature modules" that will depend on a subset of components and come with some sane default configuration. Each of this feature modules can cover a different type of use-cases. I see current media solutions very appropriate for this task as they have users that are familiar with them. With this approach we get common ground (i.e. "low level" components) and ability to be creative w/o re-implementing entire stack over and over again.
One example that proves this is display configuration in File entity, which is very powerful but also complicated. My experience is that it works well for complicated use cases, while it simply comes with to much overhead for at least 60% of sites. Why not provide two display configuration components? One with limited feature set and simple configuration UI and another that works similar to what we have in File entity ATM? It is obvious that display configuration definitely is a good candidate for a component. Others might be storage, access control, site-wide library, remote media providers, WYSIWYG integration, uploader plugins, ...
I agree about the importance of storage implementation details (i.e. File entity vs. Media entity), but that is still only an implementation detail at the end of the day. Decoupling question seems to affect much more aspects from the other hand. I believe it could help solve much more problems (pace of development, maintenance, spread of load among more people, we can solve case X but not Y problem, ...).
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
Comparison table
I created a wiki page where I tried to collect all pros and cons of both approaches (based on this discussion). Feel free to update it with more items.
Is seems that main argument for File entity is that it can solve problems that we exposed with help of oEmbed. I'd like to hear if there are any complex sites out there that actually implemented that approach and are happy with it. Any case studies maybe?
I can list at least two huge D7 sites that use "Media entity" approach (Radio France with Scald and Examiner with custom implementation which is conceptually very similar to Media entity).
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
I've used it on multiple
I've used it on multiple sites. The majority of the use cases have been to embed youtube and vimeo video and soundcloud audio. The question about people being happy with the result- the complaints that I heard have more to do with the media interface than with the embedding functionality.
http://24b6.net
Do we need multiple layers?
Forgive me if this is naive, but if we were to have a fieldable Media entity that could reference (among other things) files, then is it really necessary for those files to also be fieldable entities? Is there a reason why you would need multiple levels of fieldability?
I guess what I'm wondering is what would happen if we essentially merged File entity and Media entity, so you only have one layer of abstraction between you and your file? In many ways I suppose this is similar to the File entity approach, but I'm thinking you would decouple the entity from the file system a little more and bring in some of the additional flexibility from Media entity. Plus I think Media entity is ultimately a better name. :-)
I'm picturing something like this:
So nodes (or any entity, really) could have media fields that directly reference media entities, or they could use tokens in WYSIWYG fields that reference media entities via a WYSIWYG plugin/text formatter.
Each Media entity bundle would have a media resource field that could reference the actual resource. This could be a file resource field, or a YouTube resource field, or a Twitter resource field, or whatever. Different resource fields would use different resource link plugins to manage the connection between the media entity and its media. A simple resource link plugin might act as a bridge between the media entity and actual files, going through the file API. Other plugins could provide connections to outside web services, providing video, or tweets, etc. And yes, there could be a plugin that allowed any Drupal entity to be used as a media resource.
This architecture would seem to provide all the flexibility required to do just about anything. It doesn't make the assumption that all media are files, or the assumption that all files are media, but it also doesn't pile on the complexity of multiple layers of entities just to post an image.
Exactly
It is exactly what we want to do with Media Entity. Especially this paragraph:
There is BTW a problem with a field per resource plugin. Basically, we want to avoid a "video media entity" bundle to have one field for YouTube, another field for Vimeo etc.
Confusion
@jcisio, that was not my understanding. If you look back at the very first comment on this thread I asked if the media entity approach would also still include file entities and I was told yes, it would. I'm suggesting that multiple layers of entities may be unnecessary complexity which, I think, is one of the arguments @Dave Reid has expressed against the media entity.
As for your multiple field concern, I see no reason why there would need to be a one-to-one relationship between resource fields and resource link plugins. For instance, you could have a single Web Video resource field that was able to validate links or embed code from any number of services, choosing the appropriate resource link plugin to use for the given input. That said, local video files and externally hosted video files would probably be handled by two different media entity bundles, with different resource fields, but I don't think that's a bad thing. A little segmentation can be a good thing.
Files as entities by it's nature
Files are entities by it's nature in core. Even when you use a file field to upload a file you actually use entities for that. Media entity would work very similar, but it would certainly not require files as "full featured" entities (fields, ...).
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
If the point of this exercise
If the point of this exercise is to develop a new, comprehensive approach to media, the we should start with disposing of some of these current givens.
I understand that Core currently treats files as entities. However, I'm hearing one group of people here insisting that using the file entity system to handle all media does not provide enough flexibility and makes inappropriate assumptions about media being files and files being media. Meanwhile I'm also hearing a group of people arguing that adding a media entity on top of the file entity just adds unnecessary complexity and isn't needed in most cases.
I'm suggesting that we build an alternate system that bypasses this current model, with an eye toward eventual integration in Core. Unless I'm missing something, the file entity is completely unnecessary in the media entity model, so why use it? I can't think of any reason why you wouldn't want a media entity to talk directly to the file itself, without going through the overhead of another entity. At least for something as simple as loading a single image file.
The Media Entity seems unnecessary
The more I think about it, the more the Media Entity seems unnecessary. My understanding is that the Media Entity is required to decouple the media components (eg. the Media field), from File Entities. This is needed as soon as you understand and accept that a media is not necessary a file (eg. a YouTube video is not a file) and that a file is not necessary a media (eg. user uploaded avatars are not media). But for this, an additional entity type is not really needed, as illustrated in the following class diagram.
Through a media field, an Entity references a Media Resource and its Type. The Media Resource Type is actually a plugin identifier to allow consumer of the reference (eg. the rendering component) to retrieves a Media Resource Type plugin instance. The instance can then be used to load a Media Resource implementation identified by its ID (Media Resource is a plain PHP interface defining the methods needed by the core media components). Because entities are a common and well known, the components from the core media can detect entities based resources (because they implement a shared sub-interface) and directly use the underlaying entity when needed (for instances to re-use view modes for rendering).
This completely remove the dependencies of the media component over any existing or new Entity type. For most use-cases, the added layer (ie. the Media Resource interface) is not more complex than adding an intermediate entity type while offering nearly as much flexibility. But for simpler use-cases (the 80%), the additional layer will not leak into the UX without additional UX effort (ie. users happy with each "file is a media and each media is a file" will never have to deal with both the Media entities and the File entities).
So, do the YouTube videos get
So, do the YouTube videos get an entity too? What happens if I want to, say, add a caption field to my videos? What entity am I adding the field to?
Not in this example
Not on this example diagram, a Youtube video does not get an entity and thus is not fieldable. But the relations between the Entity and a Media Ressource could be fieldable (allowing a caption to be added to the relation itself, not the resource or the entity). And nothing prevent the developpers of media_youtube to use a Entity to represent a YouTube video. The example diagram shows that using an entity to represent a media resource is not required.
Please correct me if I'm
Please correct me if I'm wrong... This approach still uses File entity (i.e. Stream wrappers) to save information about media and that is exactly what we want to avoid with Media entity approach. It looks that MediaResourceType handles only the business logic around media. Am I right?
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
sorry for the double post
sorry for the double post caused by an unreliable connection
This approach does not use anything to save information
This approach does not use anything to save information. Instead it rely on the Media Resource class implementations to save the information. The Media Resource is an interface defining the methods needed for the media components (inc. the UI) to consume the media (incl. managing informatiom about them). These methods coul be business logic as well as information storage and retrieval one.
In the diagram, a Youtube video is not represented by any entity. Information about ait it not savec locally. The remote Youtube remote API could be directly used (with proper caching) to save and retrieve information about the media (removing complexe synchronisation between entities and Youtube's internal storage).
Storage would be responsible
Storage would be responsible on MediaResource implementations? Do I get it right?
Did you do any estimation about effort needed to implement basic operations with this approach (render, edit, update, ...)? One big advantage that we get if we stick with entity system are APIs that already exist in core, which make our life much, much easier (I can confirm that from what I've seen during initial work on Media entity that happened in Vienna and earlier). Plus, there will be a lot of contrib candies that work out of the box with properly implemented Entities, which is probably not the case with custom implementation.
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
Yes, storage would be the
Yes, storage would be the responsibility of the Media Resource implementations. Which means that for entities based implementations, storage will be actually handled be the existing entity storage.
One big disadvantage of using a unique Entity type for all media (ie. the Media Entity) is that all media have to use the same entity type. If you want to mix remote media (incl. the information about the media) with purely local media (eg. local file) and hybrid approach (remote resource with local information), all of them have to be handled with the same entity type. AFAIK, you will not, for instance, be able to use different storage engines for different kind of media. Also remote entities require special care at the level of the entity type. I doubt that anyone will be able to design and implement a single entity type that fulfill all the needs for all the variation of what a remote entity may be.
Also, adding an additional entity type for resources that are entities adds an abstraction which will have to be hidden to the end user. But all abstractions eventually leak (no matter how good the UX is) and we will always end with users having the known about both entity types and understand them both.
Nope. Media Entity does not
Nope. Media Entity does not hold ALL data. E.g. file based resource type can be handled by the File Entity. I never imagine you want separate entity types for separate media. You can't even in that case do a simple operation: list all "media entities" on your site.
@mongolito404: Media Entity is both very lightweight and flexible with the resource plugin. From what I can see, what you describe, with some incorrect terms, is pretty much what Media Entity is designed.
I glad that this is what
I glad that this is what Media Entity aims to be. With my knowledge of the Entity API is in Drupal 7 and the little I known about Drupal 8 I doubt an entity type could be lightweight (as in an API that which can be mocked in less than about 500 LoC). I would be happy to be wrong on this.
Entire file that implements
Entire file that implements Media entity has 321 lines. Entity API in D8 is much, much more powerful than D7.
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
Please excuse the UML if it
Please excuse the UML if it doesn't make any sense, as I'm just making this up as I go along, but I think this is more what I was thinking:
So every media resource would have a corresponding fieldable media entity. A media resource field on the entity would reference a media resource type plugin, which in turn would load the appropriate media resource plugin, which would get the resource itself. Note that some resource types—like an embedded web video—may be able to handle media resources from several different sources, requiring different resource plugins.
There is no a fieldable media entity
No, there is no need for a corresponding fieldable media entity for each media ressource. For media ressource which are entities, there is no need for an additional entity. Instead adapters are used in order to present to entites to the consumer of the media API as Media Resources. For resources that are not entities, a dedicated entity type could be used or no entities could be used at all. For instance, there is no need to use entities for resources with remote stored information. Instead, a Media Resource that act as a local proxy to the remote resource and its information is used.
But I want a fieldable media entity :-)
I added in that last Entity Media Resource Type in response to use cases presented in these discussions indicating that some people would like the option of using an entity (like a node) as a media resource for a media entity. This does add some interesting flexibility, but I agree it would not be needed in most cases and should not be used unless absolutely needed. In all other cases, there is only one entity per resource. Remember, I've done away with the file entity, so even local files are just using the media entity.
@mongolito404, you seem to be assuming all the information I want associated with a remotely stored media resource is stored on the remote system and is accessible from there. That may not always be the case. I will always want the option of adding locally stored fields to remote resources and I see no reason why you wouldn't want to treat these resources as full-fledged entities within Drupal. I'll also want things like views integration, path aliasing, and content moderation that you can get from being an entity.
I do not assume one will
I do not assume one will never want to associate anything to a remotely stored media (resource). And I do not assume one will always want to associate something with remotely stored media (resource) through an entity. I also do not assume that one will always store locally information associated with a remote media (resource). One could use the read/write API of the service providing remote media (resources) to store information associated with them.
My suggestion let the developpers of an integration decide wheter or not they want the information associated with their media (resources) stored locally or remotely, using entities or not.
Because a media (ressource) is not necessary an Entity, this makes things easier since there is no need to bend the Entity API to deal with remote content (AFAIK, there is two contrib module to deal with remote entities in D7, both a rather complex from a DX perspective).
When you start working with
When you start working with media, you very soon realize that you need to store local (in drupal) extra information about theses assets. To keep the example of Youtube, let's consider these 2 uses cases that are just a few ones I can quickly think of :
* you want to display videos in something like a wall/list and you want to be able to sort theses lists by video duration ? Should we have to write a view handler that would make dozens of calls to the Youtube API to get the durations, everytime we want to display that list
* you sometimes don't want Youtube to handle all the thumbnail images of your videos, not being able to upload your own thumbnail into drupal
IMHO, Youtube and other more professional video providers are good at encoding, broadcasting and handling/maintaining the players for every possible device. But one can not rely on their API to get extra information about video : assuming this means that the CMS power of drupal is useless on these assets.
The SPARQL Views
The SPARQL Views (https://drupal.org/project/sparql_views) module is a proof that you can integrate remote data in Drupal a keep much of the CMS power.
Again, in my suggested architecture there is nothing preventing a full featured third party integration that store local information about remote resources. But it allow simple, straightforward integration of third party services for users with simpler needs.
File Entity provides this for
File Entity provides this for us already.
http://24b6.net
Entities are now the standard
Entities are now the standard representation of all content in Drupal. This provides some much needed consistency and is one of the strengths of our CMS. Nodes, taxonomy terms, and even users are all entities. Every module out there that deals with content knows how to deal with entities. It seems crazy to me that we would not want to represent media resources as entities.
I think its also very important not to forget the site builder experience. Most people using Drupal will not have the skills needed to turn a remote media resource into an entity if they need it. The expectation will be (and rightly so, IMHO) that they can add fields to different types of media and create media views, without any extra coding.
THIS
THIS is what Media Entity is planned to do/is doing. THIS is also what Scald is doing in D6 and D7 (you can look at the code, it exists).
@jcisio, unless I'm horribly
@jcisio, unless I'm horribly mistaken, this is not what Media Entity or Scald are currently doing. Both seem to be still using the existing File entity, thus adding an extra layer of entity that isn't at all needed.
Hm, the discussion appears to
Hm, the discussion appears to boil down to a File entity or not discussion (=all-out war?). If I am not mistaken, neither side wants to deviate from their standpoint. This is sad because a joining of forces is badly needed if there is ever to be a unified media experience for Drupal.
Is there a way to take one step back and collaboratively develop a data model that fits everyone? I realize this is what is also done in this thread, but the Media entity vs File entity battle appears to overshadow the attempts to find a common ground.
The best place to discuss it and find this common ground might be a Drupalcon, but the next one is quite far away.
Life is a journey, not a destination
I don't think this is a war.
I don't think this is a war. For me the concern is that I see the concept of a media entity duplicating some of the functionality that file entity already provides and has the many of the same challenges that file entity currently has.
I think there is need for significant improvement for the media interface- but this is true of any solution right now. There are also lots of challenges in the interface for creating view modes, bundles, etc. for file entity- and a new concept of a media entity would share these.
File entity provides some critical API features that core doesn't offer. In D8 this maybe less so, however I'm unclear on how some new entity would be built that would implement the same API features that file entity provides that would be simpler or offer more flexibility.
Slashrsm does a good job of laying out the trajectory of things which I mostly agree with:
1. Ecosystem needs to consist out of decoupled components with very limited scope
I think this is right. I think file entity is a reasonable basis. There is functionality in file entity that maybe replaced with D8- great. From what is spelled out here I'm not sure that you would want anything with less functionality as you would limit the potential integration with other work.
2. Basic components of the described ecosystem need to be available soon in Drupal 8 release cycle
Yes, absolutely.
3. Use existing tools as much as we can
Absolutely.
4. Storage should be based on a structure that does not assume all media are files
Quoting from the post here: I agree that it is possible to treat almost everything via stream wrappers and there are cases where it makes sense even for remote media. But there are cases where it simply doesn't make sense to do that. There are also some use-cases where it is not even possible.
I think these use cases need to be spelled out. I can't argue this point without more information except to say that we should be clear on what these outlier cases are and why they are driving a different direction of work.
Quoting slashrsm out of context: This approach still uses File entity (i.e. Stream wrappers) to save information about media and that is exactly what we want to avoid with Media entity approach.
So it seems to me (and please correct me) that we're getting down to a question of how we reference something. I think the serious objection to file entity is stream wrappers. Slashrsm- could you provide a bit more information about the final diagram in your post which shows the media entity's relationship to what are identified as "resources"? I'd like to understand better what this relationship is and how it solves your concerns about stream wrappers not being able to reference something.
Also thank you (slashrsm) for trying to keep this conversation going. I know I'm being "that guy" but having been involved with Media from the beginning, we saw the use of stream wrappers as both radical and freeing from so many of the problems that we have seen with file handling in Drupal. While I recognize that there are problems with them, I see them as an enormously powerful way to reference data without making assumptions about what it is or where it's located. I'm happy to be proven wrong.
http://24b6.net
I agree!
I don't see this as a war either. There are simply lots of strong opinions about the topic, but we'll eventually need to find our way through that.
I am really glad to see this discussion finally becoming a bit wider (i.e. not only Media vs. File). As I already said in one of my previous comments I believe there are parts that are much more important than the one we talk about 99% of this thread.
I think these use cases need to be spelled out. I can't argue this point without more information except to say that we should be clear on what these outlier cases are and why they are driving a different direction of work.
Lots of very different media could be included into this group. All remote media (YT, Soundcould, Vimeo, ...) are one part of it. However, cases where Media approach fit much better are all "one-to-many" situations. Examples of those would be a photo gallery, video gallery, music playlist, etc. It is impossible to reference a group of images with an URI in a clean and denormalized way, while it can be handled by Media entity very naturally. With a multi-value field for example.
It seems that oEmbed can handle this kind of situations, but I don't have any experience with it. I have no idea how hard it is to configure an oEmbed provider for an image gallery, how well it fits in Drupal's media library and interface and how complicated the editorial work-flow around that is. Those are very important questions. If we have something that can be done and is PITA for editors we failed IMO.
Slashrsm- could you provide a bit more information about the final diagram in your post which shows the media entity's relationship to what are identified as "resources"? I'd like to understand better what this relationship is and how it solves your concerns about stream wrappers not being able to reference something.
On a very basic level it is all about the field API. In case of a single local image you have a single-value file field which attaches local file to a media entity. In case of a local image gallery (i.e. N local images) you have a multi-value file (or image) field + some other fields for meta-data (description, credits, ...). In case you need per-image meta-data you could have a multi- value entityreference field that would bring in N media (or file) entities, each bringing in a single image. Those single items could have it's own meta-data fields (title, description, ...) and parent media entity could also have it's own (credits, some taxonomy, ...).
We would use other field types for remote (any other funky) media resources. Actual type would really depend on each case.
Media usually comes with some business logic. That could be handled by a D8 plugin type, that would bring that logic and raw data together. There could be a plugin for each resource type. Plugin could be responsible for definition of storage model (type of field being used with it), some standard logic ("get a thumbnail" for example) and some resource-specific logic (meta-data that can be fetched from remote provider (i.e. YT video title, description, tags) for example).
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
I think what is described
I think what is described here as a media entity would require or duplicate file entity (I also don't think we need to make this an either/or issue. ). I don't think there is a clear differentiation between a "resource plugin" and a stream wrapper. While I don't know how complicated writing the resource model would be I do concede that writing provider stream wrappers is not very intuitive. That being said we have a pattern for doing so and integrating with view modes already- there are examples for youtube, vimeo, soundcloud, oembed, etc.
Examples of those would be a photo gallery, video gallery, music playlist, etc. It is impossible to reference a group of images with an URI in a clean and denormalized way, while it can be handled by Media entity very naturally. With a multi-value field for example. - slashrsm
I agree that these are not use cases for file entity (unless somebody wants to write an entity://node/ID provider... ). However I do think there are architectural patterns already for what I understand is being proposed here- for example an image gallery content type or an image content type. In each case additional meta data can be provided on the enclosing entity which does not rely on the file entity to contain the data- as is proposed here.
Aaron wrote media_node which allows for the insertion of a node via media wysiwyg. This allows for an image gallery to be used inside a different piece of content- which is what I understand one of the advantages of the media entity approach. I imagine views attach to provide dynamic content as well- a constantly updated playlist as a single entity for example. This is also not a file entity approach- it's simply using the media filter to render the node inline.
So where does this leave us? I think there are many cases where something like media entity is needed- I've implemented something architecturally similar on a number sites. Do we need to codify it in a specific module? I'm not so sure. Quoting slashrsm: Media usually comes with some business logic. I'm not sure that we can come up with an abstract entity which will add value over the basic use case that the current media module and file entity provide.
What I'd like to see is work on the file entity bundles and configuration, substantive work on media's wysiwyg integration, configuration, previews etc. Perhaps bundling more default providers for file entity (remote stream wrapper, oembed, youtube, etc). should be considered. I think one of the biggest barriers to the use of file entity and media is how hard it is to understand all of the components work together. I don't think the proposed media module solves any of this. Many of the complaints about the current approach reflect misunderstandings of how to use it- I don't think that that is the fault of the people trying to use it.
So how do I think we can move forward? Let's make the UI/UX component great. It should be entity agnostic. With views in core we should populate the media browser from that, allowing for admins to choose whatever entity types they want. This should not be impacted by any decision of file vs media entity.
Let's make it so that the site admin doesn't have to touch file entity configuration unless they have a special use case. I would hope that a site admin doesn't have to care what system is actually holding the URIs to individual pieces of media. If they do I think we're probably doing something wrong.
I absolutely understand that file entity in itself is not sufficient to solve some of the use cases identified. I also think that we already have the tools to do what what's desired here. What I don't think we have is an easy way to do these things. Some of that is documentation, some of that is default settings, some of that is simply a very challenging UI and requires complex understanding of Drupal components that I personally don't expect a site admin to have.
http://24b6.net
However I do think there are
However I do think there are architectural patterns already for what I understand is being proposed here- for example an image gallery content type or an image content type. In each case additional meta data can be provided on the enclosing entity which does not rely on the file entity to contain the data- as is proposed here.
Main problem with this approach is that those nodes are not treated as media. That fact separates them from the default media workflow completely (media library, etc.).
Also... "Make everything a node" approach is sooooo D6. It is totally understandable that people used nodes + CCK for almost everything as those where the best tools we had back then. Situation is completely different now. D8 entity API is very powerfull, there are fields literally everywhere, we use entity reference a lot, ...
I think there are many cases where something like media entity is needed- I've implemented something architecturally similar on a number sites. Do we need to codify it in a specific module? I'm not so sure.
And you are not the only one... There are lots of projects that implemented similar things and that should be main reason to come with a standard solution. It will save us a lot of resources compared to N custom solutions.
Let's make the UI/UX component great.
Could not agree more with that. This is the most important part!
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
So I'm going to avoid getting
So I'm going to avoid getting into the nitty gritty here and instead try to identify what I think are points of alignment:
Priority of work needs to be on UI/UX. I think we can maybe agree that this is an independent project which could be the current Media module abstracted to not require file entity.
File entity work continues irrespective of the concept of a media entity- from the discussion here it does not sound like there is any dispute that the concept of media entity would not need access to drupal's file entities (whether something else is needed would be a debate).
Here's what I see as a significant point of contention:
Does this begin to clarify what needs to be hashed out in point four of the original proposal? It seems like there is alignment on the objectives (perhaps not the implementation) of the first 3.
http://24b6.net
Thoughts about the UX for a Drupal media solution.
Personally, I have moved away from using a WYSIWYG solution for media insertion. Partly because it’s never worked very well, but I have also come to believe it may not be the best solution for a robust content strategy. That said, I understand we do need a solid WYSIWYG media solution to remain competitive.
Generally, what I need are media fields that I can attach to entities (be they nodes, or field collections, or whatever) and configure for specific uses. As an example, lets take a hypothetical “Movie” content type. I might have a media field as part of a field collection used to define my body copy, and I might have a separate media field on the node to define a hero image for the content, and I might have yet another media field used to specify a preview video for the movie. Each of these fields need to access my media library, but each should only have access to a specific segment of the library. Perhaps I want broad freedom to insert just about any media into the body copy, but the hero image field should only have access to images, and the movie preview field should only have access to videos.
This is where I ran into trouble when I started looking at the fancy drag-and-drop media browser provided by Scala. It’s single, ever-present media browser, always shows all the media. There was no way I could find to restrict the library, so when a user is editing a field that should only display images, they are only shown images to use. I would MUCH prefer a button or something, on each field, which called up a media library browser specific to the field in question. Showing users a bunch of stuff that they can’t actually use for the task they are currently doing is a big UX fail, in my experience. It leads to mistakes and confusion.
This same holds true for WYSIWYG integration. When I was testing Scala, it let me drag a media resource into a standard text field that was never intended to show any media (https://drupal.org/node/1965834), It just displayed the token as text in the field. And even with WYSIWYG enabled text areas, it didn’t put any restrictions on which resources I could pull in. Again, this is a huge UX problem.
I think the best approach I’ve seen to date for WYSIWYG media insertion is the WYSIWYG Fields module (https://drupal.org/project/wysiwyg_fields). Truth be told, I’ve never successfully used it on a production site, but I’ve always loved the basic approach of this module. Given a little more development support from the broader community, I think this could form the basis of a fabulous general purpose tool for inserting things into WYSIWYG text areas. If implemented, you would add a standard media field to the entity bundle, but you would configure that field to act as a WYSIWYG field. This includes specifying which editor profiles should be allowed to insert the media. Those editor profiles would then have a button available to them in their configuration settings. When editing an entity, this media field wouldn’t display in the edit form. Instead, you would click on the “insert media” button in the editor toolbar for the text area and it would call forth the media browser. Behind the scenes, we would store all information about embedded media resources in the field, with the text area holding tokens which reference these field values.
Some things I like about this approach are: By using fields to reference the media entity (or file entity, or whatever we end up calling it), you get a lot of extra stuff for free. It makes it easier to, say, create a view showing nodes that are using a specific media resource. You don’t need an extra mechanism to track nodes that have media resource tokens in their text fields. I also like that this is a great general purpose module. In addition to media fields, I could also set up editor buttons to insert field collections, or views fields, or whatever.
Another issue I’ll mention is the need for per-instance overrides of media resource configuration. The specific issue I ran into recently involves cropping (https://drupal.org/node/2165189). I added a media field to a field collection and I wanted editors to be able to crop the images they uploaded. The problem I ran into with all the cropping modules is that cropping is performed on the file entity, rather than on the instance of that file’s use. So if I have multiple editors who all want to use the same image on different nodes, with different crops, then either they will constantly be overriding each other—which is unacceptable—or they will need to create multiple file entities for the same image—which negates much of the benefit of a media library. Cropping is likely not the only situation where this sort of feature is needed, but it is a common one.
One last issue to keep in mind is publication workflow. Media resource entities need to be revisionable and they need to work with content moderation solutions, like Workbench Moderation.
I guess you meant "Scald"
I guess you meant "Scald" (the media management module) and not Scala (the programming language) :)
Sure, the media library solution in Scald is not perfect, and this is why we need to have strong UX/UI debate when implementing a unique Media solution in D8, because the "per field" customization approach of the media library also has its drawbacks (including more clicks for the end-user).
Customization of the media library is relatively easy right now because it is a view and benefits from the whole power of the View API. I think it should stay that way in D8.
And IMHO, a differently cropped image is another media resource, not the same one, because the act of cropping is editorial and leads to another image, which does not express the same point of view as the original one. Unless it is always automatically crop the same way with Image Styles.
Revisioning
You bring an important point about revisioning. This is a common need, at least for larger organisations, generally to be able to provide moderation like what Workbench does. As far as I know, file entities cannot be revisioned, and I'm not sure there is a good way to work around that.
Revisions brings up
Revisions brings up derivatives as well. I don't think we should tangent this conversation to derivatives but I do think there is a relationship between file revisioning and how we think about creating derivatives from original files. I think that file entity itself has to handle revisions- leaving this up to some kind of wrapper entity is always going to run into issues- consider the following:
I have a store and I want http://mystore.com/catalog.pdf to always point to the current catalog file. However I also want to keep historical versions of my catalog- for example catalog-2012.pdf for my staff members. Yes this could be done with a view, it could be done by hand, done by a multivalue field, but simply being able to add a new revision of the file the same way we do with nodes would be great.
Asper jstoller's comments about wysiwyg integration- I agree that it's not perfect. The wysiwyg_fields approach is a really good one- though it is somewhat complicated to integrate. Regardless the browser that lets you upload or choose files needs work and that work should apply to wysiwyg or file fields themselves. As I noted above I think the browser needs to be agnostic to the content that is chosen- I agree that it would be ideal for it to handle things other than file entities.
http://24b6.net
Once you start with
Once you start with revisioning you quickly leave the space of a media management solution used to support their usage in the CMS (what I think Media seeks to be) to become a full fledged digital assets management (DAM) solution. While I do think Drupal is a perfectly viable base for a DAM solution, I don't file like this should be a goal for Media. Media management is hard enough to generalize and implement right (to meet the need of 90% of the user), but a DAM will be even harder.
Scope
Actually, I think it would be a good idea to build the structure for a D8 media solution with a DAM (Digital Asset Management, for those reading this comment out of context) in mind.
No, most people don't need the full fledged functionality of a DAM, but if we don't plan for this functionality it means someone who builds such a system will have to create a completely separate system. This is what got us in the current situation where we have Media and Scald both implementing a YouTube integration (and many others), resulting in weeks of duplicate efforts.
The question whether we want a distinct media entity or not might actually come down to whether we want a DAM or a simple way to integrate media in a CMS. A media entity does bring some overhead, but it comes a lot closer to what you would expect in a DAM. If we allow for that overhead while trying to make it as small and as transparent as possible, we could make it possible to keep the same structure for everyone: the 80% who just want to add videos to their website, and the 20% who need a DAM and can actually finance all this work.
As I was thinking about this, I came up with the following way to think about it (please ignore if it doesn't make sense to you):
What we currently have (difficult to add a DAM in the middle):
CMS <> Media Integration <> Actual media resource
What the media entity model suggests:
CMS <> [Optional DAM] <> Media Integration <> Actual media resource
I continue to think that with
I continue to think that with proper architecture and lightweight abstraction layers at least 90% of the UI could be independent of the underlaying entity and could be adapted (using the adapter pattern, not code-rewrite) it to Media entity, File entity or any other heavyweight storage layer (yes, from a DX PoV, anything entity-based is Heavyweight. No matter how much LoC is needed, you need to known a rather large and complex API to use entities). That would allow the same UI to be used on different solutions. Instead of trying to define one-true solution that fit them all in oder to develop its UI.
I am still unclear on how a
I am still unclear on how a resource is realistically going to differ from a file entity. It's also unclear on why this attached to an entity is somehow lighter weight (if it should even be considered not light weight) than what file entity provides. Specifically the pattern above CMS <> Media Integration <> Actual media resource at it's simplest would be a URI to the resource- file entity gives us this URI already.
When file entity is being critiqued as "heavy" I would like the conversation to turn to specifics. I can see places where people might be concerned with code weight, performance, or configuration complexity but what I'm not hearing are specifics of how some other implementation of data storage is going to alter any of these concerns.
I absolutely agree that we need to improve the framework for the media browser (from the current media browser). It sounds to me like we're really honing in on agreement that this has to be a significant focus of D8 work.
http://24b6.net
I am still unclear on how a
Resource is more general thing than File entity. File entity is only one of the possible resource types.
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
@jstoller: I made a request
@jstoller: I made a request for per-instance overrides of media fields in Create entity reference widget. At present we use a multivalue field collection to do this, with a custom WYSIWYG plugin to insert those field collection items instead of using the media browser in WYSIWYG.
upgrade path
Are the proposed media entities different than the previous media fields (from Media 1.x)? And will there ever be an upgrade path, or are we early adopters (who are still using media fields and unable to upgrade to file fields) going to be forever stuck?
Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org
CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.
media is the future
Just my 2 cents, and I admittedly haven't taken the time to read every detail of the conversation up until now, but I just wanted to add that we are using Scald for a very large project and I would take anything the guys tied to Scald have to say very seriously. They have a very well-thought-out approach that started out with flexibility, speed and extensibility in mind. We have yet to come across a major roadblock using that solution for a VERY large site and are going to production with it soon. Not that Media doesn't have some great things, but it was, as the maintainers I'm sure would concede, birthed in a D7 mentality, whereas Scald seems to have a much more forward-thinking, extensible core. This is not the place for a Scald v. Media debate as the point is moving forward for Media in core, but just saying that, based on our experience with Scald, I would listen closely to those guys' opinions on how to make this part of the Drupal experience as good as possible in the future (and NOT comparing to WP, but better). If it has to come from the contrib space, so be it, but I think would hope that robust media management is a huge benefit for anyone wanting to build a solid site out of the box. The better the solution for managing that media out of the box, the better for Drupal's future as a site-building platform.
When will decision be made?
How much longer might this debate go on before a method is chosen and actually built? it seems like media mgmt is of such enormous importance to so many sites and kinds of sites and yet it is hard to imagine that this will be finished before a drupal 9. Could someone attempt a brief roadmap? It would be so appreciated. I know everyone is doing their best and trying to get it right. I just ask for planning purposes so I don't get burned again and I'm sure many other people are in the same boat.
Christopher Pelham
Director
CRS (Center for Remembering & Sharing)
http://www.crsny.org
CRS (Center for Remembering & Sharing) is an arts & healing center located just south of Union Square in Manhattan.
There is a media sprint at NYC camp this week
Organizers did their best to bring few media people on-site. Hopefully we'll be able to publish some good news at the end of this week.
Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name
Few ideas
This might be slightly off-track but regarding feature requests for this media initiative here is my 2 cents. We created a module called media_desk in Norway for our large media sites. We did consider Scald but there were a few issues like Scald did not have cropping and the interface was not very intuitive and we feel media is the way to go forward. Our module basically works together with existing modules like media, multiselect, manualcrop, plupload etc. and gives what we needed. Im hoping this media initiative can help bring something alone these lines for Drupal8 or 9.
Here is a quick screencast:
https://www.youtube.com/watch?v=lvDwa_XpSWk
This is much closer to what
This is much closer to what I'm looking for. Thank you for sharing! Does this work with videos or any other type of media you would like to add? I like how scald allows me to add tweets or anything other type of "resource" I would like to use in the body. Will media desk allow for this?
today a media is not anymore
That's true, but, from a philosophical point of view, this is also the boundary of the multimedia era, where a media was something that was extending a content (usually textual). When everything becomes a media, nothing anymore is a media. Any content can be a media and any media may be a content. So if we have to rethink what is a media, we should also think about what is a content today, and try to define/imagine their relationships if any.
You're half right
I get your argument, but if we approach media with the narrow mindset of "oh, historically it's been defined as X", then we are not accepting the reality of the current digital age. Yes, media at one time was limited in scope to images, videos, and documents, but now tweets and maps are embedded in content the same way.
Rather than focus on media formats, we should focus on the use cases. Media assets have been traditionally used to augment written content in some way, either an attachment or something that is embedded within an HTML page. Any future media solution should be flexible enough to support whatever the media asset is, as long as it follows that use case.
Thank you for your reply. I
Thank you for your reply. I think we are talking about the same thing. There was no nostalgia for a past era, no "oh, historically it's been..." in my purpose. Perhaps this was a misunderstanding due to my approximate English.... All I wanted to point is that, as an abstraction, reasoning about media and content, perhaps is not any more the right way, since everything becomes media and everything is content. I'm just calling for experiencing a new paradigm where there in no more distinction between media and content. As you say we should be able to support whatever the media asset is, I should add whatever the content is. Html page should be just a place where content (or, if you want, media) aggregation happens. This should lead us think about horizontal relations between contents (whatever the content is) instead of the current dependency: content (as textual nodes) / media (as images, audios, files, etc).