Content type madness is a common disease that effects drupal sites of all sizes. It is most frequently seen in drupal 5 and 6 sites, as result of content construction kit.

It is a serious, chronic disease that can result in long term damage to a site's agility, usability , and information architecture.

Common symptoms of content type madness include:

1. More than 11 content type*
2. Dubious distinctions between content types [e.g. press release, vs. annoucement, vs. news item, vs. alert]
3. No use of drupal taxonomies
4. Overuse of views
5. Users of site reporting feelings of malaise, and depression after working with content on the site.

Frequent complications of content type madness include:

1. Improperly set content defaults, ranging from internationalization, to comment settings, to publishing workflow, to user permissions.
2. Presentation inconsistency due to the proliferation of node-[type].tpl.php files.
3. Switch statements that exceed 200 lines in the hook_preprocess_node(&$vars) function in the template.php file.

Treatment Options:

Treatment of content type madness is usually difficult,  time consuming, and often requires the services of drupal specialists. In severe cases, treatment requires a total redesign and refresh of content. If you have never attempted to treat content type madness, BACK UP THE DATABASE BEFORE YOU TRY.

Highlight: WYSIWYG API Gets Top Spot With 97% Growth (Feb 8th - March 29th)

Ever wondered which modules' userbase was growing fastest?

With a bit of simpleXML, 2 hours of boredom, and drupal.org's usage charts, I can provide an answer. Personally I thought the results were rather interesting.

This list only includes projects that got 6000 downloads or more last week. I picked 6000, because otherwise, ubercart wouldn't show up.

The phpdocs put it kind of weirdly:

PHP 5 comes with a complete reflection API that adds the ability to reverse-engineer classes, interfaces, functions and methods as well as extensions.

I prefer the notorious c.h.x.'s definition

chx: it's like this insane cool weaponset of PHP which is like totally unknown :)

Reflection is a very powerful too that lets you understand the code running in your enviroment. This is particularly important for drupal development, as so much of drupal is based on functions that call functions (e.g. hooks).

The point of this tutorial is to show you how much ass reflection can kick, in so little code. The following page finds out every menu item that calls a function hidden away in a remote file, and gives you the location of the callback function: filepath, and line number and all. Note that the vast majority of code is merely used to output the test table. Obviously, this example merely scratches the surface of useful things you could do with this api.

While building a product comparison website, I ran into a situation that required a view to sort using one of 2 possible price totals depending on a users profile: lets say "red state", "blue state". The goal was to open up the product comparison tables (order, fields, field names, and filtering questions and all), as well as the underlying data to this companies' staff, so a homebrew wasn't an option (which it shouldn't be, almost 99% of the time).

Luckily, there were only two possible prices for those products, so all I had to do was create two CCK *decimal* fields [ this is important, because text, and integer fields don't properly store or sort decimal points for prices ]. Then, on hook_cron, or a node submit, I updated the two totals based on other itemized fields.

However, how would the view know which column to sort products by based on a flag stored in the users session? There's about 5 ways to do that, so I went with the 1 minute solution:

Set up two sorts in a single view, and implement hook_views_query_alter(&$view, &$query)

Discussion

In theory, you could write a custom algorithm that built its own sort queries based on a criteria using this method. You could also probably alter filters, or fields. However, this isn't the only way to have accomplished this -- but its the easiest for me to stomach. Never use this method when existing views features, or view arguments, or even other views hooks may be the proper hammer for this nail.

If I learned anything, its that views a complex beast; flexible like F-22 -- an amazing piece of technology that offers tremendous freedom -- but often that freedom will cause you to crash in the ground if you don't think about what you are doing carefully.

During the drupal.org redesign process, I noticed that Mark Boulton was using blueprint. I decided to give it a spin, and used it on a drupal site for a surgeon who specializes in sports medicine. (heavy use of imagecache, nodequeue, views, books, and nicemenus). Since that project, my stance on blueprint is this:you'll take my CSS framework from cold dead hands.

Is there a drupal theme?

Yes, and its very well made. Offers nothing except a basic grid layout that supports1,2,3 columns, a strong typographical foundation, and the conversions of various drupal elements to the blueprint styles. My "starter theme" of choice. In my humble opinion, the revolutionary advances in drupal 6 make big, bulky starter themes unnecessary.

Blueprint crash course

You don't need to know a whole lot to use blueprint. Everything you absolutely need to know is in the below code example. (with notes below)

• 1. .container sets width to 950px, and centers the content with auto margins on the side. All grid elements must be within ".container".
• 2. .clearfix - this does the same thing as having br class="clear" below the floating elements. See the oddly named br element that doesn't need to be there.
• 2. .span-[x] The width of the column in the grid. Numbers range from 1 to 24. A full row must add up to 24, and can also include prepend-[x], or .append-[x], which share the exact same widths, only add margins, either before or after the column. The final column always needs the class "last" so that it doesn't add its 10px right margin.

And that's really all there is too it. Of course, there are many more features, that let you get perfectly centered borders that don't cause the elements to overflow, some nice typography classes, and other useful stuff that nearly any website needs. I found the best way to learn the framework was to just look at what's going on on the example pages, with firebug. Its all quite self-explanatory.

How Do You Teach Drupal Without Inducing Confusion/Boredom Triggered Comas? Here's a rule that has never let me down:

Never interact with the drupal site in any way during a lesson

The person you teach needs to click on every menu link, fill out every form, and as they learn, its your job to start taking off the training wheels. At first, you'll have to point them to where to go to add a new taxonomy term, but make it a point to later ask them to add a taxonomy term, and see if they remember how to find it.

This "hack" works well for two reasons:

1) It prevents you from going into conceptual monologues

When I'm at the helm, clicking around, and "explaining concepts", its almost impossible for me to avoid inflicting a salvo of turd bombs on my hapless student. For a moment, read this: (if reading this text doesn't make you want leave this article, there's something wrong with you)

In Drupal, a node is a grouping of data, which we call fields. A node is different from a user, and block, because its content, which leverages drupal's rich nodeapi. On this page you can add, edit, and manage node types using these tabs. By clicking "edit" I can edit node settings, like whether I want comments to be threaded, or flat. Isn't that exciting? By clicking "manage", I can add new fields to my node, which can be of many types including, text, number, decimal, computed. These fields have rich set of options, including setting the maximum length, making the field required, and even entering in custom validation code for node form submits.

Not only is this a terrible way to teach, best case is that your student is completely lost (probably on something as simple as the difference between nodes, and node types, the fact that a "field" is a specific CCK concept, and not a form element), but most likely, they are not paying attention anymore. Monologues + projectors = brain death.

Let your students direct what you are teaching them

Don't teach them about blocks. Teach them how to put that new announcement in the right sidebar. Don't teach them about views.Teach them how to edit their press release page so that it only shows titles, and dates, and a "short blurb" field. As they gain more understanding, you'll find they naturally gravitate towards more advanced concepts. Best of all, you don't have to waste time talking about boring things that they don't need to know, or blabbering about stuff that they already understand.

2) The student is always on the spot (meaning, paying attention)

Nearly everyone has a tendency to worry about asking "stupid questions" (they are never stupid questions). If a student actually has to do all tasks required to teach something themselves, they won't be able to hide the fact that they missed a critical concept. You'll know fairly quickly if you need to do a better job of explaining the admin menu and how it fits together, and the pattern it follows. You also will probably find out that they still have conceptual issues that need to be cleared up between the very similar taxonomy, block, and menu pages. You see, every little task becomes A TEST. Testing is about taking off the training wheels. Even when they *fail*, the very fact that their brain had to struggle before hand means they'll have learned something. Its uncommon for someone to fail tests like "go to the block admin page" more than 2 twice. Eventually, they'll know where to look even when they've never seen it, and you are just now introducing the concept. Just keep testing them. After all, its really a test of your teaching skills, no?

While this makes teaching and learning more challenging, they learn dramatically faster then the monologue projector methods, or constant email support alternatives. .

*There's no exceptions to anything I write, FYI. If there were a lot of variables, a situations where these rules didn't work, I'd cover them one by one. Because Drupal Planet readers love long winded tracts that refuse to take sides.

You don't need a crazy CSS framework to make multi-column CSS layouts easy. They already *are* easy.

If you feel skeptical about my claim, I don't blame you. Like many web developers I too have tried to create 3 column layouts using the various types witchcraft found on web developer blogs:

• The byzantine two column layout wrapped within a two column layout technique
• The arcane negative margin trick
• The absolutely positioned nightmare
• The include a different CSS file for every browser, or else challenge (this one feels like a game sometimes...)
• ...and a variety of crude negative-margin + absolute-nightmare + nested-2-columns-within-two-columns combos

I'll call this technique the "float everything and clear" approach. I don't claim to have invented it, its just the way I've learned to do it over 4 years.

It works predictably in Safari, Firefox, IE7, IE6. It belly laughs at the the task of switching from a 4 column, to 3 column to 2 column layout. ITS NO FUSS! It contains no hacks, no browser specific code, no positioning, no negative margins. Just give your columns a width, make sure they add up to the total width of the container, and move on.

Here's a demo, and explanation. The demo demonstrates the the technique with 4 layouts: 2 column left, 2 column right, 3 column, and 4 column. It also demonstrates those 4 layouts surviving fluid width, 1000px, 800px, 600px respectively. The demo site files are attached at the bottom. Enjoy.

When Bad Hosts (Yahoo Small Business) Happen to Good Drupal Sites

Time and again, I work for a client who is stuck with a horrid server environment -- say -- Yahoo Small Business.* Surely you must think that a company like Yahoo -- who employs none other than Rasmus Lerdorf -- would offer a decent environment. That's where you'd be wrong.

Its so bad that Drupal 6 won't even allow itself to ATTEMPT an installation. And with good reason. Consider the facts:

• PHP version 4.3.11 -- (I wonder if there have been any important security fixes since that version came out?)
• MYSQL version 3.23.49 (Remember 2002?)
• Register globals is ON -- this is a "feature" and there ain't a damn thing I can do about it.
• No support for mod_rewrite [meaning all pages on the site have to begin with "?q="]
• 20m Memory limit (32 pushes it depending on what image handling modules you have on... views and panels seem to want more than 32 too)

It seems like its not even worth the effort to try to get drupal to run there. Since the site has to be live on monday, I employed a crude method that gathers all URL aliases, and a few more paths, and generates a full tree of directories and index.php files to mirror the pathauto links. Break the glass, and use this in case of emergency. [its best to run this on a local machine, btw -- it takes a while, and you'll want to turn up max page execution time up to near 120 seconds and beyond for most sites in the php.ini files.

The hardest part about using drupal's javascript features is knowing where to begin: they remained an arcane mystery to me until today. After drinking a bit of whiskey, and studying how core was using Drupal.behavior, I learned it couldn't be simpler. If you don't know how to do this, take a moment:

Step 1: Invoke the javascript "hook": Drupal.Behaviors.$hook

Sometimes you need to override more than a theme function: the entire page needs to be overridden. Drupal 6 makes it rather easy to do this.

In the example below, we call hook_menu_alter(&$callback) to override the display of every single node page view.

Instead of returning a node page, we return "[author's username] is great... for me to poop on.".