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.

Posted in:

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.

Posted in:

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:

Posted in:

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.

Posted in:

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:

Posted in:

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.

Posted in:

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);
?>
Posted in:
magnanimous-junior