About Me
Senior Developer at Lullabot
Twitter: @davereid
IRC: davereid
Maintain amost 2% of contrib modules
Core subsystem maintainer
Father of two cats and one boy
Why is media important for Drupal
people expect that we do it right
our "competitors" handle this "better" than we do
we have lots of enterprise media companies using Drupal
people expect media-rich websites
site editors expect lean & efficient media creation/organization process
we simply need to handle media well
"If I could snap my fingers and add one single feature to Drupal core it would be good Media handling."
Dries Buytaert @ DrupalCon Portland
- lists all files in the system along with some basic usage (size, filename, usage count)
- view
- embed images
-
- does not support other media types
- HTML5 multiple attribute
Ease of use
Multi-upload, intuitive library, Wysiwyg integration, drag-and-drop, ...
Pluggable framework
Ecosystem of decoupled components that know how to work together.
- feature modules to make life easier
- one can use what really needs
- WYSWIYG
- DnD library
Deliver basic components ASAP
Basic components should be available very early in the D8 production life-cycle
- people can start using thing
- development of solutions higher in the stack
- more chances we end up with a standardized solution
Use existing tools
Entity API, Field API, Plugins, ...
- code for free
- out of the box integrations
- easier for contrib
Non file-centric storage components
Local files are only a subset of all media.
- similar approaches already exist
- no assumptions
- more flexibility
- bundles can have semantic meaning
History: Initial Media and File Entity plans
Problems (we have many)
no stable 2.x release
WYSIWYG handling and regressions
overly-complex out of the box (configuring file display)
uphill battle against
core assumptions
multiple-upload workflow
accessibility
usability vs extensibility
sustained maintainership
and more!
Regroup and rewrite
Started planning a decoupled approach and focus on core problem areas from ground-up.
Focus on involving the ideal workflow and tools from day one.
Split up File Entity into smaller chunks for fieldable files, file types, download formatter.
Basic concepts discussion
There are still some disagreements... but we agree that we disagree! https://groups.drupal.org/node/384813
Photo by Paul O'Donoghue - https://flic.kr/p/cYQVgo
- disagreement basically about one technical detail
- we realized that we can work together on things that we agree on
- which is good!
We keep working on two separate storage components
Apparently there is need for two different storage approaches (file_entity and media_entity ).
Decouple the ecosystem into independent parts
Each independent component should be able to work with both storage approaches
That usually means they can be used also in non-media context
Entity WYSIWYG embed (entity_embed ) - Google Summer of code project
Entity browser (entity_browser )
Fallback formatter (fallback_formatter )
Roadmap - step 1
entity WYSIWYG embed: basic API
entity browser: basic API + working demo
storage components
entity browser: "tabs" plugins
Roadmap - step 2
entity embed: UI/UX, integration with CKEditor
entity embed <=> entity browser integration
entity browser: media library implementation
Roadmap - step 3
entity browser: "currently selected" list
display configuration
fallback/inherit formatter
integration with upload solutions (Plupload, ...)
Roadmap - step 4
3rd party integrations
cropping
derivatives
advanced access control and rights management
Challenges in Drupal 8
We still face some uphill challenges due to some unsolved issues with Drupal 8 core.
But the good news at least is that these can still be worked on.
Challenges in D8
File usage system deletes your files
We need help!
This is not going to magically happen. We need your help in order to succeed.
- would love to say that everything is done, but I'd lie
- have a project?
- interested in Media?
We need people of various expertise
frontend
UX
interface design
backend
project mgmt
ideas, past experience
You name it!