Picking the best theme for Drupal 7

Just like everyone else these days, I am jumping on the Drupal 7 bandwagon for my newer projects. And every time, I come across the question which theme to use. By default, I gravitate towards Zen. I know it inside out, it is still the most-used theme across all Drupal sites and it just seems like the right way to go. I'm not a big fan of splitting up my css into tens of stylesheets, but I can go with the flow.

Then there is Fusion, which is "a simplified 960px" grid theme and #2 on Drupal.org. As a developer, I often come across these red flags that should be slightly orange ones at best, but I just can't stop including them into my decision making process. With Fusion, that would be the fact that it is a theme by "Top Notch Themes". Nothing wrong with that company, but it's just that: there's a company behind it that sells most of their other themes. Other than that, it seems to be a perfectly fine theme.

And then there is the new kid on the block: Omega. With a cool name like that, how could you say no (even cooler: the core and starterkit themes are called Alpha and Omega => geek points for that!). Something that I need for my projects is to have most of the configuration to live in the code, not the database, for a lot of reasons other than "versionability". And from some developer friends, I've heard that Omega's configuration lives mostly in the database. That being said: the usage statistics for Drupal 7 are crazy good: http://drupal.org/project/usage/omega.

The theme package with the fanciest HTML 5 logo is AdaptiveTheme and its numerous sub-themes and sub-themes thereof.

Enough said, let's get to the trial & switch-to-another-theme part :)

Just like everyone else these days, I am jumping on the Drupal 7 bandwagon for my newer projects. And every time, I come across the question which theme to use. By default, I gravitate towards Zen (http://drupal.org/project/zen). I know it inside out, it is still the most-used theme across all Drupal sites and it just seems like the right way to go. I'm not a big fan of splitting up my css into tens of stylesheets, but I can go with the flow.
 
Then there is Fusion (http://drupal.org/project/fusion), which is "a simplified 960px" grid theme and #2 on Drupal.org. As a developer, I often come across these red flags that should be slightly orange ones at best, but I just can't stop including them into my decision making process. With Fusion, that would be the fact that it is a theme by "Top Notch Themes". Nothing wrong with that company, but it's just that: there's a company behind it that sells most of their other themes. Other than that, it seems to be a perfectly fine theme.
 
And then there is the new kid on the block: Omega (http://drupal.org/project/omega). With a cool name like that, how could you say no (even cooler: the core and starterkit themes are called Alpha and Omega => geek points for that!). Something that I need for my projects is to have most of the configuration to live in the code, not the database, for a lot of reasons other than "versionability". And from some developer friends, I've heard that Omega's configuration lives mostly in the database. That being said: the usage statistics for Drupal 7 are crazy good: http://drupal.org/project/usage/omega.
 
The theme package with the fanciest HTML 5 logo is AdaptiveTheme (http://drupal.org/project/adaptivetheme) and its numerous sub-themes and sub-themes thereof.
 
Enough said, let's get to the trial & switch-to-another-theme part

Live Blogging from DrupalCon Chicago: JavaScript in Drupal 7

Presenters: Kat Bailey

Drush Make Demo File: katbailey.net/resources/d7js

New Ways to add JavaScript in D7:

  1. Add it in the .info (within a module, not just the theme)
  2. drupal_add_js: Function changed a bit since D6, allows additional of external JavaScript
  3. Add it in a Render API: Using the 'attached' property

Altering JavaScript in D7:

hook_js_alter allows coders to change any JavaScript file

JavaScript Libraries

  • hook_library: Defines your JavaScript library
  • hook_library_alter: Alter an existing library

Live Blogging from DrupalCon Chicago: Aphorisms of API Design

Presenter: Larry Garfield

  • A good example: noad_load_multiple: Wrapper by node_load in Drupal 7: It doesn't make a difference if you're loading 1 nore or 100 node
  • A not so good example: Search API. Only allows to search for one entity at one (i.e. the module doesn't allow the user to search for users and nodes)
  • Good APIs are picky: Instead of returning nothing / NULL, good APIs return exact error message (think of the "Invalid parameters supplied on line 2933 somewhere in forms.include"
  • In you rown module: don't use undocumented APIs and don't hardcode code that shouldn't be
  • A UI is not an API
  • A website is also not an API: An API does not need a website
  • 3 implementations should be required: 1. Simpletest. 2. Drush. 3. Webform

Live Blogging from DrupalCon Chicago: Media in Drupal 7

Presenter: Jacob Singh

  • Drupal 7 offers the new Media module, which replaces all the different media modules from before
  • Media attempts to be a "file browser to the Internet". Modules can plugin to the Media module (e.g. YouTube, Flickr etc.)
  • Main advantage of Media is that the interface and API is consistent
  • Media has security advantages that allows anyone to embed images and video that circumvents the issues of malicious tags in media files
  • The Media (module) attempts to be the default file-management tool in Drupal 8

DrupalCon Chicago

I'm at my first DrupalCon in Chicago. Yeah. Compared to the Drupal Camp in New York, this seems HUGE. If I actually used Twitter, I should have poster this there. But hey.
DrupalCon Chicago

New Drupal Module: Privatemsg Bulkmail

One of my favorite modules for Drupal is the Privatemsg module. It's basically the Drupal version of Gmail, including a huge feature set for (almost) any need. For one of my clients, I needed to create a feature set that allows him to send internal notifications. Although the newest version of the Privatemsg module comes with the feature to send messages to specific user groups (in Drupal talk: roles), that feature didn't quite fit the required needs, so I decided to write a contrib module with a larger feature-set: Privatemsg Bulkmail.

The Privatemsg Bulkmail module is intended for site administrators who want to send out an identical private message to a large user base (100.000 users and more). An example use case would be an internal notification to all registered users through a private message.

Here's the description of the feature set:

  • Send out private messages from a specific user (instead of the current user)
  • Define a dedicated bulk message user and prevent that user from logging in (to prevent performance issues)
  • Prevent users from responding to a bulk mail message
  • Include AND exclude recipient group of a bulk mail. Example: Send out a bulk mail to all authenticated users that are not site admins
  • Restrict the recipient group to users who logged in or signed up after a certain date
  • Send an individual test message to a specified user before sending out the bulk mail

If you have a use case for this module, try out Privatemsg Bulkmail and leave some feedback on the issue page.

New Drupal 7 Book: Drupal 7 Module Development

January 7th 2011 was a happy day for all Drupal fans: Drupal 7 got officially released. The two Drupal books that I used to get over the steep learning curve of Drupal 6 module development, Drupal 6 Module Development by Packt Publishing and Pro Drupal Development by Apress, got released for Drupal 7.

While the later is the definite development reference for Drupal, the former was written in a more approchable way. The Drupal 6 version of the book included lots of real-life module examples that made becoming acquainted with Drupal's API function a fun way to learning module development for Drupal. I can't wait to work myself through the updated version, "Drupal 7 Module Development", and will post a detailed review of the book thereafter.

Book Cover

New Drupal Module: Views Search

A feature request for one of my recent projects was an "Advanced Search" functionality, similar to the ones that is commonly found in social networking and personal sites. Rather than creating a completely custom search form using Drupal's Forms API, I decided to create a module called "Views Search" which uses the Views module and allows anyone to create advanced searches for anything Views can process without custom coding.

Views' exposed filter work very similar to the search functionality, however exposed filters in the Views module work like true filters, where a list of nodes is limited down to the intended results using a combination of several filters. In contrast to this approach, a more traditional search form allows users to define all criteria first (before seeing any results) and then click on a "Search" button to see the results. This module allows site administrators to easily use the behavior of a traditional search for selected views.

In addition, the Views Search module allows Drupal site members to save their searches for future usage.

Here's an overview of the feature set:

  • Separates the search form and results: selected views show a search form without showing the results on the first page and the search results without showing the search form/filters on the following pages
  • Allows users to start over with a search (using a button on search results page)
  • Allows users to modify the search criteria (using a button on the search results page that expands search criteria using jQuery)
  • Allows users to save a set of search criteria for later usage
  • Allows users to modify/overwrite the name and search criteria for a saved search
  • Provides a default view that allows the current user to manage saved searches
  • Provides a block showing a drop-down with saved searches for the current user
  • Enables site administrators to select views that should act like "search views"
  • Enables site administrators to limit the number of saved searches for certain user roles & set saved search limits per rule
  • Enables site administrators to batch-delete all saved searches for a specific view

You can download the module from the Views Search Module page on Drupal.org. I'm looking forward to any feedback.

Comparison of Views Exposed Filter and Views Search

Drupal.org Redesign Imminent

Personally, I'm excited about the upcoming Drupal.org redesign. Not because I think that there is anything wrong with the old design or information architecture - I actually grew to love it. No: I'm mostly excited about the Drupal redesign because I think it will help to push Drupal out of the developer corner and make more people "like" Drupal because of a new design that looks less like a website for geeks only (again: I'm a proud one myself).

Currently, there are some small efforts to make the soon-to-be old Drupal.org look more friendly, but it seems clear to me that a major redesign was needed to communicate the following statement clearly and to the point: Drupal is the most powerful CMS out there.

In my earlier days as a developer, people unsuccessfully attempted to convince me of the power of "Ruby on Rails". It wasn't until I started working with Drupal that I found that promised power and ease-of-use, from a developer's perspective, of course. And that's the one thing that the current Drupal.org design is not communicating clearly: How powerful Drupal is, how many large organization love it, use it or want to start using it as soon as possible.

In the new design, I too miss the Druplicon looking at me from the top left corner. But I hear Larry in his blog post about the difference between the Druplicon and a logo, and it makes sense to me. One comment in the request to beta-test the new design concerned a lack of character in the new design. While I agree that the new design looks clean but a bit generic, I don't think the old design had a lot of character because of the visual look of the site itself. The character was coming from the personal involvement of the people using it, and that aspect will continue with the new design

I do think that developers using the Drupal.org issue system will need to adjust to the new look. However, while we will get used to the new look very quickly, Drupal newbies will be much more willing to dive into the beauty of Drupal because of the look of the new website.

Great job!

The new look of Drupal.org: Cleaner and simplified.
The old look of Drupal.org

SEO Module Alternative to Nodewords for Drupal Developers

After listening to Seth Cohn's very inspirational speech about the Context module at the DrupalCamp NYC 8, I got inspired to play around with that module a bit more. Primarily, Context serves as alternative way for the block administration. However, Seth focused more on Context's ability to keep variables during a page load available, without the need to use global variables or other workarounds.

One of my recent projects required very specialized SEO optimiziation. Initially, I started using the Nodewords module, which is brilliant and very easy to use. In certain areas however, I felt that Nodewords makes it harder for me as a developer to achieve my goals, so I wanted to come up with a different approach. By no means is this module supposed to be a replacement for Nodewords, it's more of an exploration of the Context module.

Search Engine Optimization for drupal module developers

In this example, I'm primarily focusing on the head title (the title that appears in the browser for any open window) and the meta description (which will show up as a teaser in search results).

I've identified three different "types" or areas that often require specialized SEO optimization. These are:

  1. Nodes (per content type)
  2. Pages (created by other custom Drupal modules)
  3. Views Pages (created by the Views module)

SEO Head: A centralized module that handles head title and meta description

If you're developing in a similar way as I am, you like to create smaller modules for each distinct functionality. In my approach for this alternative module, I am using a central module called SEO Head, which works as the central module to set the head title and meta description. This module is called at end of the page execution process by using a relatively high system weight of '200' (the default being 0). By calling this module at the end, I am trying to make sure that no other module sets the head title. This module overrides the existing head title and sets the meta description.

Looking at the above list, only one of the areas is defined within the module: Nodes, per content type. By the time the SEO Head module gets called, the full node object is available, so anything (including CCK fields) can be used for the page title or meta description. See lines 17 to 35 in the source code.

In this example implementation of the SEO Head module, I am using a special text CCK field for the page title of a node of the type 'page' (see the file attachments below, you can install this field easily by downloading the node_page_title module, which is a Features module.). For the regular "story" node type, the body of the story is used for the meta description. These two instances are just examples of what could be done here.

Using Context: Define head title and meta description in your custom module

Instead of defining all page titles and meta descriptions in one central place, I thought it would be much 'nicer' to have each custom module you create for your site define their page titles and meta descriptions, if needed. In order to make this happen, I am using the Context module as a vehicle to transport any head titles and meta descriptions to the SEO Head module. This allows any module to set these values 'remotely', meaning directly in the module. To demonstrate this, I created a separate example module called 'example', see download list below. The Example module provides a page and a simple view.

For any page defined in a module, just use the context_set function (line 13 and 14 in the example module) to set head title and/or meta description, and the SEO Head title will take care of the rest.

To define head title and meta description for Views (which is currently not possible with Nodewords), you can make use of the hook_views_pre_execute hook (line 23 following).

 

Again, these modules are just some examples for using Context in a creative way, and aren't meant to replace the Nodewords example in any way. I'm looking forward to some interesting discussions.

File: