What are the “Gotchas” for a Drupal 6 developer learning Drupal 7

Question

So, I've stood up about 20 Drupal 6 sites for personal and professional use, written and contributed to Drupal 6 modules, and even co-maintain one.

Just when I feel like I've gotten to know D6 pretty well, D7 comes along. To prepare myself for world that's moving on, I'm trying to recreate some of my Drupal 6 projects in a Drupal 7 test environment I've set up. Before I get started in earnest, I would be interested to hear from others who've made the switch.

What are some of the "gotchas" that you've come across?

That is, what are some of the documented and correct Drupal 7 behaviors (either in core or in common D7 modules) that nonetheless perplex someone who's used to thinking a in D6 environment. Of course, I've read the documentation and know about all the biggies (e.g. the changes to db_query().).

What I'm looking for are changes that might be surprising and/or confusing, especially ones in common D7 modules like CCK, Views, and so on.

Thanks!

Answer 1

Some gotchas I've learned while porting quite a number of modules to D7.

• You will have to find a new home for your administration settings page(s), if you have any. It is not simply admin/settings/yourmodule anymore but admin/config/category/yourmodule. There are quite a few categories already, try hard to find one that more or less matches your module instead of creating new ones.

• The *_load() functions only accept a single integer, something like user_load(array('uid' => 1)) will result in ugly, hard to trace warnings. There are now *_load_multiple() functions which can load multiple nodes, users, comments, .. with a single query. Search for "_load(array" in your code to find these.

• Everything goes then through entity_load() which you might want to use directly sometimes when you just have a $entity_type string and an id. However, note that that function is actually a incorrectly named *_load_multiple() function which you need to pass an array of id's and it will return an array of results.

• Everywhere where 'class' is used to add HTML classes to form/table/whatever HTML elements needs to be an array of classes instead of a string. Not doing so results in fatal errors.

• You now need to pass arguments as a keyed array to theme functions and theme functions also receive such an array. For example, theme('username', array('account' => $account)) instead of theme('username', $account).

• In general, the API is a bit rough around the edges, passing wrong arguments to a function can easily result in fatal errors and similar stuff.

And last, not a gotcha but a suggestion. Try to adobt the D7 way of doing things, be it usability (vertical_tabs are a great way to improve large setting forms for example) the whole generic entity/field stuff, return renderable arrays from your page callbacks instead of strings and so on.

Answer 2

I think the main gotcha to me has been the new Field APIs and database structure. While fields in core is awesome in many ways, the APIs for it are hideously complex. I spent half a day trying to figure out how to use EntityFieldQuery before giving up and using SQL for the job. Having to resort to hacky workarounds because the APIs are poorly documented in inobvious places is not my idea of fun. And the rabbit hole just becomes deeper if you want to make your own fieldable entities. The learning curve just increased exponentially, and I expect to see more, not less sites build by hacking together a mess of one-off node types and per-page views, because doing stuff the right way has become harder.

And as for the new database structure for fields, I can't find much good to say about it, besides the fact that it's flexible. A simple node type with 5 fields has its information spread across 15-20 database tables with a lot of redundant information. Each field table has rows for entity_type and bundle, even though they all have the same value. ("node" and the node type name), and querying this this mess of tables is both slow and confusing, so you really need to be using the aforementioned APIs. There is some hope that Per-Bundle Storage could help alleviate that, but otherwise the new data storage system for fields is going to be one particular bad headache when it comes to scaling your site, unless you have the extra sysadmin time to spend for setting up and maintaining a separate database for field storage.

And I am not a great fan of the new database layer, either, but that's mainly because I am one of the geeks who actually like SQL…

Still, there’s a lot to like about Drupal 7, and I will be building many sites with it in the future, so while there are some nasty headaches in the aforementioned things, there are some really nice benefits, which I think outweighs the bad stuff.

Answer 3

For me, and from a themer's perspective, the big change was the increased granularity in the themes. Now it's pretty much a requirement to theme each CCK field separately (ie, in a separate field theme file). So there's more work when you're creating a theme. Mixed with the renamed tpl files, the first time you're doing a D7 theme, you'll probably be pretty much dazed ;).

Since you've read the docs about the biggies in the API, I won't get into details here. But there hasn't been too much shuffling, from what I've seen. Porting a module to D7 often only requires checking all the arrays - there's often an extra index here and there you need to add. Though some functions have disappeared completely (for instance, some of the taxonomy-related ones).

Server-wise, you should get something with more available memory. D6 ran OK with 32MB, D7 doesn't seem to do so well. 64MB is the recommended minimum. I'm already migrating a few sites to a new server, with 128MB available memory.

These changes apart, it's still ole' good Drupal :).

Answer 4

As far as theming goes, there is now a template_process() to accompany template_preprocess(), which can be confusing if you're tracking down where a variable was changed.

Answer 5

They've changed tons and tons of things each of which can be a gotcha. Some of the changes are very minor (eg. renamed DB tables, hooks have been split into specialized versions etc), some major (the database API, stream wrappers), but most of which is not very well documented. Best place to start is to read this entire page:

http://drupal.org/node/224333

And I would also suggest getting a book, Apress Pro Drupal 7 is a good one and has been invaluable in transitioning me from Drupal 6 to 7. Also grab the D7 Examples module:

http://ftp.drupal.org/files/projects/examples-7.x-1.x-dev.zip