SELECT
field_website_logo_fid,
field_website_logo_list,
field_website_logo_data
FROM content_type_website
LIMIT 1

When I perform this query I get:

fid: 1723
list: 1
data: a:10:{s:8:"duration"; i:0; s:6:"height"; i:0;s:5:"width"; i:0;s:18:"audio_bitrate_mode"; s:0:""; s:18:"audio_channel_mode";s:0:""; s:12:"audio_format"; s:0:""; s:13:"audio_bitrate"; i:0; s:17:"audio_sample_rate"; i:0; s:3:"alt"; s:0:""; s:5:"title"; s:0:"";}

You’ll notice that none of these values give anything obviously meaningful to work with, and this can be confusing because as you can see, there isn’t anything obvious here (to me anyway) that looks like an image path, or that can be used to construct an image path. You might be able to guess that the fid value can be used as a look up on another table to get more information about the image (which it can by the way), but you’d need to find that table and either do a join or an additional look up to find that out. Rather that doing that, the easiest method that I’ve come across to find the path of the image (if you know the fid value) is to use the field_file_load function like so:

$file = field_file_load($node->website_logo_fid);
$filepath = $file['filepath'];

You could then put the $filepath directly into an image:

print '<img src="/'.$filepath.'" alt="" />';

Bear in mind that you might need to consider the base path before the $filepath.

The other instance that you might want to retrieve an image path from a CCK image field, is from within a template file. If you know the name of the CCK image field, then you can retrieve the path by doing something like:

$field_website_logo[0]['filepath'];

• possess rules that clash, or are made redundant by rules that you already have in place
• control aspects of the module administration that a user would never see
• cater for features that the module provides that you don’t need, or haven’t activated
• offer browser and device support that is not part of the site requirements
• you have themed a modules mark-up, thus rendering its own stylesheet obsolete

Generally there is no easy way, or no way at all to disable these stylesheets from the admin or module settings.

If you took a typical Drupal setup with a Zen starter theme and add about 10 of the popular modules, it wouldn’t be unthinkable for the number of stylesheets to breach the 20 mark! 20 stylesheets!

Even before you start adding your own stylesheets...

I know that the stylesheets can be cached and served as one file, but when you’re debugging the CSS and adding new sections to a site of any real size, you will inevitably end up playing specificity wars and having to reset rule properties more often than you’d like. This all leads to bloated CSS that is a pain to debug and maintain.

To overcome this in the past and regain some sort of control over what CSS ends up on the site, I have adopted a code butchers approach and taken to ripping out the line seen below in the page.tpl.php file, and then just manually adding the stylesheets in the html.

print $styles; //bye, bye

That’s a problem solved, but another problem created in that sometimes you do actually want a modules stylesheet to be used. Determining the CSS file location(s) that a module uses can be difficult, especially when there are configuration options within a module that force different sets of stylesheets to be used such as in the popular fivestar module.

I’m sure there are probably better, cleaner ways to achieve this, but what I do now is cull the Zen starter theme.info of all superfluous stylesheets and then add the phptemplate_preprocess_page function within the template.php file with code that removes the remaining unwanted stylesheets, like so:

function phptemplate_preprocess_page(&$vars){
	//Get the loaded stylesheets as an array
	$stylesheets = drupal_add_css();
 
	//Remove the default style sheets
	unset($stylesheets['all']['module'] ['modules/aggregator/aggregator.css']);
	unset($stylesheets['all']['module'] ['modules/node/node.css']);
	unset($stylesheets['all']['module'] ['modules/system/defaults.css']);
	unset($stylesheets['all']['module'] ['modules/system/system.css']);
	unset($stylesheets['all']['module'] ['modules/system/system-menus.css']);
	unset($stylesheets['all']['module'] ['modules/taxonomy/taxonomy.css']);
	unset($stylesheets['all']['module'] ['modules/user/user.css']);
 
	//Remove some of the popular module stylesheets - add / remove your own here
	unset($stylesheets['all']['module'] ['sites/all/modules/cck/modules/fieldgroup/fieldgroup.css']);
	unset($stylesheets['all']['module'] ['sites/all/modules/cck/theme/content-module.css']);
	unset($stylesheets['all']['module'] ['sites/all/modules/date/date.css']);
	unset($stylesheets['all']['module'] ['sites/all/modules/filefield/filefield.css']);
	unset($stylesheets['all']['module'] ['sites/all/modules/link/link.css']);
 
	//Set the styles
	$vars['styles'] = drupal_get_css($stylesheets);
}

This function will do the trick for all of the Drupal system stylesheets and a few of the popular modules. There is a big drawback to all this stylesheet optimisation of course, which is you’ll notice that your admin area falls apart and becomes completely unusable due to the fact that the supporting stylesheets aren’t present. To overcome this is simple in most cases – you just need to set your administration theme (Administer -> Site Configuration -> Administration theme) to use a different theme and all module stylesheets will be pulled in – I usually go for the comforting shades of Garland.

If you have a node that you know the node ID for, but you don’t know what the full clean url is (or how to generate it), then there is a handy function you should know about called drupal_lookup_path() that will get the full clean (pathauto) path for you. For example, a typical Drupal relative path such as:

/node/9999

Is easy to generate if you know the node ID, but if you pass it through the drupal_lookup_path function like so:

drupal_lookup_path('alias',"node/".$node->nid)

Then you will get the full clean path of the node based on the rules set out in the pathauto module. For example:

/band/future-of-the-left

This is very important for SEO. If the exact same content/page can exist on two different urls on your site, then you will run into problems with duplicate content and will have to start using things like the canonical link element to fix a problem that shouldn’t have been created in the first place.

In Drupal, the two most popular ways of controlling your meta keywords and descriptions are using the modules:

• Node Words
• Integrated Meta Tags

Both are very good and offer a range of options that allow meta keywords and descriptions to be automatically set for a node of a given content type, but occasionally you’ll find that they just don’t give you the level of control that you require.

Step forward the Drupal “drupal_set_html_head” function – this allows you to add any code you like to the document <head>.

This is the function that I use to set the meta and title tags from within a page/template in Drupal:

function setTitleAndMeta($title = null, $metaK = null, $metaD = null){
	drupal_set_title($title);   //Set page title
	$metaDescription = "<meta name=\"description\" content=\"$metaD\" />";
	$metaKeywords = "<meta name=\"keywords\" content=\"$metaK\" />";
	$meta = $metaKeywords . $metaDescription;
	drupal_set_html_head($meta);
}

Pretty simple huh? A typical call might look like:

setTitleAndMeta("motorbikes | daipratt.co.uk", "motorbikes, gsxr, donors", "I really hope that motorcyclist has signed his organ donor card. If he keeps riding like that and he won't need them anymore.");

The pipe-delimited CSV file that I was using looked something like:

"string"|"string"|"checkbox integer 1,checkbox integer 2, checkbox integer 3"|"string"

e.g.

"dave"|"test"|"2,8,10"|"test"

But for some inexplicable reason the data just wouldn’t import. After many failed attempts and a fair bit of Googling, I stumbled across a solution in the Drupal forums. What I had to do was patch the module with the file: optionswidgets.inc from CVS and drop it into the node_import module directory

sites/all/modules/node_import/supported/cck

And the import continues…

<?php echo date("D, j M Y \a\\t G:i", $created_date) ?>

For example, if created_date were to equal “1249641973″, it would get rendered as “Fri, 7 Aug 2009 at 11:46″. Nice.

This sneaky bit of code will delete all records of a particular type (just replace the #### appropriately):

$query = db_query("SELECT n.nid FROM {node} n WHERE n.type = '####'");
while ($n = db_fetch_object($query)) {
	node_delete($n->nid);
}

Careful!

UPDATE:
There is a far better way of doing this: if you activate the Devel module, and then use the following line of code:

//Delete all data of content type "event":
devel_generate_content_kill(array('node_types' => array('event')));