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.
API Changes Everywhere
Developers have a large set of API changes that they'll need to discover and learn anew, such as the DBTNG changes, file handling changes, etc... but themers also have a few changes to contend with.
Two quick ones that I encounter on most sites are:
drupal_set_html_head() --> has been changed to drupal_add_html_head()
What used to be a simple "fill in the first argument with the code you'd like to output in the <head> section of your page" has now turned into a somewhat more complicated, but ultimately more flexible and 'hook-into-able' affair. You need to feed the HTML into drupal_add_html_head() as an array. See the docs page linked above for more info (and see, specifically, the comment I added to that page.
drupal_add_css() gets simpler, more complex
In Drupal 6, you could throw a quick CSS file at drupal_add_css(), along with a couple other simple arguments to define what kind of stylesheet they've added. In Drupal 7, you can do all of this, but in a somewhat more robust way. There are some nice new options, like telling drupal you'd like the stylesheet to load for every page, or setting a weight for your CSS so you can have it appear lower in the list (to override other stylesheets, for instance).
Also, you can now call drupal_static_reset('drupal_add_css'); to quickly wipe out all other stylesheets added before yours. This can be nice for debugging purposes, or if you just want to simplify to one stylesheet that you (or your module) provide(s).
These are just two of the functions I interact with on a regular basis that will be a bit different and afford more flexibility. What are some of your favorites / most often used?
Comments
Nice writeup, appreciated. The API changes I've dealt with is now when adding a node programmatically, the body is added differently
$new_node['body'] = 'Some nice body text right here let me tell ya'; // example body textOld D6 way of adding: node->body = $new_node['body'];
New D7 way oof adding: $node->body['und'][0]['value'] = $new_node['body'];
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.
why aren't you writing a sub theme? you don't need a sub-module to add a css file.
Mostly because I don't want to deal with making an entire subtheme/info file. I already have a custom module, and it's easier to just quickly add a spreadsheet there with a few tweaks than to make a subtheme—in this case.
Most of the time, I would do a subtheme.
It's been quite common in my experience to see 'site-specific' modules used as an extension to the theme layer, to allow themes to implement module hooks.
This can be very usefull for things like modifying menues and forms, for adding specific views handlers and other things.
These things could be kept in individual modules, but that would result in lots' of little modules for theme work.
I actually used to use a single module in drp5 that would extend the current theme to run module like hooks for it. There were some hooks that were ignored, but think hook_form (or in the old days: hook_nodeapi) for a theme.
I am sure that there are some purists out there who would yell at me for not keeping display and function separate, but the real world isn't as clean as theory, and Drupal isn't designed as an mvc app or anything.
J
Quite true, and even core is still nowhere near MVC-style.