Miscellaneous Drupal 6 notes

Miscellaneous notes on Drupal 6. There are Other Drupal 6 notes on this site.

Chances are that if I mention a module on this page without describing it in any way, then there’ll be mention of it in my notes on Drupal 6 modules or Drupal 7 modules. Many modules haven’t changed much between Drupal versions.

Index

• Other notes
• Useful links
• Setup
  • Cron
  • Basic auth for site access via Drupal users
  • Clean URLs
  • Users
  • Home page
  • Feed
  • Profile
  • Contact
  • Trigger
  • Modules
  • Private filesystem
• Roles
  • Site editor
  • Site manager
  • Site designer
• Module operations
  • Install
  • Uninstall
  • Upgrade
• Menus
  • $primary_links and $secondary_links
  • ‘secondary links’ in a block
  • Expandable ‘secondary links’ in a block
  • Section / Subsection
  • Permissions
• CKEditor
• File / image removal behaviour
  • Tests
  • Conclusions
• Criticisms
  • Severe criticisms

Other notes

I had so many Drupal 6 notes that I split them into several pages. See the Drupal 6 index page for a list.

Check my Drupal 7 notes if you don’t find what you’re looking for here, as some of them are also applicable to D6, particularly the notes on Drupal 7 modules because modules may not have changed significantly between releases.

Useful links

• Top 10 Things to do after you install Drupal
• Ten Drupal 6 Modules Every Site Should Have
• Working with blocks (content in regions)
• A Drupal Module Developer’s Guide to SimpleTest
• An Introduction to Unit Testing in Drupal
• Drupal 6 Theming Guide
• Overview of theme files
• PHPTemplate theme engine
• Drupal e-Commerce
• How to: create a wiki with Drupal
• Creating a Drupal 6 Wiki
• Corporate Manual: Wiki-Style

I also have a load useful resources in my online bookmarks, on a variety of web development and computing topics including Drupal, Drupal 6, Drupal 7 and Drupal 8.

Setup

Installation guide

1. Create database.
2. Extract drupal archive.
3. cd sites/default/
4. cp default.settings.php settings.php
5. Add DB details to settings.php ($db_url = ‘mysql://username:password@localhost/databasename’;)
6. Give web server write access to settings.php and ../default.
7. Set up Apache and visit the site. The installation script at /install.php should run. If you get a database error visit http://[thesite]/install.php.
8. After running the installation, change the group/permissions of settings.php and ../default back to what they were (no write access to web server).
9. Configure the site.

Cron

• Set up cron
• Configuring cron for HTTP authentication

Drupal cron is achieved by having a regular cron job requesting e.g. http://example.com/cron.php via curl (or wget or any other command line program that can request web pages).

For security, cron.php should be protected by basic auth with access allowed only by certain hosts. For each machine that runs a cron job to get cron.php, create a user for Apache basic auth (you will be prompted for a password):

htpasswd /the/location/of/passwords cron

Then add the following to .htaccess, using the IPs of whatever machines require access to cron.php:

<Files "/cron.php">
  Order Deny,Allow
  Deny from all
  Allow from localhost
  Allow from 127.0.0.1
  Allow from 87.97.137.18 <<- Your IP here
  AuthType Basic
  AuthName "For Cron Jobs Only"
  AuthUserFile /the/location/of/passwords
  Require user cron
</Files>

You’ll have to make sure you have the following line in .htaccess otherwise 401 errors will be handled by Drupal (which will show a 404 page) and you’ll never get a request from the browser for authentication:

ErrorDocument 401 "Unauthorized"

The cron job can be set as follows:

0 0 * * * /usr/bin/curl --anyauth --user cron:p455w0rd --silent --compressed http://example.com/cron.php

Basic auth for site access via Drupal users

Sharing authentication with HTTP-Auth

You can set up basic auth to look at the Drupal database for authentication.

Clean URLs

Administer -> Site configuration -> Clean URLs.

You will not be able to enable clean URLs unless mod_rewrite is enabled and the .htaccess file is present. Also, on some server configs where drupal is installed in a subdirectory, you’ll need to set RewriteBase /. See the comments in .htaccess for more info.

Users

Administer -> User management -> User settings.

Public registrations: Only site administrators can create new user accounts.

Home page

You can set a node to be the home page via Administer -> Site configuration -> Site information, ‘Default front page’ option.

Feed

Drupal automatically creates an rss feed from content promoted to the front page, at [site root]/rss.xml.

Feed settings can be configured via Administer -> Content management -> RSS publishing.

The appearance of custom fields in a content type’s feed can be configured via Administer -> Content management -> Content types, edit type, ‘Display fields’ tab, ‘RSS’ sub-tab.

The ‘Syndicate’ block can be positioned to provide a feed icon, via Administer -> Site building -> Blocks.

Profile

Can be used to create new field groups to appear in separate tabs on the user’s edit page, for e.g. personal information. Can control public visibility of the fields.

1. Enable as normal.
2. Administer -> User management -> Profiles.
3. Create a new field.
4. In the visibility section, a ‘Hidden profile field’ is not visible nor editable by the user and a ‘Private field’ is visible to the user and editable by them but others can neither see nor edit it. In both cases user admins can see/edit.
5. Select ‘Visible in user registration form’ if appropriate.

Contact

Create site-wide contact form, to contact different sets of email addresses depending on category, and personal contact forms, to contact individual users (if access granted).

1. Install module as usual.
2. Administer -> Site building -> Contact form.

Note that the Mass Contact module may be a better choice. See later.

Trigger

Trigger: Assign actions to system events

A core module. Allows you to perform basic actions (available at Administer -> Site configuration -> Actions), e.g. emailing someone, when a system event occurs. The events are very high level (e.g. node created) so the Rules module is far more useful. See later.

Modules

Much essential functionality is provided by modules. See Module operations and /computing/web-development-notes/drupal-6/drupal-6-modules.

Private filesystem

You can turn on the private filesystem via Administer -> Site configuration -> File system, Download method section. Drupal will rewrite all file paths from their actual location to a virtual ‘system’ location which will cause the node permissions to be checked before access to a file is granted.

For example, if you attach a file to a node it may be placed on the filesystem as sites/default/files/pretty-picture.jpg, but if you try and access that file you’ll get a Drupal 404 file not found error. Instead, you access the file via system/files/pretty-picture.jpg so that Drupal checks the permissions of the node and grants or denys access to the file.

To rewrite from a file’s actual path to its virtual path, use the file_create_url function (unfortunately you can’t use file_create_path because it’s broken and doesn’t work with both public and private filesystems - see file_create_path($image) breaks URL when private file directory is used):

file_create_url('sites/default/files/pretty-picture.jpg') -> 'http://example.com/system/files/pretty-picture.jpg'

Roles

To create new roles, go to Administer -> User management -> Roles.
New roles: Site editor, Site manager, Site designer.

To configure permissions for all roles, go to Administer -> User management -> Permissions.
Note that ‘administer nodes’ permission overrides the other node permissions to allow access to everything.

Site editor

Comment module: access comments, post comments, post comments without approval.

Node module: access content, create page content, create story content, delete own page content, delete own story content, edit own page content, edit own story content, view revisions.

Site manager

Comment module: access comments, administer comments, post comments, post comments without approval.

Node module: access content, create page content, create story content, delete any page content, delete any story content, delete own page content, delete own story content, edit any page content, edit any story content, edit own page content, edit own story content, revert revisions, view revisions.

Site designer

For access to web site before it goes live, at which point the designer should be removed from this group to prevent them screwing with site content.

Permissions same as site manager, plus…

Block modules: administer blocks. Node module: administer nodes, delete revision. System module: access administration pages, select different theme.

Note that ‘select different theme’ allows the designer to change their own theme only (in My account -> Edit tab -> Theme configuration section) - an admin with ‘administer site configuration’ will have to enable the theme as default when their work is done.

Module operations

Install

Installing contributed modules (Drupal 5 and 6)

1. mkdir sites/all/modules
2. Extract module to sites/all/modules/
3. Enable module and its dependancies at Administer -> Site building -> Modules.

Uninstall

1. Disable the module. Administer -> Site building -> Modules. If a module is a dependency, you’ll have to disable the dependant modules first, save configuration, then disable the module.
2. Remove module from database via the Uninstall tab.
3. Delete module directory.

Upgrade

Upgrading from previous versions

For modules, though it depends on the module, the approach taken by the Token module is…

1. Unpack the later version over the current version in sites/all/modules/
2. Go to [base]/update.php
3. (?) Choose the module you’re updating by selecting 1 from its dropdown.
4. Continue to do the upgrade.

Menus

Note: Without the Menu Subtree Permissions module to grant specific roles access on a menu by menu basis, you have to grant access to the entire menu admin page (which will be available by URL even if no access to the admin menu). Even though the user will not be able to delete certain items and won’t see items for pages they can’t access, they can still disable the items that are visible and hence alter all menus for all other users.

Drupal provides three menus by default, shown at Administer -> Site building -> Menus -> List menus tab:

Navigation - For logged in users to access site admin links etc. It has items by default.
Primary links - Intended for main site links. No items by default.
Secondary links - Intended for less important links (e.g. credits). No items by default.

These menus also appear as blocks in Administer -> Site building -> Blocks.

$primary_links and $secondary_links

Drupal provides the $primary_links and $secondary_links variables, which are not Drupal menus but source their items from Drupal menus. By default, they source from the ‘Primary links’ and ‘Secondary links’ menus, though this can be changed at Administer -> Site building -> Menus -> Settings tab (remember, on this page the dropdown items are referring to the menu names and the field labels are referring to the ‘primary links’ and ‘secondary links’ parts of the ‘navigation’ menu).

Both these variables only include one level of items, regardless of whether any items are set to be ‘Expanded’. The $primary_links uses only the top-level items from the menu. The $secondary_links uses only the children of a top-level item if it’s in the active trail (i.e. if we’re viewing one of its ancestors, however deep).

For example, if $primary_links and $secondary_links were both set to source their items from the Navigation menu, and we were at Administer -> Site building -> Menus…

$primary_links (contains top-level Navigation items): * Create content * Administer

$secondary_links (contains children of Administer): * Content management * Site bulding * Site configuration * User management * Reports * Help

All very confusing, because of the strange use of identical names for different entities. I suspect this is one of the main reasons Drupal seems to have such a steep learning curve for new users expecting to quickly create a basic site.

In Administer -> Site building -> Menus -> Settings tab, you can prevent the default Primary and Secondary menus displaying by changing the source of the primary and secondary links to ‘no primary/secondary links’.

Blocks

The ‘Primary links’ and ‘Secondary links’ blocks show the associated menu and show all items that are set to be ‘Expanded’.

More info

Read the following for a better description than in Drupal’s themeing guide: http://drupal.org/handbook/modules/menu

‘secondary links’ in a block

NOTE: Use the Menu Block module instead.

If you have the PHP Filter (core) module enabled, you can cut the secondary links markup out of page.tpl.php and put it in a block. Set the input format to ‘PHP code’.

Note: Neither of these options will create an expandable secondary links menu (see later for that).

Option one, as used by zen-6.x-2.0

All code but the first line was lifted from the secondary links code in the Zen theme’s page.tpl.php, though I’ve not tested it in a block yet - I assume that the first line is necessary to get the $secondary_links variable.

<?php $secondary_links = menu_secondary_links(); ?>
<?php print theme(array('links__system_secondary_menu', 'links'), $secondary_links,
  array(
    'id' => 'secondary-menu',
    'class' => 'links',
  ),
  array(
    'text' => t('In this section'),
    'level' => 'h2',
    'class' => ''
  ));
?>

Option two, as used by Zen before 2.0 (I think zen-6.x-1.0)

All code but the first line was lifted from the secondary links code in the Zen theme’s page.tpl.php - the first line is necessary to get the $secondary_links variable.

<?php $secondary_links = menu_secondary_links(); ?>
<?php if ($secondary_links): ?>
  <div id="secondary">
    <?php print theme('links', $secondary_links); ?>
  </div> <!-- /#secondary -->
<?php endif; ?>

Expandable ‘secondary links’ in a block

NOTE: Use the Menu Block module instead.

As above, create a new block and use the following PHP (from secondary-links as a tree/menu instead of links - solved?):

<?php
$menu_name = variable_get('menu_secondary_links_source', 'secondary-links');
$menu_array = menu_tree_page_data($menu_name);

// if the $menu_array has an entry with a below element in the top
// level, then that is our menu ... we want to extract that element
// and then output it using the menu_tree_output function ...
$top_level_keys = array_keys($menu_array);
foreach ($top_level_keys as $current_key) {
  $sub_menu_array = $menu_array[$current_key];
  if ($sub_menu_array['below']) {
    print menu_tree_output($sub_menu_array['below']);
  }
}
?>

You’ll get a menu that expands like the admin ‘navigation’ menu.

Section / Subsection

To have subsection (aka secondary) navigation show only links to content in currently selected section (aka primary navigation):

1. Administer -> Site building -> Menus.
2. Via the ‘Settings’ tab, set the source for the secondary links to ‘Primary links’.

Permissions

In order to allow an editor to add content to the menu, their role must have ‘administer menu’ set in Administer -> User management -> Permissions. This does however give them access to the Menus admin page if they visit via a direct URL (they won’t have the menu option unless also granted ‘access administration pages’).

File / image removal behaviour

Here I test in which scenarios an image associated with a node is deleted. The same behaviour can be expected of any file that’s attached to a node, but not when IMCE is used because it uses a different mechanism.

The test rely on the following modules:

• CCK with FileField/ImageField
• IMCE

Tests

Adding an image to two nodes will upload the image twice, adding a numerical prefix to images after the first.

Adding an image to a page creates a thumb in imagefield_thumbs, I think when the page is viewed. Removing the image via IMCE removes the thumb as well as the image.

Conclusions

• Files/media uploaded via IMCE will remain even if no nodes use it.
• Files/media attached to a node will be deleted when no other nodes reference it, even when it’s used in the body content, unless it was previously uploaded via IMCE.
• IMCE won’t let you delete a file that’s attached to a node.

To prevent people using attached files/media in the content of a node, must prevent them using IMCE to browse the folders in which the attached images are stored. This can be done via IMCE profiles at Administer -> Site configuration -> IMCE.

CKEditor

CKEditor - WYSIWYG Text and HTML Editor for the Web

Buttons enabled for Filtered HTML (used by anon for comments):

Bold,Italic,Strike-through,Bullet list,Numbered list,Outdent,Indent,Undo,Redo,Link,Unlink,Anchor,Source code,Cut,Copy,Paste,Paste Text,Paste from Word,Select all,Search,Replace,Maximize,Check spelling.

Buttons enabled for Full HTML (used by auth for content):

Bold,Italic,Strike-through,Bullet list,Numbered list,Outdent,Indent,Undo,Redo,Link,Unlink,Anchor,Image,Superscript,Subscript,Blockquote,Source code,Cut,Copy,Paste,Paste Text,Paste from Word,Remove format,Charactermap,HTML block format,Table,Select all,Search,Replace,Maximize,Check spelling,IMCE

Criticisms

• Ridiculous naming clash for menus and core menu variables. See ‘Menus’ section above.
• Inconsistent naming across admin UI. For example, the URL of Administer -> Site configuration -> Input formats is /admin/settings/filters, the names of the “input formats” on this page are “Filtered HTML”, “Full HTML” and “No filter’, but the option to add one is “Add input format” that goes to /admin/settings/filters/add.
• You can’t have a node linked from multiple menus, because it uses the first item found. Hence, with e.g. multi-lingual sites having a language neutral node linked from an english and finnish menu will result in an incorrect menu for that node when viewing it in one of the languages.

Severe criticisms

• A user with permission to administer users can delete the admin user (id 0) or the current user (i.e. themselves). Anonymous users (id 0) can also be deleted via the API. The Protect Critical Users or User Protect modules fix this.
• A user with permission to administer users can change the admin password, gaining access to all functionality. The User Protect module fixes this.

Last modified: 17/07/2014 Tags: drupal