Drupal 6 Archives - developed.be

This tutorial explains how to created a single page with a login form an a register form in Drupal6.


To accomplish this, we have to go through some concepts first:

Continue reading “A custom login/register page for Drupal 6″…

I upgraded my Ubuntu 10.04 to Linux Mint 14. After installing LAMP I got a Drupal WSOD on a previously well working site. As it turned out most errors came from deprecated php-functions and deprecated call by references to functions, introduced with the release of PHP 5.4.

At first I was a somewhat encouraged to solve those deprecated functions, but I gave up pretty soon. Drupal 6 isn’t designed for 5.4. Tweaking Drupal feels the same as upgrading to Drupal 7. Therefor, I keep it to PHP 5.3.

To downgrade 5.4 to 5.3 I recommend this script on the Ubuntu forums.

Introduction (back to the 90’s)

Apple lovers (= those who would kill for a €599 iPhone and trade it for a €20 coupon within two years) have forced webdevelopers to go back to the 90’s. Those phones appear to have 56k modems, can’t play flash videos, and use screens even smaller than 800×600.

If you want to make a mobile version of your Drupal 6 site, you’ll not only have to strip half of your functionality, but also half of your html, css, js, images, flash and anything the w3c recommends since 1989.

I thought in terms of teletext (80’s kids will recall: texts, slow page loading, and low graphical use). (that it is what mobile is).

Continue reading “Mobile site: back to the 90’s”…

  • Published:March 14th, 2013
  • Category:Drupal 6

This post applies when

  • The admin menu suddenly disappears
  • The admin menu is incomplete (menu-items are missing)

Following scenario causes this behaviour:

  • The records of table “menu_links” with menu_name “admin_menu” were deleted (could be caused by an unfinished or erroneous cache wipe).
  • Cache-clear was called and caused a time-out by the webserver or php. (keep in mind cache-clear could’ve been called by cron through wget or by poormanscron)
  • Before the table menu_links was entirely refilled, a page of the website was requested by a user.

Even if you clear-cache afterwards, it says incomplete or missing.

A quick solution I’ve found is this:

  • Backup table “menu_links”
  • Delete the records in the table “menu_links” with menu_name = “admin_menu”. Don’t remove all the records in the table because primary and secondary links are also located in that table and they would be deleted permanently.
    DELETE FROM menu_links WHERE menu_name='admin_menu';
  • Call “cache-clear” but with Drush, because Drush doesn’t get interrupted by time-outs.

Or the more sustainable solution:

  • Change the time-out of the webserver to let’s say 120s.
  • Backup table “menu_links”
  • Delete the records in the table “menu_links” with menu_name = “admin_menu”. Don’t remove all the records in the table because primary and secondary links are also located in that table and they would be deleted permanently.
    DELETE FROM menu_links WHERE menu_name='admin_menu';
  • Call “cache-clear”, preferably with Drush, but you could also call it with the web admin as long as it doesn’t time-out.

It’s difficult to get around Drupal-modules that appear to have the same functionality. This is particularly the case when you want to set-up decent SEO-friendly url’s. The two main modules are called “pathauto” (also named: url-alias) and “path-redirect” (also named: url-redirect). This post applies only to Drupal 6.


pathauto = url-alias = /admin/build/path/list = table url_alias

path-redirect = url-redirect = /admin/build/path-redirect/list = table path_redirect

PathAuto (or URL-alias)

Pathauto is the standard module that creates SEO-friendly URL’s for users, nodes, taxonomy (etc) based on the title of the node. You can set up what the url’s must look like in /admin/build/path/pathauto

But when an url gets changed, the previous url would become unreachable and the user would get a “404 – page not found”-error. This is negative for search engines, bookmarks, and links from other sites. This is where path-redirect comes to the rescue.

Path-Redirect (or URL-redirect)

The path-redirect module keeps a list of all aliases that were changes and redirects them with a 301 (the permanently moved http-status).

In order for this to work, you need to check an checkbox in path-redirect  (see screenshot). Direct link: /admin/build/path-redirect/settings

path-redirect settings for Drupal

As if that ain’t enough, you also have to specify this in PathAuto. Go to: /admin/build/path/pathauto and scroll to “General Settings” > “Update action”. Select “Create a new alias. Redirect from old alias” (see screenshot)

Once you have created a field in Drupal, the fieldname will haunt you forever. A spelling mistake will keep living, and refactoring is out of the question.

It is however possible to change a fieldname in Drupal 6, but it might cost you a couple of hours work and a hard focus.


Drupal stores the fieldname in every thinkable place:

  • column-names
  • table-names
  • row-values

The obvious content-field-tables are an easy task, you can even do that manually. But Drupal also stores the fieldname in many other not-so-evident places, in views for example where fieldnames are stored as serialized data.

An all working script to change the fieldname is not evident (a reason why the possibility is not included by default in Drupal). There is a module that did an approach to change a fieldname, but in my option it’s best to do it all manually with a checklist.

Step by step guide

I made a step by step guide about how to change the machine name of a Drupal-6 field.

1) Backup

Backup your entire database. Test this script on your local machine or on a dev-server, not in a live environment. There is no guarantee that it won’t break your database.

2) Automatic script to change evident table names and column names

I made a php-script to make the task easier.

The script:

  • changes the fieldname in the most common places in the database.

Continue reading “How to change the machine name of a content field in Drupal6″…

I wanted to make a list of “related nodes” based on the term that is attached to the node.

Say I have 10 nodes that have the term “fruit”. With every fruit-node I want to display 5 links to other fruit-nodes.

I work with panels and views.

This turned out more time-consuming then I thought because the way to do it is not straight forward.

  1. Make a new view
  2. Add “taxonomy term id” as argument. Select “hide view” is the argument isn’t provided.
  3. Add a couple of fields to display (eg: title, teaser).
  4. Save the view. Make sure your caches are cleared.
  5. Make or edit a page (with the panels module through: Administer › Site building › Pages).
  6. Make or edit a variant.
  7. We need to add a new relationship to the variant. This will make it possible to parse the term id  to the view.
    1. Click on the tab “context” in the variant.
    2. Add a relationship. Select  “Term from node” in the dropdown and click the “Add relationship” button.
    3. A new window will open. Select the correct vocabulary (in my example: the vocabulary where “fruit” belongs to). You might want to give it a decent name so you can recognise it later.
    4. Click “ok”.
  8. In the “content” tab, add a new pane to the panel. (click the gear icon and select “add content”)
  9. Select the view you’ve just created (under the “views” tab on the right) and select the “default” view. (do not make a “content pane” in the view because this does not work that way).
  10. Normally it will show the views’ argument (term id) with a dropdown under it. In the dropdown select the term id of the relationship we created in Step 7.
  11. Click update & save. This should do.


The short answer:

It’s not possible

The long answer:

In a simple user form it is possible to add a single on/off checkbox.

  $form['thermometer_enabled'] = array(
    '#type' => 'checkbox',
    '#title' => t('Show the thermometer'),
    '#options' => array(0 => t("no"), 1 => t("yes")),

But, it’s not possible to provide a default value (checked/unchecked) with a single chechbox. This causes difficulties when you want to show the saved value of a user.

A simple solution is to use a “yes/no radiobutton list” instead of a single checkbox.

  $form['thermometer_enabled'] = array(
    '#type' => 'radios',
    '#title' => t('Show the thermometer'),
    '#options' => array(0 => t("no"), 1 => t("yes")),
    '#default_value' => variable_get('thermometer_enabled', 0),

In this example the result is saved in the variable thermomoeter_enabled and has the default value of 0 (false).

In case you’ve installed Varnish but not Pressflow (for Drupal 6), following scenario may happen:

  1. User A logs is, gets sessionid A
  2. User A changes something and loads a new page
  3. While loading the new page, a js or css-file is being downloaded from Varnish (example: /sites/default/files/js/js_79eb17289b3a88ec931b6f4bdb728282.js)
  4. The next file that is being downloaded is a jpg. This file doesn’t come from the Varnish cache and gives a new sessionid to the user (sessionid B)
  5. The requested page is being served correctly because it was requested with sessionid A. The user is unaware that he has a new sessionid because it happened during the loading of the page elements.
  6. The user clicks on another page and sends a new request with sessionid B.
  7. Drupal checks sessionid B and sees that it the session belongs to an anonymous user. Result: the user gets an “Access Denied” and is logged out.

Solution: install Pressflow. It will stop giving sessionids to the client.

(this post only applies if you have installed Varnish)

Let’s face it: Drupal can be a snail. When you attract lots of visitors, or have a lot of content, you performance will go down. To speed up Drupal, you need to install other software on your server that will make it appear like Drupal goes faster (but in fact stays as slow).

You can do any of these or a combination of these:

  1. Use memcache. Memcache replaces the classic cache-database-tables and puts the cache in the RAM (instead of in the database). This is the fastest way of getting your data.
  2. Use nginx instead of Apache. Nginx is a lightweight webserver that can handle more traffic than Apache. While it will not make your site magically faster, it can surely help up.
  3. Code-improvements in Drupal:
    • Disable menu_rebuild every time a view is saved. Run menu_rebuild only when cache clear is explicitly asked. (this is in fact core hacking, which is wildly disapproved, but it clearly helps)
    • Rewrite heavy queries generated by Views. Views don’t make the nicest queries. Certainly complex views can be made faster when you edit the query yourself. You can do this with a module that hooks into the view.
    • Check for node_load() calls everywhere. These functions eat up memory and should be replaced where possible (a custom query could do). You wouldn’t believe what happens when you call node_load().
    • Cron:
      • inspect all the cron hooks in your Drupal installation. Decide if the tasks are really necessary, and/or edit them. You’ll notice that the cron spends most of its time with indexing the search words.
      • Use visitorstats (like Google Analytics) to see when traffic peeks. If your website peeks at noon, edit the crontab and disable cron around that time. At least all cpu will go to your visitors. (make sure there are no real important tasks to be done). Cron should run “just enough”. I set my cron to run every hour from 11PM to 7AM.
      • Drupal calls home once a day to see if there updates for modules (with fread). This action consumes cpu. I think that once a week is more than enough. Even every forthnight. You can always check for new modules manually.
    • * In order to do find bottlenecks:
      • Use the Devel module. It displays all queries that are made to the database.
      • Use XHProf. A free php-profiler developed by Facebook to find slow components. It displays function calls and generates a graph (also install Dot for that). My article on how to install XHProf.
      • If you have the possibility, use New Relic, a tool similar to XHProf, but more advanced.
  4. Boost: Boost is a Drupal module that caches entire  webpages as static html files for anonymous users. You wouldn’t believe what a boost that gives. However: take in consideration that websites with a lot of content changes will need to refresh this cache a lot. It’ll take some time to configure. Still, it doesn’t speed-up the admin-environment in any way. This article explains how to install Boost with Nginx [mysqlperformancetuning.com].
  5. Varnish: A similar, but better, approach to Boost is Varnish. Varnish also caches pages, but puts them in the RAM, while Boost uses the hard discs (and creates amounts of files). A downside of Varnish is that it’s complex to set up (you have to put it in front of your webserver) and is difficult to config. With Varnish Drupal can’t use anonymous cookies, so you have to patch your entire Drupal setup, and use “Pressflow” as Drupal core instead of the regular Drupal releases (this is just for Drupal 6). Any module that uses sessions will have to be patched. Varnish however promises what it delivers and gives a serious boost to your website and is far more advanced than Boost. My article on how to install Varnish.
  6. If you can afford it, use a seperate (database) server. Drupal generates a lot of cpu-pressure. This makes the database on the server getting less cpu. Some queries take x50 times as much time as on a non busy site. By taking the heath of the database, this should give a performance boost.