Practical Performance Benchmarking, and Tuning

Section:

As promised here are my slides, a few corrections, and some links to further resources. 

Building Custom Panel Panes (CTools Content Types) in Drupal 7

Section:

Content types (a.k.a. panel panes) are one of CTools' most visible, versatile, and easy to learn APIs. In this tutorial, we're going to build a custom content type (or panel pane depending on what you call it) that display's a twitter user's latest feeds. As with any new CTools content type, you need to have at minimum three files in following structure:

Hitler Finds Out That Drupal 7 Might Release Without Panels

Section:

Hitler finds out that that Panels might not be ready for Drupal 7.0 at a recent Hitler's Drupal Users meetup.

Note this another Hitler downfall video, which i find to be hilarious

Interested in proving Hitler wrong?

1, Issue for Ctools Update
2. (dependent on ctools update) Issue for panels.

Link to youtube.

A Belligerent Rant on Design Centered Websites with Poor Communication Skills

Please be seated for my sermon. There's an evil force out there, and its responsible for the majority of failed websites. This force seduces you into focusing too much on questions like:

"Is that the right shade of blue? Would a drop shadow make that element pop? Why do links have to look ugly, can't we tone them down so they bend in better with the design?"

The evil force wants you to focus on those dumb questions so that ignore the really important questions:

40+ Essential Drupal Modules

Section:

If you are new to drupal, then this list is for you. These are some of the best of the best drupal modules. Everything from standard framework modules, to location and mapping is covered. Note that if you've been emersed in drupal for some time, than this will be "old news".

The Big Three

"The big three" are important enough that they deserve a category of their own. Most drupal modules worth using have integrated with one of these three. Their importance simply can't be stressed enough.

  • Content Construction Kit (CCK) - Part of drupal 7; still a contrib in drupal 6. Allows you to define new content types (e.g. blog entry, event, or employee record...) and add "fields" to them. A field could be plain text, an image, a flash video, or whatever. You can also adjust how these fields display in the live view. No drupal install should be without this module.
  • Views - Broadly speaking, this module empowers non programmers to build dynamic streams of content displaying any number of fields. The content may come from nodes (a.k.a. content types and fields), users, system log entries, etc. You can display this stream in any number of formats including RSS feeds, tables, or just the vanilla view for a content type. You can also create pages or blocks -- its very tightly interwoven with drupal. Nearly every drupal module worth using is integrated with this module. Extremely powerful when used in combination with CCK.
  • Panels -

    I believe Panels + CCK & Views is a hint at what drupal will look like 3 years into the future. I had to change my pants after the first time I witnessed it. At a very simple level, you could think of it as a layout manager. Create a 1,2,3 column layout. Or a 3 column layout with a full width footer and header, and plop pieces of content in them -- say a view, a block, or a node. That description, however does not do it justice. Since version 3, its positioned itself as a replacement for drupal core's clunky block system. It can now override a node page, and can be used to place content all over the place. It also introduced a concept of contexts, selections rules, and relationships. These are concepts that deserve a series of blog posts, but lets just say its solving some of the weirdest, mind numbing, bug creating problems found in advanced websites. Ironically, I used to hate this module, but after version 3 I will defend its awesomeness to the death!

jQuery UI ,Drupal, and Behaviors Slides

Section:

Slides from a presentation I did today @ drupal camp austin. Will expand on Drupal.behaviors in a later post.

Note to self: pick an easier topic for next presentation

Switching Drupal tpl.php files at will: Old Switchy McTipplefep's Trick

Section:

One of the first lessons they teach you at the School of Drupal Arts, Arcane Sciences and Sorcery is that a tpl.php can have dynamically generated wildcards or "suggestions". You can see this every day drupal themes: you can simply use the "node.tpl.php" file if you want only one style for a node. Where as if you want different styles for three node types: blog, story & page, you create the following files:
  • node-page.tpl.php
  • node-story.tpl.php
  • node-blog.tpl.php
Obviously, this pattern exists far beyond nodes. For page.tpl.php, user/register can have its own tpl.php file:
  • page-user-register.tpl.php
Where as user/1/edit will be (yes -- these suggestions will remove numbers... i think... i was hung over that day in class):
  • page-user-edit.tpl.php
This may be fine and dandy if your agenda is either to build a simple drupal theme with a few exceptions, or to build manly Texas sized drupal themes with enough tpl.php files, and duplicate html code to choke a donkey. Old Switchy McTipplefep's trick is for anyone who:
  • wants 3 styles that are shared by 20 blocks
  • wants 4 possible layouts for dozens of pages in a site
  • has 12 node types, but wants them to share 3 styles
The magic happens in your theme's $theme_name . '_preprocess_' . $theme function. Below are examples for how a theme named "example" would do it.
function example_preprocess_node(&$vars) {
  $node = $vars['node'];
 // only switch for story type
  switch($node->type) {
    case 'story':
      $vars['template_files'][] = 'node-batman';
      break;
  }
}

function example_preprocess_block(&$vars) {
  // sure why not -- we'll pass our node.tpl.php file to our block
  // That's how tpl pimpin works sometimes
  $vars['template_files'][] = 'node-batman';
}

Architecture is for Everyone: The Path to a More Humane Drupal API

Eaton's presentation on Architecture & Drupal is by far the best of the 12 or so drupalcon presentations I've watched so far (they were all good, but this one just seems to stand out). If you missed it, its worth your time.

http://www.archive.org/details/Architectureisforeveryone

A Damn Simple Technique For Making Anything in Drupal Ajaxed*

*well, probably anything that uses drupal.behaviors...

Today, I was doing a few experiments on how to get several giant CCK node forms to load and submit via ajax from a single custom page.When this technique actually worked on the first try, my exact words were "no f#cking s#it..." I'm sure I'm not the first to figure this trick out, but I have had a hard time finding people who've described it. Perhaps everyone besides me figured it out ages ago -- though if that's true, I don't want to know what horrible things have driven some of you to use your current techniques.

This technique seems especially ideal for integrating any existing drupal form (especially giant CCK forms with sortable, multiple value, file fields), and the results into some highly customized drupal based web gizmo. *IT REQUIRES NO PHP* beyond whatever calls you may have to make to get dependent JavaScript files available to your requesting page. This pattern will mostly degrade to drupal's default behavior if JavaScript isn't present.

The stupid simple strategy

We use javascript to take what we want from drupal's default behavior, and throw away everything else.

Below, is all you need to submit a giant CCK form and have it successfully post:

//node form just happens to be the ID shared by every node form
//replace #node-form with any form ID and the results are the same
$('#node-form').submit( function() {
  $.post($(this).attr('action'), $(this).serialize(), function(response) {
  // ...
  }
  // return false prevents the form from submitting regularly ... noob...
  return false;
});

Even though the user will not be redirected or see any results of this $_POST, jquery will still follow the default redirect to node/$node->nid or return the original form with validation errors -- this is actually a good thing.

$('#node-form').submit( function() {
  $.post($(this).attr('action'), $(this).serialize(), function(response) {
   // why not, lets replace our logo with the resulting node
    $('#logo').replace($(response).find(.'node');
  }
  return false;
});

There's a few downsides I see to this technique: for one generating entire pages is totally unnecessarily; since we are simply taking contents of $(.node) from the result's full document object, why load the entire page? The answer is: the page already exists, and its one less menu_callback, loading, or godforbid form behavior altering trick that will cause bugs down the road. Its easy, it works, and all but the minority of websites would need to worry about the performance implications.

Another downside is that since we are using jQuery, we are depending on classes and ids that may eventually change. I think this is a real risk, but i think the risk can mostly be avoided by making intelligent decisions about what selectors you use. Besides, the maintenance hassle is probably still less compared to many of the alternatives.

Below is a working example: load a node "edit" tab, submit, and refresh the node all via ajax.

The code snippet is cute as a button, though its handling of validation is sort of half-assed. Note that the vast majority of code is devoted to simply throwing around the response data, the jquery itself is elementary.

Web Development:

Pages

Subscribe to Nick Lewis: The Blog RSS