Here's a two-step formula for simple inline video, assuming you have jQuery Media installed on your site, doing both of these configuration steps from Administration > Site configuration > jQuery Media (at /admin/settings/jquery_media):
Open the Node types field set and check the node type for which you wish inline video.
Open the Classes field set, and enter .node .content a in the Media class text field. (You can separate classes by comma if you want to keep existing class invocations.)
Then just add a link to a video inline to your content. Doesn't matter if it was uploaded with the node or through FTP. (The second step assumes you're using the Garland theme, or another theme that uses that CSS class designation. You might need to check the node in FireBug if you're not sure.)
Notes: This method is easy, though admittedly a bit heavy-handed. The down-side is it will be invoked regardless of whether the node actually contains a video link (fortunately it's a lightweight jQuery plugin). If you want more fine-tuned control, you can skip the first step, use a PHP filter, and just invoke it manually from in your node, using jq_add('jquery_media') (assuming you have the jQ module enabled; jquery_media_add(); otherwise). (I don't actually recommend that, because of all the security issues involved. Just stick with the first method.)
The cool thing is this will work with pretty much any media player, including the upcoming Media Player for Drupal!
Don't get me wrong; I like Garland. It's sleek, it has an easy-to-configure color scheme, it works well out of the box. And it's identifiably Drupal, which, though sometimes thought to be a criticism, is not a bad label for the blog of a Drupal developer, such as the blog you're reading.
At the same time, I'm interested in spending some time creating a unique theme for my blog. I develop eight-plus hours a day, and it's time I eat my own dog-food. Granted, I haven't actually done any design work in over three years, but I do have some background with that.
So I've been looking at some of my favorite blogs to get some ideas. And discovering an interesting trend.
Chx's Drupal4hu is simple, with little clutter on the screen, but very identifiably Drupal oriented.
Jame's Walker's walkah.net features his most recent blog post, with a listing of the next few post titles beneath, and again, little clutter.
Then there's Neil Drumm's Delocalized Ham, which evokes a manuscript on paper. His design is a testament to his recent study of Typography, which will also figure into my future directions.
So I'm not entirely sure what I'll do for a design quite yet. But I believe that these simple blog designs highlight the most important element of a blog, the written word.
I was recently asked my opinion of whether to use Drupal or one of those other ones. I was going to just write a flippant reply, when I realized I'm not actually qualified to answer the question.
I have never personally used WordPress. I read a comparison of it and Drupal some years ago, and knew even then that WordPress would just never cut it. And I've never looked back.
Now if Joomla had been part of the original question, I would have had slightly more qualifications to answer. I used that once (back when it was Mambo, and for all of three weeks), and was sorely impressed at first. But the glow faded quickly when I realized that though it was slick out of the box, it required more work tearing it down to make it do what I wanted than Drupal's simple building blocks offer. And again, I've never looked back.
However, that's coming from a decade of experience on the web beforehand. I really have no idea if Drupal is suitable for someone just starting out. (That is more generic: the author of the original question is a seasoned developer, and specifically to them I say use Drupal, what are you waiting for?)
I found a few comparisons of Joomla and Drupal, but they're largely out-dated, the first on the list dating from Drupal 4.7. Most of the negative points on Drupal on their list have turned into strong positives since then. That was a thorough comparison, but needs to be revised to warrant its current Google ranking.
From a blog, to a news mogul, to a store-front, to a social network, to a university's portal site, Drupal can handle any of it. Just take a look at this slideshow:
With a strong community of developers, there are easy-to-use tools that can handle pretty much anything you can think of. Its underlying architecture is scalable, its API is robust, and Google loves Drupal; its SEO friendliness is well-known. (Although to be fair, as pointed out on Joomla's forums, they're all SEO friendly, and Wordpress does that out of the box, as opposed to needing to install Pathauto for search-engine-friendly URLs in Drupal.)
The rest of this is largely opinion. Please do the research yourself before coming back and telling me this other can do this or that. Without doing a thorough examination of the CMS options, it doesn't do any of them justice to oversimplify their offerings.
Basically, from my perspective, I'd say, if you are an experienced developer, particularly if you have any programming background at all, you need Drupal. If you are looking to hire a developer for your site, whatever site that might be, you need Drupal. If you are a newbie and want nothing more than a blog, then WordPress might be for you.
This was created with an hour of tweaking the OpenLaszlo XML, and then pasting the following into this node: print theme('media_player_player', 'http://spindowners.com/files.dm/videos/20051210-w50s.flv', array('logo' => '/sites/aaronwinborn.com/files/my-logo.png');
Couldn't be simpler! I see a dev release as soon as we have an icon for the play button!
Of course, playlists and the like will take more. We've talked about including several players, including a light-weight and one with all the bells & whistles, and have the module call the proper one according to passed parameters.
Obviously, it's still rough on the edges, and all the options in the theme function aren't hooked up yet. Although it works already (after a fashion), don't use it yet unless you're willing to suffer the consequences.
When it's done, this module will come with its own player, fully GPL'd, and will support others out of the box as well, such as JW Flash Media Player and Wimpy. But who's going to want those anymore?
The module adds theme functions and a simple API that should be easily usable by other media modules, such as Embedded Media Player, jQuery Media and whoever else wants to jump on board. The other modules won't need to worry about where a particular player lives or how to invoke it; the theme functions provided will be robust enough to handle player colors, sizes, icons (including placement, layout, and other customization options), splash screens, playlists and more. Administrators will be able to override any of the defaults, including player of choice. Additionally, it'll be easy enough to invoke manually as well:
print theme('media_player_player', $filepath);
And best of all, since it's in OpenLaszlo and GPL, with the source included in the module, it's easy for developers to modify even the player, without even needing a Flash IDE. (The whole thing is created with an XML.)
Kudos to EclipseGc for nudges and encouragement to get this project going!
Next on the list: volume controls, playlists, override color/logo/splash options, settings pages, pull in the other players, youtube/blip.tv/other provider support, tie into other media modules
So my brother in law (Erik Gecas) has an art exhibit, Painting Physical Presence, that's just opened in Las Vegas! Particularly exciting for me (though admittedly only slightly relevant to the world of Drupal) is that I created his web gallery a few months ago, with Drupal of course. The show is in tandem with Ayako Ono.
The web gallery is largely created with Views Slideshow (for which I still owe a port to d6). In fact, it was largely for this site, which makes a small appearance in Drupal Multimedia, that I beefed up development for that module (and the Magnifier module, that is also used on the site, though not in the book).
The Media Code Sprint has been a great success thus far! We have built a fairly comprehensive test suite for hook_file. It still needs to be rounded out, so that, for instance, all the cases for file saving are covered. However, validation is fleshed out, and the framework is pretty much usable and ready for testing gurus to go in and run it through its courses.
Jonathan Hedstrom (jhedstrom) of OpenSourcery joined us this morning, and created the FileDirectoryTest class, finding and fixing some flaws in the current file api in the process. His help was invaluable. And we all quashed other minor bugs and problems in the documentation, so it's been a most successful sprint thus far.
Tomorrow should prove to be productive as well. It's my last day in Portland before heading back east to Pennsylvania, so I plan to make it a great one. Thanks to Advomatic for sending me out to the media code sprint! It's great to work with a company that recognizes the value of Open Source, and reinvests in the community.
Drewish and I will be taking a break in the early afternoon to present a remote session for DrupalCamp Colorado on Drupal Multimedia, where we plan to talk about the state of the art and our recommendations for Drupal 6, as well as a brief overview of the successes of the Media Code Sprint, and what that means for the future of Drupal. See you there!
As announced, we've begun the Media Code Sprint to put better media handling into Drupal core!
It's been a great time so far. In the morning, drewish compiled a file function guessing game (free beer!), and andreiashu took the bait and completed the first round with great feedback about how unusable the current state is.
Next, we've sat down and begun writing SimpleTests for the hook_file patch. This has been great fun for me personally; though drewish is an old hand at building tests, this is completely new for me. And to top it off, webchick, Queen of Drupal testing, dropped by our table and got involved!
Even the process of writing tests has been helpful; we found at least one case for validation that had been missed in the original patch, and drewish decided that file_scan_directory needed refactoring. (He's currently chasing other problems as well, and cursing about finding himself going down rabbit holes.)
There's more fun to be had for all! If you want a quick 15 minute task that everyone is qualified to do, go play the File API Function Guessing Game. If you want to do more, then ping me (aaronwinborn), drewish, or dopry at #drupal in IRC, or leave a comment here!