drupal

Flags is a very useful module that allows users to "flag" nodes that meet some criteria (eg type etc). Administratively, it might be of interest to show the users who have flagged a specific node. Unfortunately, that's both tricky and slightly non-intuitive.

I've been working with the Forms API for some time. I've found a very useful shorthand for that today.

Forms API is great, let me start there. However there are some cases where you want to ... ahem, go around it. One such cases is with checkboxes (where you have a number of checkboxes), specifically when you want to alter just one of the set. Here's how to fix that!

There are many occasions in which you would like to alter a form behavior, and it's normally very easy to do -- just implement hook_form_alter and you're done. There are cases though, where fields will be missing, and in those cases, you need a workaround.

One of the great usability features in the Drupal Form API are simple validators, such as #required. Just set it to true, and Drupal takes care of it. However, when in a multistep scenario, simple validators go haywire since moving to a different step validates the form. Normally, you cannot override form errors within your validation hook... but there's a workaround.

More often than not, you'll come to a point where you need a field value of a node. Not the whole node, just a field. The most common case would appear to be when you need an image (say a promotional image). Some ways are easier than others for it, however you need to think of what you are doing under the hood.

I assume that if you've build a relatively large site, you've stumbled on Nodequeue by now ( summary: it allows you to create lists of arbitrarily ordered nodes ). But clients always had a thing for imagining things that are normally tricky to do, and one of them is to create a block that has arbitrarily ordered content per section of the site, usually by taxonomy term.

What every new developer in Drupal needs to get to his head (and hears all the time in the community), is that no matter what, you should never EVER hack core. Except when your problem is one that has absolutely no other solution. In our case, using an alternate administration theme, will cause access errors to administration pages to be rendered in that theme -- and that cannot be solved otherwise.

You really aren't using Drupal right if you're not harnessing the power of taxonomy, and you haven't seen much of it until you understand views. The only limitation for me was that you have to streamline all terms to look alike, in order to fit in the same templating. Well, not anymore!