Just a quick post to save anyone else that runs into this. If you've created something like ajax.php to handle some minor requests outside of your primary Drupal install but you need access to things like the $user object or the PHP $_SESSION variables, you can simply bootstrap Drupal at the top of ajax.php as you need:
I put together a small module for a recent project that extends Webform to include a "roster" form. Basically, you can assign Webform B to be the roster form for Webform A. When a user completes Webform A they're sent a link to complete Webform B. This link can be used an infinite number of times, so the original user could fill out Webform B immediately, or send the link to a dozen others (which is what my needs are). All of the Webform B submissions are tied to the original Webform A's submission, and show up when viewing that original submission.
I can't stand the over-use of contrib modules when they just aren't necessary. When a visitor loads your Drupal front page, all of your modules are opened and read by the server whether they affect the front page or not. PHP searches files for hooks that need to be fired, a huge number of database requests are made that don't necessarily have a purpose, and on the list goes. Why use modules that perform tasks already available to you such as including a JS library in your theme's folder, firing a trigger/action when a user logs in, or building your own custom content type?
It can be a bit confusing to create a custom theme for Drupal. Users new to this process typically hack a core theme like Garland, or grab a starting theme from the repository, but then it's easy to get frustrated with all the different template files, functions, and styles. After all, what are these extra functions? Why aren't they included in Drupal's core if they're so necessary? Why do I see page.tpl.php and a bunch of node-*.tpl.php files and a dozen other .php and misc files? I'll try to cover some of the basic concepts of Drupal theming and get into the more advanced stuff in later posts. My goal here is to really break things down on a simple, linear level.
The function behind the $node object is node_load(). This brings the $node object into play within your node.tpl.php template file and gives you the ability to display any variables from the node. Drupal handles everything behind the scenes -- access permissions, attached taxonomy, attached files, meta information, and more -- and hands you the gift wrapped object. In addition to the core variables, the node object also includes any added variables, such as CCK fields.
I hear complaints in the community that many of the core and other free themes that are available for Drupal are too stock looking. While a lot of them tend to leave aesthetics at the door (and there are reasons for this) there are also some great free themes available. Here's a handful that I have turned to, either to build upon or use as-is for small sites:
I stumbled upon Mail Carbon the other day, a great little open source app @ sourceforge (http://mailcarbon.calfater.com/) that allows you to specify 2 IMAP servers & the user's account information, which then transfers all of the email from the old to the new, maintaining hierarchy (folders) and all of the good stuff that we get out of IMAP.
It's always cool to see large organizations implement Drupal. Acronis (software vendor specializing in backup and disk utility apps) has leveraged the power of Drupal's core node and taxonomy systems, as well as powerful modules like webform, to provide their community with an intuitive, simple, and well-mapped system -- at a fraction of what it would cost them to have built it from scratch.