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