Wise Bread has been very popular on Digg the last few weeks. Every time we get Dugg, the server crawls. We've been making incremental tweaks, but today, we found a tweak that relieved all the pressure at once:

Throttle the statistics module!

It's been said before, but we didn't do it in order to preserve the list of popular today/all-time articles in the sidebar. Everything else we throttled. For previous Diggings, that level of throttling along with making the popular article a static file was just enough to make the site load very slowly. (That's better than when we were getting WSOD or 503 unavailables.)

Today when the number of anonymous users online stayed high (around 1800) for a couple of hours (and the site was unresponsive), we knew more stuff had to go. As soon as we throttled statistics, search and comments, the load on the server dropped to zero. We ended up unthrottling comments and the load was still acceptable, so we'll keep that on. But definitely no more statistics during high load conditions.

Bottom line: If you want your content (at least the article) to be read during a Digging, throttle aggressively. Throw out everything except the article itself if you have to!

If you want to call a function from another module, use the module_invoke() hook instead of calling the function directly.

I ran into a situation where we had to throttled the statistics module. Errors started being thrown to the page because I was calling statistics_get() in my theme. Here's the code:

      if ( module_exists('statistics') && user_access('view post access counter') ) {
        $statistics = statistics_get($node->nid);
        if ($statistics) {
          $mylinks[] = format_plural($statistics['totalcount'], '1 read total', '@count reads total');
          $mylinks[] = format_plural($statistics['daycount'], '1 read today', '@count reads today');
        }
      }

We were getting into trouble with the statistics_get() call in the second line. As you can see, even though we check for the existence of the module first with module_exists('statistics'), it didn't cover the case when the statistics module is enabled but throttled.

By using module_invoke() instead, this block won't throw errors even if the referred module is disabled or throttled.

To construct a module_invoke() call, simply make the 1st argument the name of the module, the 2nd the part of the function name after modulename_ (called the "hook" in Drupal speak), and the remaining arguments are what should be passed on to the function.

So this: statistics_get($node->nid)

Becomes this: module_invoke('statistics', 'get', $node->nid)

Back to my real world example. My above code that threw errors when statistics was throttled works perfectly fine after changing it to this:

      if ( module_exists('statistics') && user_access('view post access counter') ) {
        $statistics = module_invoke('statistics', 'get', $node->nid);
        if ($statistics) {
          $mylinks[] = format_plural($statistics['totalcount'], '1 read total', '@count reads total');
  

There is a theme() function in the Drupal tinymce module that lets you (the admin/webmaster) turn off the rich text editor on a field by field basis.

Basic steps to disable TinyMCE in a specific Drupal form field:

1. Look in your modules/tinymce/tinymce.module file.
2. Search for "theme_tinymce_theme".
3. Copy the entire function to your theme's template.php file.
4. Rename the function from theme_tinymce_theme() to yourthemename_tinymce_theme(). (Substitute "yourthemename" for your theme's name.)
5. Add a line to the switch($textarea_name){} block that specifies the name of the textarea you would like to exclude. Use the existing examples as a guide.

I wanted to disable the RTE for a custom plain text field in the node edit form. The field's name is "field-teaser-0-value". This is the line I added (marked with "KA") with some surrounding logic: (The fully modified theme that I put into my template.php is at the end of the post.)

function theme_tinymce_theme($init, $textarea_name, $theme_name, $is_running) {
  switch ($textarea_name) {
    case 'field-teaser-0-value': // KA: blog teaser (we want plain text only)
      unset($init);
      break;
  }
}

To find the name of the field in question, load the form in your browser. Check the source code. Look for the name="" attribute for your field. That's the string you insert into the theme function.

Tip! For CCK (content) fields where the name is something like "field_teaser[0][value]", you need to replace the non-alphanumeric characters with a dash. So the $textarea_name variable for this field is actually written as "field-teaser-0-value".

Here's the final customized theme function I placed in my theme's template.php file. My theme is called "avocadoshake" and my comments are marked with a "KA".

This is Dries' approximation of the Drupal learning curve. I think it's a pretty accurate visual representation of walking the Drupal path.

I'm just starting to cross into the "I kick ass" level. Woo!

Drupal definitely had a tough starting curve, but the D5 release went a looong way towards fixing that. The proof is in the explosion of drupal.org nodes and the number of modules that have since been released. Drupal is crossing into upper echelons of CMSes.

Here's a small patch to make the similar module output absolute links. This is useful because we use this content in our feed. Relative links just don't work outside the site.

Update (8/17): This feature was already in the 5.x-1.x-dev version. Use that instead.

I submitted my second patch to a Drupal module. This one allows the user to use custom feed domains (eg., feeds.killeraces.com) with the FeedBurner module. (The FB module is freakin' awesome. One of the biggest things we got from the D5 upgrade, IMHO.)

That's right. Multiple open source contributions. Yup yup. I'm hardcore.

BTW, MyBrand is now free for all. Go make your own feed domains.

The footermap module causes a WSOD upon enabling.

To recover, go into mysql and run the following to disable the module:

update system set status = 0 where name = 'footermap';

I've installed yet another CMS over yet another decrepit blog/website. This time it's Drupal overwriting a long neglected Wordpress install. Long time coming.

I don't think anyone other than spam bots were reading the previous incarnation of avocadoshake, but I should try to import the handful of WP posts. I wonder if I can still get those posts stuck in MT from two generations ago...

I just watched Dries' State of Drupal talk from the Open Source CMS Summit at Yahoo! in March.

Here's what he discussed (based on my shoddy memory):

Scale - focus on support and security.

Innovations in core.

We've eliminated the webmaster. CCK and Views eliminates the developer. Can we further remove the developer and even eliminate the designer.

Work with web services. OpenID, Amazon S3. Data API.

Critical features Drupal needs to "catch up" on:

- lightweight assest management
- structuring pages in heirarchies
- forum module improvements - learn from other forums, flatforum. Reworking comment system for more flexible handling of data.

Amen to the lightweight asset system. Image + img_assist, IMCE, upload module, ... are all awkward.