The Drupal 5 version gives you the possibility to use the administration theme when editing posts. This feature was introduced in Drupal 6 core and is with this module now available in Drupal 5.
Use the administration theme on more pages then possible with Drupal 5 or Drupal 6 core. You can allow the theme on a predefined set of pages and on a custom set of pages. The inverse is also possible: specifying a set of custom pages on which you don't want to use the theme. An example of this might be that you want to use the administration theme (all pages having a path starting with "admin" (admin/*)) but not on "admin/content/node".
Hooks! All modules can now add some pages to the administration theme settings page using the hook_admin_theme hook. By doing so you give inexperienced users the possibility to just tick a checkbox to use the administration theme.
A permission is introduced to allow or disallow certain users to use the administration theme.
Read More..
Showing posts with label drupal 5. Show all posts
Showing posts with label drupal 5. Show all posts
Friday, January 2, 2009
Friday, November 28, 2008
Updating Drupal 5 Modules to Drupal 6
About 5 months ago I was worried when the department I was working with in NYC was getting ready to migrate sites from Drupal 5 to Drupal 6. I had started working with Drupal during the late 4.6 days but wasn't really a developer until a few months into Drupal 5. Even then I was making beginner mistakes of hackng modules (but not core) to get my desired results.
Fast Forward 1 year and a few months, after hours of reading other people code, blog post, going to DrupalCamps, DrupalCons, and Lullabot trainings, I finally feel comfortable developing in Drupal 5. Of course this is all in relativity, you have modules like Views and Panels which remind you there is so much more to learn.
I moved onto a new position here in San Francisco right before major migrations started at the other company. I'm thinking "Phew, saved my ass from having to do that, more Drupal 5 sites here I come." But sure enough, after a few months the overwhelming power of Drupal 6 came along and of course this new platform I'm working with is needing to be upgraded.
Because the Drupal community is so awesome (understatement), a majority of contrib modules have already been migrated. We're basically building the platform from the ground up and eventually migrating old sites to the new platform when all custom pieces are in place and well tested. Till then we're able to release new sites based on Drupal 6 that aren't dependent on all features from the previous platform. The flexibility of this is great for numerous reasons and the person streamlining this process has done a great job of laying out the groundwork to build upon.
Custom modules appear to be the only things we needed to migrate to D6. It finally felt like enough time had been provided to learn the major changes that effect modules from D5 to D6. Well, it appears not much time was needed at all. With the assistance of Coder module, I began seeing a pattern of; change hook_menu, fix l() and url(), use menu_get_object(), hook_form_alter() with $form_states. I'm sure there's plenty more but these appeared to be most common.
So i'm gaining confidence in the types of changes being made using Coder for module upgrades. I've heard of a module called Deadwood that will do most of these changes automatically. After dropping a Drupal 5 module into a deadwood folder in the files directory clicking a few buttons a Drupal 6 module would magically appear in a goodwood folder. This worked great, the easy stuff that I was accustomed to was getting done and I would spend a just little more time using Coder to catch some things that were missed.
Read More..
Fast Forward 1 year and a few months, after hours of reading other people code, blog post, going to DrupalCamps, DrupalCons, and Lullabot trainings, I finally feel comfortable developing in Drupal 5. Of course this is all in relativity, you have modules like Views and Panels which remind you there is so much more to learn.
I moved onto a new position here in San Francisco right before major migrations started at the other company. I'm thinking "Phew, saved my ass from having to do that, more Drupal 5 sites here I come." But sure enough, after a few months the overwhelming power of Drupal 6 came along and of course this new platform I'm working with is needing to be upgraded.
Because the Drupal community is so awesome (understatement), a majority of contrib modules have already been migrated. We're basically building the platform from the ground up and eventually migrating old sites to the new platform when all custom pieces are in place and well tested. Till then we're able to release new sites based on Drupal 6 that aren't dependent on all features from the previous platform. The flexibility of this is great for numerous reasons and the person streamlining this process has done a great job of laying out the groundwork to build upon.
Custom modules appear to be the only things we needed to migrate to D6. It finally felt like enough time had been provided to learn the major changes that effect modules from D5 to D6. Well, it appears not much time was needed at all. With the assistance of Coder module, I began seeing a pattern of; change hook_menu, fix l() and url(), use menu_get_object(), hook_form_alter() with $form_states. I'm sure there's plenty more but these appeared to be most common.
So i'm gaining confidence in the types of changes being made using Coder for module upgrades. I've heard of a module called Deadwood that will do most of these changes automatically. After dropping a Drupal 5 module into a deadwood folder in the files directory clicking a few buttons a Drupal 6 module would magically appear in a goodwood folder. This worked great, the easy stuff that I was accustomed to was getting done and I would spend a just little more time using Coder to catch some things that were missed.
Read More..
Subscribe to:
Posts (Atom)