drupal 7

Drupal Core provides a central caching system. If your module has needs for caching that fall outside the default cache tables, it can have its own cache table (or bin) that uses the same interfaces.

Adding a custom cache table is as simple as adding it to the site's install schema.

Drupal 7

Quite often a site needs to log important events from custom code. Use the watchdog. I'm getting slightly less descriptive in my introductions.

Sometimes doing a full node_save/entity_save on an entity is overkill, like when updating a single field's value and not needing anything else to change.

This can be achieved by doing part of the complete entity_save function - prepare, update, and flush caches.

The weight of a module determines the ordering in which it will be called during callback hooks. eg Given 2 modules which implement hook_menu_alter(), the one with weight 0 will run before the one with weight 10.

If you know the weight that a module needs to be, and you can be very sure that no other module might get in there and change it, it can just be set statically.

Sometimes, when the brown stuff has hit the proverbial, there is a need to manually insert a single node back into the database with its original node id.

For Drupal 7 it is quite easy no add one back in and end up with an empty node which can then be edited to add the information via the normal interface, but if you have the comment module installed at all, it will throw errors that you haven't got $comment_count defined even if that content type never had comments attached to it ever!

ImageCache was the Drupal 6 way of doing things when you wanted a modified version of an already existing image on the site. Instead of manually manipulating the image and keeping a copy of it manually, you could setup an ImageCache preset which would be used to manipulate the image automatically.

In Drupal 7, this functionality is now in the core and it has also gone through some subtle changes to keep up with changes in the core.

Drupal has an inbuilt caching system, but it needs to be used effectively to get any benefit from it. For data accessed many times during the same request, data should be statically cached. If it's consistent over a longer period of time, it should also be added to the core cache.

The following is my template code that I used any time I need to pull something from the cache. I modify it based on what I expect to happen to the data.

Separate out files ... reduce code loaded for most pages since main module files are loaded for every page load. Moving all code that isn't needed on every page load to different files speeds things up. Maybe. It sounds good in theory.

To make Drupal search for the default form_alter, and any other custom form, the module needs to hook_hook_info_alter().