Drupal

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 :)

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

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.

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!

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:

• Beginning Drupal 7
• HTML5 and Drupal
• Drush - Intro or What is it good for?
• Drupal as a web services platform for building Android, iPhone and other platforms' applications
• Drupal 7 Module Development
• rules, the next big thing in drupal
• Context - changing how I code Drupal
• Views for Module Developers
• Making Search Usable: Apache Solr and Faceted Search UI Challenges

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.

One of the things that I love about Facebook is the fact that all my online activities show up as part of my "Facebook Status Updates". Wouldn't it be great to have all those updates available in Drupal? I recently came across a module called "Activity Stream", which offers a Drupal aggregator pulling in updates from Delicious, Digg, Flickr, Last.FM and Twitter. Besides the big 5, it also offers a custom feed option that I haven't tested yet.

Installation of this module was really simple. This module comes with a core package and 6 sub-modules, one for each service (and custom feed). According to the Activity Stream online documentation, those modules can be easily extended in case you're looking to display items from a different service than the one already provided.

The display of feed items looks decent from the get-go. My visual design preference is more organized, so I applied the following style tweaks to the get the items to show up as displayed in the image below. You can just add these lines to your style.css file of your theme:

It seemed strange to me that there isn't a better solution, so I found the Weblinks module (http://drupal.org/project/weblinks), which does exactly what I'm looking for: it allows an admin or user to create Blogrolls (= several list of links). Those lists can be put into categories, such as "Design Links" or "Programming Resources".

What I liked about the module was the fact that it seems seamlessly integrated with the core Drupal modules. It's using the Taxonomy module for categories and has a straightforward installation. The module creates the Vocabulary automatically (after visiting the configuration page once). Any categories can be created through the Taxonomy module. Weblinks comes with three different css files; I chose the weblinks_minimal.css, as my goal was to integrate the module's output into my sidebar.
Another part of the module that's great is the views integration. Using Drupal 6, Views and Weblinks, it's easy to create a page with the most popular links based on user click-throughs (which comes as a predefined block for the sidebar, but the fact that it CAN be easily re-created using views was noteworthy).

One feature that I was missing was an OPLM importer to take all the items from my existing feed reader and import them easily into Drupal, without having to copy & paste every website manually. Apart from that, I think I'll use this module from now on instead of creating custom blogrolls, as it seems to be maintained very well and updated often.