New York city Drupal camp happened last weekend in United Nations HQ and there was, among numerous other things, Media sprint going on. Organizers did their best to bring some of the most active Drupal Media contributors on-site. We are very happy and thankful that they made this possible, as we managed to achieve some very important steps forward.



Photo by: Jovan Matic

Plans for Drupal 8

Main part of our efforts at the camp was roadmap for Media in Drupal 8 as part of which we achieved few very important conclusions:

Storage components: there are still different opinions about the storage part (AKA "File entity" approach vs. "Media entity" approach - for more info check https://groups.drupal.org/node/384813). We decided that this is fine. We will continue to work on both solutions, while trying to find as many sticking points as possible and share as much code as possible. Entire ecosystem will be split into several sub-components in order for this to be possible.

there are still different opinions about the storage part (AKA "File entity" approach vs. "Media entity" approach - for more info check https://groups.drupal.org/node/384813). We decided that this is fine. We will continue to work on both solutions, while trying to find as many sticking points as possible and share as much code as possible. Entire ecosystem will be split into several sub-components in order for this to be possible. Decoupled components architecture: as already mentioned we're dividing Media ecosystem into smaller pieces, which will be easier to develop and maintain. We will make sure to make every component as generally usable as possible. This will allow us to use them with both storage solutions and also, when applicable, in more general contexts (not necessary related to media itself). "Full featured" media solutions will still exist, but will mostly provide glue that will make individual components able to work together.

as already mentioned we're dividing Media ecosystem into smaller pieces, which will be easier to develop and maintain. We will make sure to make every component as generally usable as possible. This will allow us to use them with both storage solutions and also, when applicable, in more general contexts (not necessary related to media itself). "Full featured" media solutions will still exist, but will mostly provide glue that will make individual components able to work together. Media browser/selector/creator: this part of the system will be responsible for browsing media collections, picking and/or creating individual or multiple media items. It will be used in different contexts as fields (entity reference, file, image, ...), WYSIWYG, global, etc. This component will not be related to media by it's nature. It should be possible to use it also in other similar use-cases (browsing and picking nodes for an entity reference field for example). Existing tools/systems should be used where possible (Views for entity browsing, existing field widgets for entity creation, ...).

this part of the system will be responsible for browsing media collections, picking and/or creating individual or multiple media items. It will be used in different contexts as fields (entity reference, file, image, ...), WYSIWYG, global, etc. This component will not be related to media by it's nature. It should be possible to use it also in other similar use-cases (browsing and picking nodes for an entity reference field for example). Existing tools/systems should be used where possible (Views for entity browsing, existing field widgets for entity creation, ...). WYSIWYG integration: core now supports image embeds by default, but we still want to be able to embed other types of media. WYSIWYG entity embed framework will be responsible for that. It will be able to embed any entity using techniques that were already tested in D7. Entity-specific solutions that we know from D7 world (node_embed, ...) will become obsolete as a result of that.

core now supports image embeds by default, but we still want to be able to embed other types of media. WYSIWYG entity embed framework will be responsible for that. It will be able to embed any entity using techniques that were already tested in D7. Entity-specific solutions that we know from D7 world (node_embed, ...) will become obsolete as a result of that. Display configuration: we will create two levels of display configuration. Field formatter level will provide more basic functionality, while ensuring simpler interface for site builders and administrators. This approach is expected to be used on simpler sites. Media/File entity render will, on the other hand, provide more powerful display configuration system with more complexity. Both storage solutions will share some parts of display configuration components, but it will not be possible to re-use everything.

we will create two levels of display configuration. Field formatter level will provide more basic functionality, while ensuring simpler interface for site builders and administrators. This approach is expected to be used on simpler sites. Media/File entity render will, on the other hand, provide more powerful display configuration system with more complexity. Both storage solutions will share some parts of display configuration components, but it will not be possible to re-use everything. 3Rd party providers: both storage solutions will need own 3Rd party integrations due to fundamental differences in storage implementation.

Next events/sprints

Sprint at DrupalCamp Alpe-Adria (May 17th - 20th)

Week-long sprint at DrupalCon Austin (June 1st - 7th)

Week-long sprint at DrupalCOn Amsterdam (September 28th - October 4th)

Week-long sprint at BADCamp (approx. October 21st - 26th)

Getting involved

In order for Media to really rock in D8 we need a lot of help (by this I mean A LOT!). Are you personally interested in media on Drupal or you run a Drupal company/shop and have to deal with funky media problems and desperately need a powerful and extensible solution for that? Are you able to dedicate some of your (or one or your employees) time to achieve that goal?

We need you! No matter which skills you have! We need help with back-end and front-end development. We also need design/UX skills to create good editorial experience. Are you not a coder, but have good ideas? We need those!

You can reach us on #drupal-media or on groups.drupal.org/media. There will be weekly "scrums" held in Google Hangout onAir every Tuesday at 3:30PM GMT (follow groups.drupal.org/media for announcements).

We need your user stories

There are as many possible media use-cases as there are Drupal websites. In order to be able to design the system in a way that will work for most possible situations we need your feedback - your user stories. Please take few minutes to think about your past project that dealt with Media and try to remember interesting problems that you'be been facing. Then use our form and send them our way in a form of a user story.

Google Summer of Code 2014

We have two quite strong media related project proposals for this year's Summer of code. We are hoping for both of them to be accepted. We will be able to publish more informations about that in the second part of April.

Please help Aaron Winborn

Aaron is a long time Drupal contributor, author of many media-related modules and a great and inspiring person. He is fighting ALS and he needs our help. Please consider contributing to his fund to help them make his and his families life just a little bit easier. Thank you!

We would like to thank camp organizers one more time. They prepared an unforgettable event for us. We would definitely not be able to achieve this progress without their support!