HTML 5 and Drupal - Live Blogging from Drupal Camp NYC 8

HTML will bring lost of changes regarding the following areas: (taken directly from Dive into HTML 5)

  1. New semantic elements like <header>, <footer>, and <section>
  2. Canvas, a two-dimensional drawing surface that you can program with JavaScript
  3. Video that you can embed on your web pages without resorting to third-party plugins
  4. Geolocation, whereby visitors can choose to share their physical location with your web application
  5. Persistent local storage without resorting to third-party plugins
  6. Offline web applications that work even after network access is interrupted
  7. Improvements to HTML web forms
  8. Microdata, which lets you create your own vocabularies beyond HTML5 and extend your web pages with custom semantics

In regards to browser compatibility, here's the current state:

HTML5 Browser Compatibility

Beginning Drupal 7 - Live Blogging from Drupal Camp NYC 8

By Jacob Redding & Jennifer Lampton

What’s New: Overview

  • Admin Menu
  • Overlays (can be turned off)
  • FIelds
  • Image Styles (combines all the imagefield, imageapi etc.)
  • RDF
  • Theming Functions
  • New database layer (completely different abstraction layer, less direct DB queries). Goal: broader reach, including Oracle, MS SQL
     

What’s New: Details

  • Overlays for management and content creation functions: Never leave the actual page
  • Basic content type: Article, Basic Page. Article now has an image field included (which is part of core)
  • Tags are built in by default
  • Node attributes are styled better
  • Admin menu built (a version thereof). Can be extended with customizable shortcuts
  • Fields (CCK) built into core. Anything can be extended with additional fields, including comments, taxonomy, and users. BIG!
  • Media Configuration Section
    • Image Styles: formally image cache presets
    • File System: Possible to selectively choose a private file folder (D6 required either all files to be private or all files to be public)
  • New Themes: Bartik, Seven
  • Display of permission is smarter, e.g. admins inherit permissions from authenticated users
  • New options for case of deletion and what happens with related content. Choice can be given to the user.
  • User profiles can use global image styles (a.k.a. imagecache for users)
  • Users itself can use all fields (would use Content Profile for this in D6)
  • Drupal 7 has a module called Profile (which should not be used for new sites, as fields can be added to the user directly)
  • Modules can be installed through the Drupal interface (either through upload or direct tar archive). FTP/SSH not needed anymore.
  • Views not included, because of (technical) complexity of integration Views into core

Overall Impression

  • Look much more simplified and un-geekified
  • Easier descriptions targeted and Drupal novices
  • D7 will have a lot more distributions

Drupal Camp NYC 8: My first Drupal Camp and I can't wait!

This is the first time I am doing an intense 2-day Drupal training in Brooklyn, NYC: DrupalCamp NYC 8. I'm unsure about what to expect, but from looking at the schedule, it looks like an intense one, as there are only about 10 minutes of breaks between the sessions :)

I'm reviewing the sessions right now and here's my list of sessions I want to attend:

I can't list all the ones I like, because they are all grea, but I'm sure to post a quick update from this weekend.

Drupal Camp NYC 8 Logo

Flickr integrates with Facebook. Sort of. Ok, just a tiny bit.

I feel like I've been waiting for this integration for years. I'm a Flickr PRO user (haaagendazs), but haven't really used Flickr that much, since all my friends want to see my photos on Facebook, not Flickr.

We're not quite there yet.

As a starting point, Flickr now has an option to automatically push your photo uploads on Flickr to your Facebook news feed. That's great. However, the thumbnails in my Facebook news feed still link back to Flickr. The feature I'm expecting from Flickr is a feature that uploads my photos in the highest possible resolution to Flickr and then automatically uploads them to Facebook, so I can tag them there and allow my friends to comment on them. They surely won't create a separate account on Flickr.

So this integration is a bit disappointing, as it doesn't seem like Yahoo really thought this one through:

  • At first, Flickr created a new news feed entry for every photo that was uploaded. ReadWriteWeb reported about this annoying problem here: http://www.readwriteweb.com/archives/flickr_fixes_facebook_integration_w...
  • To link your account, there's an option in Flickr under the account tab (http://www.flickr.com/account/?tab=extend). Just activating the Facebook integration here led me to an error message that didn't tell me what happened. With some extra searching, I found out that I needed to activate the Facebook integration in the Yahoo Pulse settings. First, I didn't even know that I have a Yahoo Pulse account. Second, Yahoo Pulse seems to suffer from an inner struggle, because it can't decide if it should present information to me in German or English.
  • Most disappointingly: With this Flickr/Facebook integration active, I still need to upload photos to Facebook manually so my friends on Facebook can comment and rate. Thus, it looks like I'm uploading the same photos twice, which will look confusing for my friends (or make me seem very narcissistic).

After a couple of test uploads, I'm turning this feature back off.

Flickr Account Settings
Yahoo Pulse Settings

Behind the scenes: Star War's Yoda does TomTom's voice

After a long time of not posting anything, I decided to revive my blog. Facebook is great for talking to all my friends, but nobody gets anything tech-related. What better way to get back into blogging than a video :) You gotta love TomTom for coming up with a smart marketing move like this: Now, you can listen to Yoda and Darth Vader giving you directions on the road: http://starwars.tomtom.com.

Views Integration with your custom module and Overwriting Views Handlers

The module I'm using at least once a day is (what a surprise) Views. While the module is great and (after somewhat of a learning curve) pretty self-explanatory, I've always found it hard to find a good documentation about writing custom views handlers. The Views 2 API manual at http://views.doc.logrus.com has all the information, but is a bit too technical, even for my taste. So for myself, and everyone else trying to write their own custom views handler or just modify the functionality of an existing one, here is a very non-technical, concept-driven explanation of Views Handlers (forgive me, Earl).

Let's assume one writes a custom module that stores some information in its own database tables and fields. The Views documentation itself does a good job about what's required to expose the data of your own table into views. Successfully done so, you will be able to show your module's custom data using Views. Here's a real life example: I wrote a module that tries to mimic Facebook's Newsstream. The module tracks a specific action in the database every time a user uploads a new photo, creates a new comment etc. One of the fields that I store in the database is the uid of the person "doing the action". If I want to expose that field to views, I need to do a few things:

  1. Tell my module that I want to use Views to display data by implementing hook_views_api
  2. Define my table as a base table for Views
  3. Tell Views what to do with my database fields

1. Implement hook_views_api

This is a pretty simple step and documented well. In my case, the module is called socialfeed, so the implementation of hook_views_api looks as following:

/**
 *  Implementation of hook_views_api().
 */

function socialfeed_views_api() {
  return array(
    'api' => 2,
    'path' => drupal_get_path('module', 'socialfeed'),    
  );
}

2. Define my table as a base table

If I want to use the data from my table alone (meaning, not in combination with nodes or users), the easiest way is to define my custom database table as a base table for views. My table needs to have a unique identifier for that to happen (usually an auto_increment counter). Alternatively, I can join my data with another tables data (e.g. the user table). Here, I define my table as its own base table by implementing hook_views_data():

/**
 * Implementation of hook_views_data()
 */

function socialfeed_views_data() {
  $data = array();
  $data['socialfeed']['table'] = array(
    'group' => t("Social Feed"),
    'title' => t("Social Feed Stream"),
    'help' => t("Shows social stream items targeted at the current user."),
  );
  $data['socialfeed']['table']['base'] = array(
                'field' => 'sfid',
                'title' => 'Socialfeed Items',
                'help' => t("Social Feed items are generated through user activity."),
                'weight' => 10,
  );
}

3. Tell Views what to do with my data: Define the Views Handlers

If you've used the Views module before, you're familiar with the different ways to use data. Basically, there are 5 different groups for database fields: Fields, Sorting, Filters, Arguments & Relationships. For any of those five groups, Views needs to know what to do with the data coming from each database field. Here's the kicker: The handler's functionality has to be different depending on where it is used (this makes total sense, but took me a bit to get my head around). If I use the field "actor" (representing a uid) in the "Fields" list, I'm most likely just displaying it. If I use it in "Sorting", I'm using the uid to filter down the results. I'm using the same field, but Views needs to handle it differently. This should make sense to any Views user: When I show a "uid" field in the Fields list, I have the option to select things such as "Link this field to its user". If I use a "uid" field in Sorting, I can use things such as "Filter this view to the logged in uid". Exactly that functionality is defined by Views Handlers.

For this example, let's talk about the easiest view handler: views_handler_field. This handler displays information in the "Fields" section for view and is the most general handler for the "Fields" section. Views itself provides a number of more customized field handlers that extend (!!) the functionality of views_handler_field. Here's the direct link to the documentation: http://views.doc.logrus.com/classviews__handler__field.html.

Back to our module example (a newsstream called "socialfeed"). In order to expose the "actor" field from my database table "socialfeed", I use the following construct (to be placed within the implementation of hook_views_data):

$data['socialfeed']['actor'] = array(
  'title' => t('Actor User'),
  'help' => t('User that created the action.'),
  'field' => array(
    'handler' => 'views_handler_field',
  ),
  'filter' => array(
    'handler' => 'views_handler_filter_user_current',
    'type' => 'yes-no',
  ),
);

Let's explain this step-by-step:
The field I'm defining is called "actor", and it's stored in the "socialfeed" table. The title for this field in the Views UI is going to be "Actor User", the description will be "User that created the action". In the "Fields" section of Views, I want this field to be displayed using the views_handler_field, in the "Filter" section of Views, I want to use the views_handler_filter_user_current handler with a Yes/No selection. You might ask yourself the question: How should I know which handler to use? In general, you could start with the most generic one. If you know another module that exposes its data to Views, you could take a look at their Views implementation and use the same handler. Alternatively, you can look at the name of the handler itself (which is pretty self-explanatory), at the source code of the handlers (all the handlers that come with Views itself are located in sites/all/modules/views/handlers) or you could read the documentation at http://views.doc.logrus.com.

After you're done with all these steps with your own module, you should be able to use your module's data just like the data of any other modules that integrates with Views. And that means you can use all the sweetness that comes with the Views module itself.

 

Overwriting Views Handler Functionality

For everyone who's not overwhelmed with the information so far, here's the icing on my cake: What should you do if you don't like the way Views handles the data (meaning, the Views handler doesn't do what you want it to do). For most cases, this won't happen, but it actually happened to me, so here's an easy-to-follow example.

In an earlier version of the Socialfeed module, I was storing HTML text in the database,for performance reasons :-) Anyways, I got Views to display that data as text, but the HTMl was escaped, and for my case, it should have been unescaped. After a lot of back-and-forth, I decided to modify the behavior of the handler I was using (views_handler_field).

Of course, there's a hook for that: hook_views_handlers. Here's how the implementation for this case looked:

/**
 * Implementation of hook_views_handlers().
 */

function socialfeed_views_handlers() {
  return array(
  'info' => array(
    'path' => drupal_get_path('module', 'socialfeed'),
    ),
  'handlers' => array(
    'socialfeed_message_views_handler_field' => array(
     'parent' => 'views_handler_field',
     ),        
    ),
  );
}

The first few lines are just basic setup, the definition of "handlers" is where it gets interesting: I'm defining my own handler called "socialfeed_message_views_handler_field", which extends the functionality of the handler called "views_handler_field". The name of my handler is pretty much custom, but in this case, I usually try to use this structure: databaseName_fieldName_originalViewsHandler. In order to define this handler, you need to create a new file (in the same folder) called socialfeed_message_views_handler_field.inc (the name of the handler). In that field, we can go ahead and define the functionality we want to change.

Coming back to my example, I had to find out why the HTML in the data was escaped. To find that, I had to look into views_handler_field.inc and found the culprit in a function called render that returned the text after using Drupal's check_plain function. Here's the original function:

function render($values) {
  $value = $values->{$this->field_alias};
  return check_plain($value);
}

To overwrite that function, you need to know a little bit of object-oriented PHP, as Views uses objects and classes. The contents of socialfeed_message_views_handler_field look as following (and that's literally the whole file):

<?php
class socialfeed_message_views_handler_field extends views_handler_field {
  function render($values) {
    $value = $values->{$this->field_alias};
    return $value;
  }
}


The difference to the original function is quite obvious and programming-wise not so hard. However, the process of creating a custom handler to overwrite the functionality of the original handler wasn't quite clear to me after reading the Views documentation, hence I decided to write a blog post (mostly, so I'll remember the next time I have to do this).

Drupal 5 Views Recipes

I recently finished reading the book "Drupal 5 Views Recipies", the first book about one of Drupal's most relevant modules: Views. Here's my  summary.

At first glance, Views' module page looks like any other page on Drupal.org. Only the high number of commits and comments reveal that this is the module that enables site administrators to use Drupal as a Swiss army knife for content display. In a nutshell: Views is a query-builder with an administrative interface that gives site admins the ability to create almost any possible list of content without having to write the SQL query themselves. From my own experience working with Views, I remember the early challenges I had with this module. The user interface is a monster, not because it is poorly designed, but simply because of the large amounts of settings necessary to give an admin the flexibility she needs. Almost any setting produces some result, but it takes a lot of knowledge to configure a view correctly.

One of the main reasons I was pleasantly surprised about Drupal 5 Views Recipes was the fact that the book doesn't just give a laundry list of views (or recipes), but instead helps the reader understand Views from a conceptual perspective. Personally, I much prefer a book that explains a concept as it allows me to not just execute an example that's mentioned, but transfer my knowledge to my individual requirements.

This book delivers a great overview about Views without being overwhelming and starts out with a very simple view that gets fully dissected and explained. It then moves on to explaining working with default views (which come shipped with the Views module) as a basis for a site's custom views. Views learning curve is especially steep when trying to use taxonomy terms. Drupal 5 Views Recipies describes all the GOTCHA's and ways to get around them, such as an excellent description on displaying all terms from a specific taxonomy and using Drupal's "l" function to create the related links.

Views' right hand (well, they're pretty much equal partners) is the Content Construction Kit, or CCK, which allows the definition of custom fields for content types. Drupal 5 Views Recipes explains very well how to combine the two modules effortlessly and create views such as a blogroll, using the CCK link field. Another rather complex module is CCK's Node Reference field, which requires the usage of arguments in Views. Again, the best way to conceptually understand the interaction between the two is a simple example, exactly as the one used by the author. Furhermore, the book explains how to use dates in Views. Both the Date module itself as well as large number of other module gems are explained in the book, such as setting up a calendar block, visually showing aggregated data using the Timeline module and the setup of a summary view, which can be used for things like "blog posts per month", aggregating the number of posts in a given month.

Since working with the Views module requires dealing with a lot of different aspects of Drupal (content types, users, taxonomy, many different types of CCK fields), I was excited to get much more than just information about Views out of this book. Drupal 5 Views Recipes contains a lot of the "bread & butter" developer knowledge required for every Drupal admin, ranging from dealing with Firebug, how to work with cron and some basic understanding of the UNIX command line. Theming of views results is also mentioned in the book, although it only touches the surface. Also, this are of the book is not applicable to Drupal 6 / Views 2, as theming is the one area that radically changed in Views 2.

Overall, I can highly recommend this book to any Drupal administrator looking to begin working with Views or trying to become a Views expert. I was somewhat sceptical about the fact that this book focuses on Views 1 / Drupal 5 only. Conceptually however, there are no big differences between Views 1 and 2, so I would also recommend this book for Views 2 beginners using Drupal 6. I my view, the documentation that comes with Views is very brief and technical, and I am excited that the author succeeded in explaining the concept of Views in a structured and easy-to-comprehend way. I'll be the first to buy the second edition with an update to Views 2.

The book can be purchased at the Packt Website or Amazon.

Views Breadcrumbs using Arguments

For most of my clients, I need to create Breadcrumbs. Seemingly easily, breadbrumbs is an area that is a bit more involved than most features in Drupal. There's a great module out there called custom_breadcrumbs. The module works great for the display of breadcrumbs on all node pages, but doesn't (yet) work with views.

After doing some research about a solution for view pages, here's my favorite pick: Views Arguments.

For a simple overview page (that uses views), add a "Global: Null" Argument. Within that argument, select "Provide default argument" and select "PHP Code". In here, you can use the drupal_set_breadcrumb function. That function accepts an array of link titles and paths. Here's an example:

$breadcrumb[] = l('Home', null);
$breadcrumb[] .= l('Is The Box Butler For Me?', 'use-cases');
drupal_set_breadcrumb($breadcrumb);

To make this work, it's important to select "Display All Values" for "Action to take if argument does not validate", otherwise the view gets messed up.

To be on the safe side, I've attached a screenshot of the arguments code for this (live) example: http://theboxbutler.com/use-cases.

Views Breadcrumbs using Arguments

Swabians & The Amazon Kindle 2

The pre-release of the Amazon Kindle 2 got me excited! The Kindle (2) is, basically, a replacement for books printed on paper. Personally, I love the idea of reading books on a digital device, but after looking at my computer screen for 10 hours per day, my eyes hurt. The advantage of electronic paper devices like the Kindle 2 is that unlike a conventional display, which uses a backlight to illuminate the scree, electronic paper mimics the properties of ordinary paper. This means they reflect the light just like an ordinary paper and can even hold text indefinitely without needing electricity (of course, you will need power to see the next page). A neat feature: you can download books (and newspaper content) over the air.

Anyways: So I found this image on Crunchgear, which has a leaked image of the Kindle 2 (which is supposed to launch in late February) and was starting to the the text display: it has the headline "The Swabian" and basically talks about a not-so-smart Swabian guy who has a speech impediment. Really? Amazon, you really couldn't find another text example for this picture?

Of course, I'm Swabian myself. And a proud one too. My favorite advertising campaign of the past couple of years was a campaign by and about Baden-Württemberg entitled: "We can do everything, except speak proper German". And Amazon, just for the record, that includes helping Newton with the theory of universal gravitation, inventing the first modern carl and the diesel engine, founding Universal Studios and, of course, doing wicked-awesome movies like "Independence Day".

I think I'll get the Kindle after all.

Kindle 2

We're all conntected - By a 3inch wire at the bottom of the ocean

I always thought that most of the bits and bytes flying around the world would be transmitted through satellites, but I'm sadly mistaken.

The vast majority of the worlds communication is carried by cables in the ocean. The first cable was the TAT-1, which connected North America with Europe in 1958 with a capacity of 640000 bytes per second. Until today, that bandwidth grew to an amazing 7.1 terabytes per second. One terabyte is 1 099 511 627 776 bytes. So..a lot!

Interestingly enough, there are incidents where ships or landslides under the ocean cut one of the cables. In 2006, a landslide disabled Internet access in Taiwan for weeks. Now THAT would be a big problem for me.

We're all conntected - By a 3inch wire at the bottom of the ocean