Drupal Articles

Category Module: A Solution to Everything You Hate About Taxonomies and Books

I’ve been watching the category module since January. Today, I’m ready to make a rather controversial assertion: this module has rendered both the taxonomy, and book modules obsolete.

It goes without saying that when making a serious decision, such as going to war, or declaring the taxonomy module obsolete, one better have a reason. Here are just a few of my reasons:

  1. It converts the book module’s flacid, pseudo menu into something useful: a real menu. In other words, it enables you to create a global navigation scheme (menu trees, and breadcrumbs) that will expand in response to whatever node your users are currently viewing. Before, books were invalid mini-sites that were seperated from the great context of the menu tree. They were a bad solution that one had to make, because there wasn't an alternative. Let us join hands, and celebrate the passing of that dark age.
  2. The category module not only gives you the option of automatically generating a menu item for every node that you file under a certain category… it gives you the option to create an pseudo menu item – so you avoid cluttering your menu, but have the benefits of context in terms of breadcrumbs and menu trees. Some "experts" say that its important for your navigation to a) show the user where they are, b) show them where they can go, c) show them where they've been. It was very sad that this simple goal was so hard to achieve in the past. Well, it is no longer, thanks to the category module.
  3. Every “category”, and every “container” are nodes. And wait, this should be explained:Foreach (TAXONOMY) { category = term, container = vocabulary }Foreach (BOOK) { category = child, container = parent} Every container, and category have an RSS feed. And since they are nodes, they can be themed like any other node. This = presentational freedom that both taxonomy and book sorely lacked.
  4. Pathauto now has native category module support. In otherwords, I dare you to see what happens if you set every node’s default path to [menupath]/[title], and every category and container to [menupath]. What you will find is SEO, and URL heaven – never again will you need to scheme of ways to make URLs, breadcrumbs, and menus all agree.
  5. We all know that the views module allows you to differentiate between taxonomy, and node types (just nod along like you knew that…). In contrast, the category module has full fledge views support. I’ll say it again: you can extend the category module’s organizational freedom, with the universe of presentational, and conditional options of the views module. That makes me a very happy person.
  6. In general, the new concepts put forward by the category module offer superior freedom in terms of the way content relates, is displayed, is navigated, and can be consumed. For the first time, you can build a comprehensive organized sitemap, using the sitemenu module. Oh – and did I mention, it has a bulk editor that makes complete reorganizations of a site’s structure take LITERALLY 1/40th of the time they would take with book, or taxonomy modules. F@ck yeah!
  7. I will never have to explain what a taxonomy is again. I will never have to show someone the difference between vocabularies and terms. Even better, never again will I have to hypnotize some poor bloke into believing that the seperation between taxonomy/menus/book hierarchies is a sensible thing. Though, its worth noting that I've become a good hypnotist.

Learning How To Theme in Drupal, Starting at Square One

Note: I'm going to start regularly answering questions I get via email by blog. The reason being that email is a blackhole; and I am getting too many good questions everyday. When I have a few moments to answer, I figure I should make them available to everyone.

A reader by the name of Fouad writes:

How to create a block region for node.tpl.php

Update: appparently, today was the day to write about this. Nedjo Rogers submitted a handbook page that shows a different method of achieving the same end.

For the most part, Drupal 4.7's block system is underutilized. This is a shame; with the proper templating, drupal's block system can become a valuable workhorse. In this tutorial, you will learn:

  1. How to override default functions in the phptemplate.engine
  2. Create new regions to place blocks
  3. Pass a block region into node.tpl.php

By the end of this tutorial, you will have the ability to place blocks into node's like a so:

Quick and Clean CCK teasers Via PHPtemplate

If you are like me, you've been pulling your hair out trying to make teasers work in CCK. Well, as it so happens, I figured out a crazy simple phptemplate method of making CCK body fields act like any other node's body. Observe:

A CSS ID for Every Menu Item

As you can see, these menu links have unique icons. Yet another miracle accomplished using Drupal's PHPTemplate. This technique is especially cool because it automatically generates CSS ID's from the menu link's name.

TEMPLATE.PHP: Override theme_menu_item() (includes/menu.inc)

<?php function phptemplate_menu_item($mid, $children = '', $leaf = TRUE) { return _phptemplate_callback('menu_item', array( 'leaf' => $leaf, 'mid' => $mid, 'children' => $children )); } ?>

Now create a menu_item.tpl.php file.

Overriding Themeable Functions: The Where's, the Why's, and the How's

There's good news and bad news. First, the good news: overriding theme functions is easy. The bad news: every theme function is different, and there isn't a standard proceedure of going about it; if you don't know what you are doing, its quite easy to accidently do something ugly, or foolish.

So, in the next few tutorials, we are going to explore the hows, whys, why nots, and what ifs of overriding theme functions. Each of these functions will present a different set of challenges, and opprotunities to do something stupid, etc. Today's lesson is "Building a better node form". In this tutorial you will learn

Extreme Drupal Theming with PHPtemplate

Drupal's phptemplate is the most powerful, simple, and flexible templating/theming system on the planet*. Yet, it seems that the majority of drupal themers, (and wannabe drupal themers) are ignorant of its true power.

More disturbingly, vast numbers of people still insist that Joomla!, typo3, and wordpress's templating systems are easier, sexier, and slicker. These people are either loony, or wrong.

As an expert in PHPtemplate (isn't that scary), I've decided its my duty to show the true power of PHPtemplate to world.

Consider these tutorials, a proper (and steadily growing) introduction to drupal's templating system.

An Introduction: Dominating the User Login Form

In this first tutorial, you will learn how to:

  1. override the default presentation of the user login form, and create a custom template for it.
  2. pass an editable node into the user login form
  3. alter the form’s values (such as text, and instructions)
  4. make the form available to page.tpl.php — as though it was something as simple as a footer.

Moreover, I will show you how bloody simple it is. Folks who follow this tutorial should already have:

  1. knowledge of PHP
  2. the ability to lie about a lack of knowledge of PHP
  3. some familiarity of the kindergarden basics of drupal theming
  4. Be working with drupal 4.7+

Step One: Override the deafult user login form

Overriding is always done in the theme’s template.php file (if you don’t have a template.php file, you may create a it now). Obviously, before you can override anything, you must first locate what you are trying to override. The best way to do this is to search a module for the $form variable.

How Drupal Could Become Easy to Learn, Easy to Use

After some thought, I've come to the conclusion that Drupal's most significant usability problem is findability. Findability[1] is defined as:

a. The quality of being locatable or navigable. b. The degree to which a particular object is easy to discover or locate. c. The degree to which a system or environment supports navigation and retrieval.

The true seriousness of drupal's findability problem may not be immediately evident to expert drupal users. In addition, in various usability surveys, and studies, there is no immediate evidence of Drupal's findability problem.

Welcome to Anti-Usability Club

The more I think about it, the more I dislike the word "usability", and this abstract construct dubbed "the user".

This is not an entirely enviable stance for me to take. A brief search of my past writings will reveal that I've been downright promiscious in terms of discussing users, and their useiness. So why the change of heart?

Well, think about it:

  • have you ever thought to yourself "my, this website is insanely usable!".
  • Can you even remember the last time you uttered the word"usability" outside of a discussion about usability?
  • Have you ever heard a person who doesn't read web design blogs mention a site's "usability"?['1']

It seems to me that the word "usability" is much like the Tao: though one can speak of usability, the true, and eternal usability can only be nameless. If it had a name, than it would not be of the eternal usable nature.

Pages

Subscribe to Drupal Articles