forms API

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

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.

A Brief Overview of the Future of Drupal: Short Term and Long Term

Last summer, nearly every client that I talked with who wanted a CMS would ask for Mambo. This was in spite of Drupal's obvious superiority in terms of code, flexibility, and power.

I was forced to conclude that Drupal's biggest weakness was the first impression it was making. I spent about 2 minutes looking at drupal.org, and Mambo's homepage, and the cause of Drupal's weak first impression was dead obvious:

Generally, "Power in Simplicity" makes a better first impression than "Community plumbing".

Hardly an Earth shattering observation. You could ask a 5 year old which slogan is better, but they'll probably be laughing too hard at the implications of "community plumbing" to answer the question with words.

Today, I can't remember the last time anyone mentioned Mambo to me. So, 9 months after I wrote that article, I am going to go out on a limb and say it: Drupal, as a platform and community, won. We've left the competition in the dust. (and funnily enough, those who make up the competition seem blissfully unaware of the fact).

We won in spite of the fact that we still advertise the idea of plumbing together as a community; its clear the drupal community is not plumbing anymore; we're kicking serious ass. The number of users, and nodes at drupal.org as DOUBLED since I wrote that article. In one year, it was estimated (somewhere, Zack Rosen mentioned this) that the overall economy of drupal increased by 10 fold. And don't even get me started about what the forms API, CCK, Views, Relationships, CiviCRM, OG, blah blah blah ... let's talk about something else:

The Imminent Release of Drupal 4.7.0 is only the Beginning

So, where is drupal going to be in another 9 months? We probably won't have made it to the cover of Time magazine... yet... However, based on my conversations with Adrian (for all practical purposes the inventor of PHP-template and Forms API), here are just a few things that the future of drupal holds:

Syndicate content