Drupal 6.x

Cached part

This is very simple, a search-and-replace operation. Here is a list of changes:

• hook_menu() no longer takes any parameters (remove $may_cache).
• The value of path is the new index for $items.
• callback becomes page callback
• callback arguments becomes page arguments
• access becomes access callback and access arguments.

  For example, access => user_access('administer nodes') becomes 'access callback' => 'user_access', 'access arguments' => array('administer nodes').

  However, the default for 'access callback' is 'user_access' so you can leave that out.

  Complex access things must be moved to a function which can be called on runtime, user_is_anonymous and user_is_logged_in are useful helpers. See Access control for more.

• The title and description arguments should not have strings wrapped in t(), because translation of these happen in a later stage in the menu system. This allows translation of menu items to any language required on a site, adapting to the language used on the page.

Non-cached part

Let's suppose you had

The Drupal menu system was always much more than what the name suggests. It's not only used to display visible navigation menus but also to map Drupal paths to their callbacks with proper access checking. This second task is called dispatching. The likely rationale behind this; once you define a link to a page, you might want to define what happens when you click that link.

This eventually led to a very complex data structure which was stored as a serialized array in the database -- per user. Unserializing this on every non-cached page load uses tons of memory. Altering this either on build or run time needs dirty hacks.

Some misunderstandings about how access to an element applies to their children led to grave security holes with some contributed modules. This stresses the need for thought out, cleanly defined inheritance rules.

In addition to the material in this handbook, developers may find the Content Construction Kit Group to be a useful source of information. That is an active group of people who develop and use CCK modules, and it's a good a place to read what others are doing, or post questions and announcements about CCK development.

Most content in a Drupal site will come from instances of Content Types. It is important to read the handbook page on Content Types.

The Content Construction Kit allows you to add custom fields to any of the content types using a web interface. In Drupal 6.x, custom content types can be created in Drupal core, and the Content Construction Kit allows you to add custom fields to any content type.

Upgrade Limitations

Description

The taxonomy image module allows site administrators to associate images with taxonomy terms. Once defined, this association allows Drupal themes or other PHP code to display images with site content. For example, the taxonomy_image module might be used to display a penguin with content about Linux, and a cheeseburger with content about junk food.

The default .htaccess RewriteRule to redirect every multisite.com to www.multisite.com does not work properly.

If you have problems with it, leave the two lines uncommented, and add the following three lines for each multisite you set up:

 RewriteCond %{HTTP_HOST} mysite\.com$ [NC]
 RewriteCond %{HTTP_HOST} !^www\.mysite\.com$ [NC]
 RewriteRule ^(.*)$ http://www.mysite.com/$1 [L,R=301]

Credit to Florian.