Planet Drupal

With W3C Validator module, you can validate markup on all nodes and views in a Drupal site.

I have been on the lookout for several years now for a good tool to validate markup across an entire site. The Drupal module w3c_validator does almost exactly what I want.

Prior to discovering this tool, the extent of my use of markup validation was to pass URLs to the the official W3C validator or open one of several validator plugins for various browsers.

Web site performance is an expansive topic. Like just about any aspect of Web development, a career can be made out of becoming knowledgeable on performance. A career can even be made out of becoming a Drupal performance expert (David Strauss is doing just that). I find for single-server sites there are 4 must-dos for performance. These are the biggest bang-for-the-buck performance improving techniques.

By default, views of type Term link to category pages (taxonomy/term/[tid]). I find that category pages are more useful as custom views where you can control fields. You can effectively replace the default category pages with a customized view by following this views recipe. And no programming is needed.

I am currently on a project that requires a 2-level drop down navigation and a sidebar block that displays the pages in the current section. This is not the first or second time I have used this recipe so it's time to share. This block can be used to display other pages in a section.

I wrote up a doc detailing Drupal related stuff that needs to be done to launch a Drupal site. Here is the info for discussion and anyone who finds this useful.

Drupal provides a clean way of formatting dates any way you want throughout the entire site.

Earlier today, Rachel commented that an upcoming events block on a site we are working on displayed the date in an ugly format. So I changed it and for anyone who is interested, here is the step-by-step process for doing so.

1. Create a date string

Here is a 5-step process to have full control over the output of a node. This method lets you stay at the theme/display level and gives you full control over output without having to implement any hooks in a module. You'll often find that you can get the desired output without resorting to any PHP template or HTML coding using the first two steps.

First: Edit the order of fields

From the content type edit page, click on the Manage fields tab. The URL is admin/content/node-type/[mynodetype]/fields
From here, drag and drop the fields in the order you want them displayed.

Adding the following code in any PHP area in Drupal will give you settings values available client-side that you can use when writing JavaScript code.

Pass a key/value associative array to drupal_add_js() and give it type value of 'setting'. Note that I am using an array of arrays with the key of the first array as the name of the module. This is to namespace the settings. This will keep your settings from overriding others and others from overriding yours.

//PHP code in your module or in a PHP snippet anywhere on your site
 
$jquery_settings = array(
  'myModule' => array(
    'mySetting1' => 'myvalue1', 
    'mySetting2' => 'myvalue2' )
);
drupal_add_js($jquery_settings, 'setting');

Here is the node skeleton for Drupal 6 for anyone who cares and for me to reference :)

This contains hook_views_api which requires the views module. The code inside the implementation of hook_views_api assumes views exports are in mymodule/includes/*

The code inside hook_enable assumes that there is a cck export located in mymodule/includes/mymodule.cck

<?php
// $Id$
 
/**
 * @file
 * Provides a "mymodule" node type.
 * 
 * @author Dustin Currie <dustinc@getlevelten.com> & Tom McCracken <tomm@getlevelten.com>
 */
 
/**
 * Implementation of hook_node_info().
 */
function mymodule_node_info() {
  // We return an array since a module can define multiple node types.
  // We're only defining one node type, type 'mymodule'.
  return array(
    'mymodule' => array(
    'name' => t('My Node Type'), // Human readable name. Required.
    'module' => 'mymodule',  // Machine readable name. (alphanueric, '_' only) Required.
    'description' => t('My Custom Node Type'), // Required.
    'has_title' => TRUE,
    'title_label' => t('Title'),
    'has_body' => TRUE,
    'body_label' => t('Content'),
    'min_word_count' => 0,
    'locked' => TRUE
    )
  );
}

If you create a content type through the administration menu that content type (i.e. mynodetype) will be derived from the node module. If you want to extend functionality of that content type by providing hooks, you cannot do it by creating a new module with the name of the content type (i.e. mycontenttype.module) and enabling it. If you try that Drupal will still see the content type deriving from node.module.