5.x
Migrating data in Drupal 5 to 6 using Table Wizard and Migrate (Part 4 - Product Nodes)
Product nodes
So the next step is bringing in the product nodes. As I mentioned in the company node migrate post, I have some custom text fields with taxonomy terms in them, as well as a regular taxonomy, and a node reference field (for the company that makes the product).
The custom text fields' data and the regular taxonomy terms must get moved into new Content Taxonomy fields. The node reference must have its node id number updated to get the new company node id.
Migrating data in Drupal 5 to 6 using Table Wizard and Migrate (Part 3 - Company Nodes)
After importing taxonomies and users, now I need to bring in the actual nodes. First thing to do is remove the primary key option from the node table's vid field. Remember, Table Wizard only works when the table has a single primary key.
Alright, so the things that need to be updated during the migrate are the taxonomy terms for each node, any node-reference fields (user-reference fields are fine as-is because we simply copied the existing user base to the new site), and our meta tags from the nodewords module.
Migrating data in Drupal 5 to 6 using Table Wizard and Migrate (Part 2 - Users & Profiles)
Well, it looks like the users are pretty simple to do. Just overwrite the Drupal 6 profile_fields, profile_values, role, users, and users_roles tables with the Drupal 5 ones. No need to do any importing (which would have been pretty complicated with all the profile values in there).
Couple of things to watch for though:
Allow certain roles to bypass Post Preview when it set as required
On a client's site, the Post Preview option is turned on to reduce the amount of bad posts. However, as an admin, this is a real pain - I hate having to Preview first and then Submit. So I did some digging and found out a couple of other people are also interested in a solution. A chap by the name of Markus Petrux has even released a small module (for 4.7) that allows certain roles to bypass the forced preview. You can select which roles in the Access Control page. His module can be found here.
Adding an "active" class to menu links
This method works on all menus that are displayed as blocks i.e. not primary or secondary links. These sorts of menus are created using the theme_menu_tree() function. The process here is a bit more complicated than for primary links, but all you have to do is paste in the code below (I have done all the heavy lifting for you).
Put this in template.php somewhere:
Adding an "active" class to primary links - Option 1
Because primary links use theme_links to generate their output, we could override that theme and add in our own code to get an "active" class on the <li> element. Drupal 6 made some improvements to 5's theme_links function, so I used that version and added in some code to check for the front page too.
Adding an "active" class to primary links - Option 2
There are quite a few posts about setting the active trail properly with primary & secondary links. In Drupal 5.x, its actually handled pretty well if you use the following code to print your primary & secondary links in page.tpl.php
<?php
print theme('links', $primary_links);
print theme('links', $secondary_links);
?>