Hello, my name is Aaron Winborn. I am a developer for Advomatic, the author of Drupal Multimedia, and a contributor and a co-maintainer of several Drupal modules, including the Media suite of modules.
Today, I will demonstrate a new feature of the Media: YouTube module: browsing and searching videos directly from YouTube, in the media browser itself. So first, let’s set up our environment.
We are assuming that you already know how to install Drupal. If not, you can find information at Drupal.org.
So right now we are at the modules administration page. We are interested in the modules under the Media package. You will need to install and enable the File Entity module (version 7.x-2.x), and the same version of the Media module.
We will not enable the included Media Field module; it is there for legacy purposes, and has been deprecated in favor of core’s File Field.
The Media Internet Sources module, included with the Media module, is a dependency of the Media: YouTube module, so we will enable that.
Next will be the Media: YouTube module, also version 7.x-2.x.
Finally, we will install the WYSIWYG module.
Let’s start by configuring WYSIWYG. We do that by going to Configuration > Content Authoring > WYSIWYG profiles. Note that I have also installed and enabled the Admin Menu module and the Admin Menu Toolbar module, which gives us the fancy drop-down menus for administration that you see here.
Now in order to use WYSIWYG, you need to have also installed a third-party WYSIWYG library, such as CKEditor or TinyMCE. You need to follow the instructions with the WYSIWYG module to install that, although it is quite simple actually. You just download and unpack the file into the sites/all/libraries folder. You can see that I am using CKEditor here.
The WYSIWYG module allows us to set up profiles for the various text formats on our site; in this demo, we will edit the Filtered HTML format.
Open up the buttons and plug-ins field set next. Then check the Media Browser check box. That will add the media browser button to our WYSIWYG editor, which we will see soon.
In order to use that however, we need to configure the filter in question. In fact, I believe that if we do not do this step 1st, we will get an error message, complete with a link to the format configuration page.
On this page, we need to check the box next to “Convert Media tags to markup”. That is the answer to the number 1 support question that we get in the Media queue, which is, “Why is there bracketed goobly gook instead of my images?”
So now, as we will see, everything should be working now. So let’s test it.
Here on the create article page, we see a fancy button on the body text area! Let’s click it.
And there we go.
These are thumbnails being pulled directly from YouTube. How about that?
And there is even a ghetto pager, or at least previous/next links.
And you can also search YouTube directly from our browser.
So now we will select a video and submit it. Add a title and save the node. And there we go.
And that’s it really. Well, almost.
There are some more settings, specifically here to control which tabs show up for WYSIWYG. Note that at the time of this demonstration, you will not have this functionality unless you install the patch over at node 1434118.
To complete the demo, we will also do the same for fields. Let’s add a field to hold YouTube videos. We will call it Media, and it will be a file field with a Media file selector widget.
Here, let’s reorder it as well for the demo.
We leave everything at their default settings.
Hold on, I forgot that we need to allow the YouTube URI scheme. And the video file type.
So now we will create a new article, and select the media.
And here we have all the tabs available to our browser, including the new and improved YouTube tab.
And also, let us look at another new feature of the media module: My files!
This has been a long-awaited feature for the Media module as well.
Now here comes the 2nd most asked question in the support queue: “How come there is a link to my file, rather than the file itself?”
Let’s just fix that now.
Now we are in the file type administration page, where we can configure the display for each of our file types. Note that we can also add fields to our files, although we are not going to do that in this demo.
We will jump to the video display...
No, we want to make sure that our large formatter is set up properly for YouTube. And it is, so let’s set up that as the formatter for our Media file field.
And there it is, as a generic file, which is simply a link to the file stream itself. We will change that to rendered file. And then we set the view mode to large.
While we are in there, we can do the same for our teasers. We will just set that to the preview view mode, which by default will display a thumbnail.
Whoops, I forgot to save it. Let’s just do that again.
This past month I've been busy getting the Styles module ready for release. This module does the heavy lifting for display of Media objects. For those that don't know yet, Media, the File Browser to the Internet, is the future of media handling for Drupal 7. It exposes the underlying streams API of Drupal core, allowing for fieldable media entities (fields on files), mixing up images and audio, local files and YouTube.
Basically, the Styles module allows you to select a style for display with a field (or in a View or with WYSIWYG), and the field will be displayed as determined by the predetermined criteria. For instance, as shown in the above diagram, you might set the display as 'Medium', and the actual displayed file or remote stream will be selected according to the file's mime type (as an image, a video, in an mp3 player, etc).
As KarenSpredicted, there have been many Drupal-free nights from me this summer, while my household adjusts to its newest member. Though thanks to Advomatic, my days have continued to be filled with Drupal.
For instance, I've been hard at work on Node Reference / Embed Media Browser (nrembrowser), the perhaps unfortunately named, but descriptive, module that does just what it says. I did a session for it in an earlier incarnation at Drupal Dojo, and have banged at it incessantly, until it's now just about ready for prime time! As I said in the session, that project is, I believe, a reasonable alternative for folks who want Media-like functionality for Drupal 6.
What makes it viable is its integration with WYSIWYG and Styles. Styles is a brainstorm I had during the development of Media, in which I tackled how to display wildly differing data (such as photos and videos) with a single field formatter. I've been refining the model in version 2 of the Drupal 6 version, where I've moved it into a class structure and made lots of improvements. Coming soon to Drupal 7...
And then there's Views Slideshow: Galleria, which makes it easy to create a Galleria slideshow in Drupal. And some refactoring of Embedded Media Field, version 3, in which we begin the migration to Drupal 7's Media, and bring some of its magic (of a unified storage system) back to 6...
But what I've been dying to tell you all is about my few, but precious, Drupal nights. Though it's gone from 12 hours or more a week to three, in the wee hours of the morning at that, I've still been banging away. However, I've changed directions entirely, following another passion of mine: games! And no, not playing them, making them... I've said too much already, as it's not quite ready for release. But suffice to say, I think it'll be fun, and of course, it'll be available through the good ol' GPL...
I'm actually posting this as a question. If you're looking for the answer, sorry I don't have it yet.
How can we reasonably handle large file uploads? I'm talking in the >100MB range; YouTube, for instance, now supports 2GB files, and this will become increasingly the norm. I don't think that most servers are up to that yet, particularly if you need an application to scale.
Currently, using PHP, you need to set memory_limit to more than twice the upload_max_filesize, which as you can see would be prohibitive in the example of 2GB uploads; you'd need to set your PHP memory to >4GB (adding the buffer of 64M or whatever you need to run Drupal). EDIT: Looks like I was incorrect in my assumption; if you're not going to process the file, you don't need a huge memory footprint just to handle the raw uploads. Thanks Nate and Jamie!
Even if you manage to have that kind of resource available, you can probably expect things to splode with concurrent uploads...
So I spent some time yesterday looking at SWFUpload yesterday (module here), as I'd misunderstood its claims. Yes, it handles large file uploads (from the browser's standpoint), but you still need to set PHP memory accordingly. Not suitable for what I'm looking for, but it is a really nice way to handle multiple uploads. WARNING: I also learned from experience and much head-scratching that it doesn't work if you have Apache authentication on your server...
Sorry if you came to this post looking for answers; I've simply postulated more questions. But I'm hoping that someone with more experience with this issue might be able to comment, and we'll all benefit from it. Additionally, this might turn out to be a handy addition to the Media suite, perhaps as a fancy stream wrapper for handling large files? And I'll definitely follow-up when I figure out how best to tackle this.
If you haven't looked recently, there's been some huge progress recently for Drupal's Media module. Jacob Singh from Acquia has jumped on board, paving the way for fieldable entities! This allows Media asset objects to be a first class Drupal citizen, alongside Nodes, Users, Taxonomy, and Comments. (Hopefully in core for Drupal 8!) Also, Dipen Chaudhary has been hard at work providing WYSIWYG support!
I'm adding display formatters to the Media module, and could use some feedback.
Basically, I'm taking the work from the Image Styles built into core (which is a port of Imagecache), and building a wrapper around it. A Media Style would be a collection of styles, based on the stream (public://, private://, youtube://, etc) and file mimetype (image/jpeg, image/png, etc.), that would be applied to a specific filefield display (either in the node teaser/page display, or a view field display, or possibly other places, such as inline).
As an example, you might have a 'small-box' Media style that contains a 'medium' image style, a 'preview' youtube style, and an 'inline' pdf style. Thus, if the filefield contained an image, it would display it with the image scaling, a youtube video with a small player, and a pdf would be displayed in an iframe. Undefined streams/mimetypes would fall back to the default file listing.
The module is intended to work stand-alone, with File, Image, and/or Media. Thus, one question I have is if it should be bundled with the Media module, or packaged outside the module. On the one hand, as it can be run w/o Media, it might be useful in other situations. On the other hand, I imagine 98% of Media users would also want this module, so I'm hesitant to create a new external dependency. I've mostly decided to bundle it with the Media module, but am open to new considerations I haven't had yet.
I've included two screen shots. The first screen shot at the top shows current functionality. Clicking on a radio will automatically load a new preview of the selected style (that part's not built yet, but that's the idea).
I'm mostly looking for feedback of how the administrative UI could be improved, as well as how to word instructions to the user that won't scare them off. Also, for any other conceptual, architectural, or other comments.