The Date module creates a standardized way to interface with date fields across many different data types. When creating a custom module that creates its own date or timestamp field, you may want to take advantage of common functionality, such as easy Views integration with popup exposed filters.

To accomplish this, there are two hooks that you must implement in your existing module -

Just like any other component in a server stack, it is important to be able to isolate the performance of each server to granularly test small configuration changes. Apache ships with ab for this purpose. Memcached has the memslap program provided by libMemcached. To run tests, we'll start two small Memcached servers on the local machine -
$ memcached -d -m 256 -p 11211
$ memcached -d -m 256 -p 11212

pair Networks

cd /tmp/ewebb/
pecl download uploadprogress
tar xzf uploadprogress-1.0.3.1.tgz
cd uploadprogress-1.0.3.1
phpize
./configure
make
make test
mkdir ~/php-extensions
cp modules/uploadprogress.so ~/php-extensions/
cat >> ~/public_html/fcgi-bin/php.ini <<EOF
[uploadprogress]
extension=/usr/home/ewebb/php-extensions/uploadprogress.so
EOF

Since Red Hat Enterprise Linux (RHEL) 5 came out in March 2007, it has become quite long-in-the-tooth compared to Ubuntu and other flavors with much faster release cycles. It's of course Red Hat's policy not to upgrade components to ensure the maximum amount of backward compatibility, so this lag is to be expected. Additionally many Red Hat support customers are weary of installing packages from other repositories like EPEL or freshrpms. Thankfully RHEL 5.6 added the ability to run PHP 5.3, but most other components were still missing and out-of-date.

At a client this week, I struggled to find an easy way to change the links to all taxonomy terms. I tried using template_preprocess_field(), but that only covered the uses of taxonomy terms with fields. Taxonomy terms can be used in other places and it simply didn't make sense to involve the Field API; there must be something more universal.

Last weekend I gave two presentations at Drupalcamp South Carolina as part of the Southeast Linuxfest. I also attended last year, which was the very first Drupalcamp that I had attended. It was an awesome experience and has directly led to the involvement I now have in presenting all over the US, and soon in Europe as well. This year, however, was very disappointing to me. The turnout seemed substantially less than last year.

The menu system in Drupal is known to most people as "that thing in the cache I have to constantly clear to find my links!" That is true. Also, it's a vastly powerful framework for, not just managing your URLs, but adding context and power around the URLs themselves.

Load functions

The following menu item receives a single argument to the URL, an ID for some data -

When values don't change between requests (unlike static variables), Drupal's caching system is a great, simple way to reduce the workload on your site and provide a flexible way to configure the storage duration of this data. Using just our handy cache_get() and cache_set() functions, we can implement an elegant solution to increasing performance across a stateless application.