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 -
With OS X Lion and the new XCode 4.3, locations have changed and SDKs are no longer available. The current Acquia documentation also no longer works. I have begun compiling extensions using the following trick -
CFLAGS='-arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5' ./configure --with-php-config=/Applications/acquia-drupal/php5_3/bin/php-config
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
Many enterprise clients rely on LDAP as their authentication and authorization provider for their websites. LDAP is used to store all of this information, the infrastructure already exists, so why not use it? There are plenty of reasons. So much so that I don't know if I can ever "recommend" a client directly integrate their web site with LDAP again.
pecl download uploadprogress
tar xzf uploadprogress-184.108.40.206.tgz
cp modules/uploadprogress.so ~/php-extensions/
cat >> ~/public_html/fcgi-bin/php.ini <<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.
Even though taxonomy terms can now have fields, there are still some big differences with nodes that prevent them from being true equals. When deciding whether you should create content as nodes or terms, there are a few differences to consider -
Taxonomy terms have no workflow. There is no concept of a published or unpublished taxonomy term. If terms need any sort of approval or moderation, you should consider a content type.
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.
At some recent clients, Drupal has been used purely as an input method for content to then be pushed into other systems. Although the Services module provides a decent method for receiving content, there appears to be no modules that allow nodes to be easily pushed out of Drupal into other systems in configurable formats (e.g. JSON or XML). I've started a new sandbox project on Drupal.org named Node Push to solve this problem.
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.
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.