drupal 7

Drupal 7. Is it ready?

That seems to be the general question in the air over the past few weeks discussed by many in the community. There's a problem with this question, though... I think many people look at their particular use cases, determine Drupal 7 to not (yet) be a good fit, then declare all things Drupal 7 to be lacking.

Really, though, are things so bad? I've seen hundreds of sites on Drupal Gardens that are beautiful and functional. I've upgraded two of my simpler Drupal 6 sites to Drupal 7. I've built a total of fifteen Drupal 7 sites—some serving more than 10,000 visitors a day, others serving a hundred or two (and almost all on shared hosting!)—and am working on three others. So, for me, the question 'Is Drupal 7 ready for prime-time?' doesn't make sense. It's already there (I haven't started a new project on Drupal 6 for six months now).

With the awesome new #states implementation in Drupal 7, and for form usability in general, it's often good to be able to selectively, or completely, disable form autocompletion for your users. One example I just encountered was a form that has two fields that are alternatively shown or hidden depending on the value of a checkbox earlier in the form. However, Google Chrome, in its infinite wisdom, was autofilling the hidden field, which shouldn't have a value if hidden, so I had to set the input's 'autocomplete' value to 'off.'

For simple textfields, here's how you could do that in a hook_form_alter() (in this example, I was disabling autocomplete on the user registration form's email field):

For a while (earlier in my Drupal career), I was avoiding adding imagefield-attached images to nodes that appeared in my search results, because I remember the first time I tried doing so, I was still quite confused by the way drupal handled search results theming.

Well, after another crack at it, I finally have a nice, performant way of displaying images from nodes added via imagefields (or in drupal 7, image fields) inline with search results, and it didn't require much work at all!

The image above shows inline images for LOLSaints.com, a site which uses Midwestern Mac's Hosted Apache Solr search service to return results quickly and allows faceting, etc. using the excellent Apache Solr Search Integration module. But the technique I'm using works equally well with built-in (but slower) Drupal core search module's results.

[UPDATE: Here is a much simpler method for editing a user's roles.]

I thought there might be some sort of API function that allows me to add a user role to a user object by the role id (rid), but after looking at user_save() and some other information around the Drupal universe (like this thread), it looks like it's not as easy as I'd hoped. Definitely not like node_save(), where you just modify the node object, save it, and you're done!

I wrote this helper function that you could stick in your own custom module (tested with Drupal 7), which lets you add roles as simply as:

  custom_add_role_to_user($user->uid, 'role name here');

Here's the function:

The References module in Drupal 7 allows for easy creation and removal of user and node references through Drupal's interface. However, programmatically adding and removing these references is a little more difficult.

You basically have to load the node which has the reference in it, edit the reference field (in my example, the reference field can have an unlimited number of references), add or remove the user ID (or node ID if you're chaging a node reference), and save the node.

Let's look at the example of simply adding a user reference to a node:

It takes a little more effort to remove a user reference (or node reference) from a node. For this, since I have to do it for a few different fields on a node, I've written a helper function that removes a given $uid from the array of user references on a given node.

[Update: Views 3.x has a really nifty plugin feature called 'Results summary' that you can simply add to the header or footer of your view, and use your own text with placeholders, to do everything I outline in the post below, without a line of code. Add a results summary instead of using hook_views_pre_render() or a Views PHP field.]

I needed to display a page/item counter on a view on one of my Drupal 7 sites, using Views 7.x-3.x. This counter would display at the bottom of the view, just above the pager, and needed to display the current number of results being displayed, along with the total number of results.

Views provides all this data right inside the $views object, so all I needed to do was add the following PHP snippet (including the <?php ?> delimiters) to a 'Global: PHP' textarea in my view's footer:

In Drupal 6, I would often resort to using my theme's template.php file to implement template_preprocess(), and add in the class to Drupal's $body_classes array. In Drupal 7, some new hooks were introduced that allow me to do this more easily, and inside my .module files.

Introducing hook_preprocess_HOOK()

...or, "Always Check Your Module Weights when form_alter'ing"

I spent about half an hour today trying to use hook_form_alter() to move the 'Scheduling options' fieldset (provided by the Scheduler module) out of my node form's vertical tabs (down where URL path settings, comment settings, etc. are jumbled together).

I couldn't even see the 'scheduler_settings' form settings when I looked at the form's array, even though I knew it existed (since it was being displayed, and the scheduler.module defined it using its own hook_form_alter().

A few months ago, I was starting to get fed up with having to manually re-patch the WYSIWYG module on about five of my sites every time it was due for an update, to incorporate functionality that I had hoped would make it into WYSIWYG as a regular button/plugin (see issue).

Well, after months of that issue's inactivity, I decided to take the bull by its horns and write up a proper module that would hook into WYSIWYG and allow me to (a) provide the functionality I needed to a wider audience, and (b) save me an extra minute of time per site upgrade (no more patches!).

Thus, WYSIWYG Force Linebreaks was born.

This module helps me with many of my sites - for many different reasons.

The transition from Drupal 6 to Drupal 7 has taken a bit of time, and I (like many others) simply haven't had enough time in the past few months to do D7 testing while in the midst of tens of other D6 projects.

I've committed, though, to building out three Drupal sites in Drupal 7, now that we're at beta-3, and I will be posting a few reflections, mostly from a themer's perspective on some changes—the good, the bad, and the confusing.

A New Default Theme - Bartik

Just like Drupal 5/6's default theme, Garland (which is in use on this site right now :-/), Bartik will be seen on thousands of quickly-built sites around the web, and I think the theme is robust enough for this purpose. I'm actually building one site's theme directly on top of Bartik, just modifying CSS through a single stylesheet added by a custom module.

But it's nothing amazing, in my opinion. I think it would've been awesome to have some sort of dropdown menu support in core by this point—but it looks like that will wait until Drupal 8 at least. This is probably the number one most requested feature I get on a lot of the smaller sites I'm asked to build, and having the feature in core would be über-cool.