Do you provide professional Drupal services and want to submit a session for Drupalcon SF? Talk to me!
I'm chairing the "Providing Professional Drupal Services" track for Drupalcon San Francisco in April and am looking for interesting sessions and speakers to help seed the Drupalcon sessions list. We already have some great folks on board. Sessions will be opened up for public submissions soon and the earlier your session gets added, the longer people have to vote on them.
So, if you're interested, ping me with your session idea. If you're looking for ideas, I've put together of potential subject matter for my track here, as well as a Drupalcon Talk Idea Generator to get your juices flowing.
Disclaimer and clarification: I posted this with the goal of connecting with people who are thinking about or have already prepared sessions for the track I'm chairing. I'm not in charge of fielding all Drupalcon session proposals and I won't be the one that decides which sessions ultimately get chosen, but I should be able to help folks with the submission process.
How to deal with cloning or dynamically loading new form elements (like radio buttons) in Internet Explorer (IE) using jQuery
It's a horrendously long blog title, I know, but I wanted to mash in all the keywords I was looking for when trying to find a solution to this very sticky problem so that other folks running into the same issue can spend the next six hours doing something more productive.
jQuery makes grabbing one group of elements from a page, duplicating them and adding them somewhere else really easy. You just use a combination of clone() and something like append(), as in the following:
$('#surrounding_div').clone().appendTo('#some_other_div);
The problem with dynamically adding form elements in IE
Woot! So easy! Right, until you start goofing with forms and IE (Internet Explorer) (appropriate sound). The problem is that IE doesn't allow you to manipulate the 'name' attribute in the DOM directly. So, something like this won't work:
$('#form_element').clone().attr('name', 'new-name').appendTo('#my-form);
If you do that with a radio button, the interface will tell you that there's a problem, because since the new radio button has the same name as the original one, only one can be selected. Bugger!
Luckily, the solution is clear, but it took forever to figure it out. Instead of adjusting the name attribute directly with something like attr(), you need to edit it manually in a block of html and then add that html to the page. So, something like this would work:
$('#form_element').parent().html().
replace(/orignal_name/, 'new_name').appendTo('#my-form');
There's a couple of key points here:
- Because we're getting the html using $.html(), we need to move up the DOM to grab the element surrounding the element we wish to add using $.parent(), then we can grab the html using $.html().
- I'm using the javascript replace() function to pass a regex pattern and replacement text to the html.
What about dynamically cloning groups of inputs with jQuery?
In my particular use case, I was grabbing a set of form elements and adding them this way. There were a couple of challenges, which was that I couldn't use $.parent() to get the outer element, and the other was that the names of the form elements were being set dynamically. I learned a couple of tricks to help with this:
Use the regex modifier /g to replace all insteances of a pattern. So, when doing replace(), if I needed to replace ALL instances instead of just one, it would look like this:
replace(/original_name/g, 'new_name')
Because I couldn't use $.parent(), in the end I had to wrap an element around the html using simple contatination, like so:
var newHTML = '<div>' + $('#element').html() + '</div>';
I hope that helps you, it was sure a bugger to figure out.
Video presentation on why Drupal kicks other CMS's a**
A couple weeks ago I put out a blog to garner feedback on why Drupal kicks serious a**, and a big thanks to everyone who responded. I integrated a number of the comments with my own personal experience with Drupal and presented my talk last week to a diverse group of 20 or so web tech people in the local Boise Idaho area. Judging from the audience participation, I think the presentation went really well. I recorded the talk (from two different camera angles, no less!) and am posting the video and slides for folks that are curious about what they missed, or who are interested in giving a similar talk themselves.
I did a little research before hand about how Drupal compares to popular CMSes like Joomla, Plone, Wordpress, ExpressionEngine, and SharePoint. The talk was also directed in many ways to audience members who have rolled their own CMS, because that was my experience coming into Drupal and I found that Drupal solved many of the problems I was attempting to solve myself, but in much more elegant ways.
Drupal kicking butt - Video and slideshow
The format of the talk was "10 ways Drupal (might) kick your CMS's a**", and here are the 10 things about Drupal that stand out to me as particularly steller:
#1 - The Drupal Community
The community is a big part of what keeps me involved in Drupal at the level I am. I helped found and participate in a local Drupal users group, which provides important face-to-face time with other people using the Drupal, and keeps us all abreast of important news in the project. I also talk about regional conferences and Drupalcon, IRC, and leadership in the community.
#2 - Central Module Repository
Drupal keeps all of its modules in one place, unlike many other CMSes. This has many benefits, and has helped to keep significant licensing problems to be an issue in the community. Also, a standard module release process allows both developers and administrators to have a clear path forward with module upgrades and choosing the correct module version for the Drupal version they use
#3 - Drupal is a Framework
For developers, Drupal does a lot of heavy lifting and really lets you get plugged virtually anywhere in the platform. The module structure encourages good coding practices and good organization.
#4 - Drupal is Mature
Drupal has been actively developed for 8 years, and lots of big web sites are using it, like the White House, The Onion, Fast Company, BMG Records, NASA, Warner Brothers and Yahoo Research. Even if you don't understand the nuances of security and scalability, you can point to hear examples of how Drupal must provide a solid framework for both.
#5 - Flexible Data Structures
Drupal allows you to create flexible content, much like Access or Filemaker, and even creates full CRUD (Add, edit, view and delete forms) on the fly. So, storing custom content is easy, and doesn't require any programming or touching the database. (video includes demo)
#6 - Flexible Content Feed Output
Once you have content, you have many options for how you want to output the data. You can pass content filters via the URL or even expose filters to users so they can narrow down content based on whatever criteria you specify. The ability to generate these lists of data via configuration without touching queries or code can be a powerful administrative tool.
#7 - Flexible Path Aliasing
In Drupal, you can specify how you want a path to look based on virtually any information in your content, including title, date, or custom fields. Drupal can handle redirecting duplicate URLs (also called aliases) to a single URL with a 301 redirect to prevent a duplicate content filter in search engines.
#8 - Multi-Language Support
Including another language is trivial, and you can even override content within the same language. There's community infrastructure to support translators even if they don't know how to use, install or develop in Drupal.
#9 - Making Forms is a Breeze
Creating forms in Drupal is as easy as creating content types, and can be done without any programming. If you do need to program a form, however, there is a powerful API which will allow you to generate a secure, robust form in just a couple of steps. There is also a nice utility for generating module configuration forms.
#10 - A Bunch of Other Stuff
Including distributions for intranets and social aggregation, cross-database compatibility, an active usability team, hierarchical taxonomy, a powerful theme layer and AJAX framework.
Post-presentation discussion
During and after the presentation, there were a lot of great questions and discussion about topics like:
- How does Drupal store content types?
- Can Drupal work with obscure databases like BDB?
- How do you create a wiki in Drupal?
- How much does Drupal break from one version to the next?
- How difficult is the upgrade process from one Drupal version to the next?
- How much of this stuff is handled by core Drupal, and how much by contributed modules?
- What versions of MySQL and PHP are the different Drupal versions compatible with?
- How many people non-developers use Drupal?
- Discussion on ecommerce solutions for Drupal
"10 reasons why Drupal (might) kick your CMS's a**" - Crowdsourcing an upcoming talk
I'm going to be doing a talk in a couple of weeks called "10 reasons why Drupal (might) kick your CMS's a**" to a local group of web tech folks, only a couple of which use Drupal. I have some ideas, but wanted to crowdsource this a bit and see if I can get some input from the community. I have a very limited exposure to other popular CMS's, so any input on comparing and contrasting Jooma, Wordpress and Drupal would be appreciated. Also, any nifty graphs or diagrams that might hit the points home? So far, here are some items on my list:
- Caching - The various caching tools enable Drupal to perform nearly as fast as static HTML
- Community - Lots of IRC participation, local user groups, positive leadership
- No forking - The community hasn't yet reached the point where a schism caused forking.
- Central module repository - This has meant that all projects are supported in similar ways (version control, issue queues, etc) and that they are GPL compliant. Also, this adds exposure for the modules and they get vetted by the community.
- Drupal is a programming framework plus a CMS - Drupal does a lot of heavy lifting, and helps you organize your code in a meaningful way other folks can plg into.
- Drupal modules don't have to hack core to work - As opposed to other CMSs
- Drupal scales well - And this will only get better with Drupal 7 and the new database layer
- Drupal is mature - It's been around a while, it's stable and is being supported by a lot of big projects (need some good diagrams here)
- Extendable data structures (i.e. fields in core) - Makes all data flexible at the interface level
I'd love to have some good visuals for this, and I'd also like to get some ideas on what I might be missing. I will gladly open source this presentation as well once it's complete.
Thanks!
Review of Drupal 6 Search Engine Optimization and interview with Ben Finklea (or, the benefits of reviewing e-mail on drugs)
As part of this review process, I interviewed Ben Finklea. We covered his new book, "Drupal 6 Search Engine Optimization," as well as other interesting topics like how you might need to start your own church to write a book, what it's like to overcome the stigma of doing SEO, and what to expect in the future of search engines and Drupal 7. Listen to the interview here. (right-click and select 'save as' to download)
Props
I have a lot of respect for business owners forging new niches in the Drupal space. Not only has Ben Finkea done this, but he's done it in a niche that's rife with controversy. SEO as a subject is highly polarizing, and choosing it as the topic of a book directed at an open-source audience that highly values the transparency often neglected in the SEO sector seems downright masochistic. So, before even addressing the content of the book I have to applaud Ben's gumption. To have success in a controversial arena like this, I think you have to be quite skilled at filtering out and responding positively the inevitable negative feedback - something that's not always easy to do.
The book
To begin with, I think the name of this book is understandably misleading. While "Drupal 6 Search Engine Optimization" covers many topics related to optimizing a site for search engines, a large part of the book is dedicated to teaching the reader how to improve conversion rates, attract readers and organize content. I think this is a good thing, but going into the book knowing that a variety of non-SEO topics will be covered might allow the reader to enjoy it more.
I've had enough SEO experience to be a bit beyond the curve the book takes on, so I felt a little outside the target audience range. In spite of this, I still found a lot of value in it, and surprisingly this value was mostly in the material that wasn't directly SEO-related. Also, if I step back about 5 years to before I knew much about Drupal or SEO, the value multiplies significantly. If you're new to Drupal, sifting through the module repository to find ones that will help your site become more friendly to search engines is tricky, because they're not all labeled as such. The first part of the book introduces the reader to a variety of helpful modules and walks them through the steps required to configure them. Along the way, the reader is exposed to some basics concepts in SEO, such as the importance of targeting keywords, cleaning up URLs, dealing with redirects and the benefits of writing semantically-correct markup. If you find that you have too few tools in your SEO toolbox, then this initial coverage is important and will get you headed in the right direction. Pages 11-17 in particular lists out a number of useful SEO modules that are mentioned throughout the book, and this list alone is a great resource.
A number of more advanced topics are covered as well, including how to optimize your robots.txt file (something I don't have much experience in), and tips on speeding up your site. For a typical site maintainer who hasn't given much thought to optimizing their site for search engines, there is enough material here to keep busy for a while. And based on my knowledge of SEO, using the collection of tools Ben suggests is an excellent defensive strategy for getting your content indexed by search engines properly, without any fear of sketchy tactics getting your site penalized or banned.
At about page 150, SEO starts to take a back seat and traffic optimization takes the wheel. My favorite two sections in this second part are labeled "Don't Stop" and "Find Inspiration." Don't Stop is a short, single paragraph, but summarizes a principle that is just about the most essential aspect of building meaningful traffic, which is continuing to build content and keep things fresh - an excellent reminder. "Find Inspiration" is a list of around 20 suggestions for sources and structures you can build content from. Ben mentions that he refers to this list when he gets stuck, and I found the list useful enough that I'm going to start doing the same. Some suggestions include subscribing to Google Alerts, reviewing emails and questions from customers, and doing original research. If you've attempted to write on a regular basis, then you know that some days you're more inspired than others. There's something on this list for just about any level of inspiration.
Some interesting additional topics are covered in this second part, such as how to write compelling copy, organize large amounts of content and improve conversion rates, which are all very useful to those responsible for managing web site content.
Criticism
I understand that one book can't be everything to everybody, and this book serves its purpose well. However, If you have some experience with SEO, you'll notice that there are some notable omissions in this book. With controversial subject matter, one can be be bold, in-your-face, opinionated and passionate, taking a side and sticking with it. Or, one can be cautious and careful and avoid arguable material. This book takes the latter approach. It definitely outlines a clear path of SEO defense which useful material that is difficult to argue against, but leaves out a lot of the meaty bits I find most interesting about SEO. Subjects like inbound and outbound linking, link building campaigns, conducting tests against search engines to see how PageRank is transferred (and is it even important?). Link text - generally thought to be one of the most important aspects of passing value from one page to another - is only briefly mentioned. What about changing content on pages that have been indexed, or how search engines consider the longevity of links? The book but doesn't take the SEO talk further than the basics, which may be disappointing to some.
Those things being said, I recognized a number of suggestions in the book that I don't apply regularly enough, and the argument can be made as to the amount of good the material I'd like to hear about would do me if I'm not executing the essentials properly.
The only other criticism I have is that I would have liked to see more sources referenced. Matt Cutt's blog is mentioned briefly, but I would be really interested to see where the rest of the material came from or from where it was inspired. That kind of list would also be helpful for folks ready to dive a little deeper into SEO.
Summary
I think this book can provide a lot of value to new web development shops or freelancers. If you become familiar enough with the material it covers, you will have an arsenal of answers to tough questions you're inevitably going to get from potential customers regarding SEO and managing content. It will take a while to gather this information yourself, and the time it saves you will be worth the cost of the book.
As a new site administrator or owner of a site that needs to optimize its traffic sources, a lot can be gained from utilizing this book as a reference guide for writing and organizing content. As an intermediate Drupal user, I would suggest reviewing this book to make sure you're following the different strategies it outlines. If you find yourself running out of ideas for improving your site and building content, there's some excelent material in the second half of the book for you, too.
Interview notes
Ben was kind enough to interview with me, and some really interesting topics came up. One notable bit that got missed in the interview was that the book probably wouldn't have been written if Ben didn't get appendicitis and had been high on drugs in the hospital with nothing to do but find the bottom of his e-mail inbox. Here's a quick list of what you'll hear about:
- How the Drupal community has responded to an SEO company in their midst
- Is organic SEO dead?
- How will SEO in Drupal 7 be different?
- How are search engines changing and what can we do?
- Reflections and tips on writing a book (everyone should do it!)
- Listen to the interview here
CafePress vs Zazzle review part 1 - Black on White and White on dark American Apparel

One of the things that's been on my bucket list for a while is to start a t-shirt company. I'm surrounded by people with great artistic talents and keen senses of humor, and it seems a shame to let those ideas languish among such a small group, so what better way to spread them than by sporting them around all day on your upper body? CafePress is one of several services that let's you get started selling printed products without a serious outlay in funds. If you're designs take off, you can always take your designs to your own site. I also also ordered a shirt from Zazzle.com so I could compare and contrast. In case you're thinking about ordering some custom shirts, here's a couple of differences between the two services:
- CafePress is a significantly cheaper. It cost me around $20 for each shirt, and shipping was free. Zazzle cost $25 plus $4 shipping, making it a $29 shirt. I don't remember ever spending that on a t-shirt before.
- Zazzle has bigger printing area by 68 square inches. CafePress is 10x10, Zazzle is 12x14 and you can have it horizontal or vertical.
- Zazzle has a nice tool for seeing your shirt on a variety of models of different shapes and sizes. CafePress just has the shirt, no model.
- The process of designing the CafePress shirt went more smoothly and had a few more options.
I decided to start real simple and created a t-shirt around a misspoken phrase I heard the other day which gave me a nice laugh. It's a little obscure, but the project was designed to get me started with the creative process and test out the quality of printing over at CafePress. I also ordered a shirt to advertise one of my recent ventures at geeky events. I purposefully chose a single color, and did a light-on-dark and a dark-on-light to see the differences. Both came out pretty nice, with crisp edges and bold ink. I put them through a wash, and they didn't shrink or flake. The white ink is raised up like a typically silk screen shirt, and the black is more like a dye without any raising. The neck is a little tight, but the shirt (I ordered large, fitted American Apparel shirts) is soft and long - a feature severely lacking in a lot of men's t-shirts.
Once I get my Zazzle order I'll post a bit more contrasting the quality of the printing and shirts.
"Extreme Productivity" talk proposal for Ignite Boise 3
Several months ago I managed to grab some tickets to Ignite Boise 2 from a friend. It was the most fun I've had watching a live performance in a while. Half of it was the fast-paced, multi-faceted topics and presenters, and the other half was a jam-packed room full of slightly inebriated, vocal participants. It felt like there was no third wall, and that it was more of a sport than a sit-on-your-hands-and-listen gig. So, as my family eagerly awaits the availability of tickets (attendance is free, but you can get tickets to get in early), I decided to go ahead and submit a talk for Ignite Boise 3 in November. I've been on this planet for a while now, and I've gathered enough interesting techniques for getting the most out of living to fill a 5-minute slot.
Life is short, we should be spending more of it doing what makes us happy!
And this talk will summarize just about everything I've learned about how to do just that. In Extreme Productivity, I hope to introduce the uninitiated into a slew of techniques for increasing enthusiasm (the very core of productive living), outline a mindset that attracts opportunity, and lay down some principles - many backed by scientific research - that will help you get more done in the limited waking hours of our life (and maybe even the non-waking ones!). Here's the one-minute bullet-pointed run down of some of the topics I'll be covering:
- How to fit more in your head without a lobotomy
- Increase your waking
- How to make work suck way less
- The myth of multi-tasking
- Introducing multi-purposing
- The body is a truffle - How to use your body to please your mind
- How the people around you affect your attitude (and how you can affect their affect on you)
GTD (Getting Things Done inspired) free flow chart and fan t-shirt
I've been on a T-shirt designing kick lately, and put together a simple design for an upcoming talk I might be doing at the next Ignite Boise on Extreme Productivity. In the process of designing the shirt, I wasn't able to find a GPL / Creative Commons licensed flow chart of a GTD-inspired process, so I downloaded OmniGraffle and put together my first flow chart ever! I've packaged up the files (black and white and color versions, both OmniGraffle and a transparent high-resolution PNGs) which you can download below, licensed as Creative Commons.
Case study: Setting video file access based on Ubercart orders
One thing that's really nice about working on your own Drupal projects is that you get to share what you're working on (no NDAs, woot!). This particular project (Build a Module.com) is a video tutorial site for newer Drupal developers. For a while, I had a single product offering, but feedback made me realize that people like options. So, I decided to to offer single video purchases as well as 'collections,' or groups of videos bundled up into a single product. I also needed to make sure that customers had the right permissions set on files depending on their purchases.
Here's a video outlining the solution I came up with. Scroll down below the video for further details.
About the flow
I have 3 node types:
- Videos - Contains description and video file in a file field
- Single Video Product - Is an Ubercart product with a node reference CCK field pointing to a single video
- Collection Product - Another Ubercart product, but this one has a node reference CCK field that points to a number of videos
I didn't realize that a node reference field could point to multiple nodes before a fellow Drupalista pointed it out to me. Eesh! I really could have used that info a year ago.
So here's the flow:
- A user adds a Single Video Product or a collection to their cart
- They check out and complete the purchase
- They visit a video page
- A custom function checks against their orders to see if they have access to the video. If they do, they're in.
The function used in step 4 uses several queries to determine access. The queries check for the following:
- Is the product free? If so, show the video.
- Has the user purchased a product that includes the video file that this Single Video Product type points to?
- Same check for a Collection Product type
- If there is no product for the video, then give access (some videos, like the intro video, don't have an associated product)
In the hook_file_download, the same function is called, but I first have to figure out what node the file belongs to. In Drupal 6, hook_file_download only supplies you with the name of the file. No node associations or anything, so you have to connect the dots with your own query. I think the reasoning is that a file can belong to multiple nodes, but since my workflow doesn't allow that, it's not an issue.
There are some good things about this approach, such as when files change in the nodes (i.e. you upload a video with corrections), even though there is a new file name, the node association will remain the same and access will be granted.
For a while I was using a module called File Access, which allows you to set granular permissions for each file based on user or role, but because I would have to build a connector action between a purchase and the access, and then respond when new files are uploaded, I figured I would keep it simpler and just cross-reference the orders instead. The downside is that if my products change, so will access. Also, using File Access would enable access based on field, rather than on node. So, if I have two different versions of a file on the node (iPod version and full-size) and wanted to sell them separately, I would need something more complex.
Part of the reason I'm putting this info out there is to get feedback and see if a module that handles this type of access and setup would be a welcome addition to Drupal contrib, so feel free to drop me some feedback below.
The Pacific Northwest Drupal Summit (a DrupalCamp in disguise)
On October 24 and 25 I'm going to be in Seattle for the Pacific Northwest Drupal Summit. From my understanding, this un-conference is aimed specifically at intermediate and advanced Drupal users, so most of the topics are hitting the folks a little higher up the Drupal learning curve. There will be a whopping 4 rooms of sessions, which means that we'll have a lot of choices, and there will be a lot of people hanging out in the halls looking at the schedule, trying to figure out where to go. Perfect for me, because I love hanging out in the halls.
The Summit's web site was donated by This By Them, the same folks that did the uber-nice DrupalCamp LA site. You can see some similarities. I'm happy to see this re-purposing of a DrupalCamp web site (A full distribution and case study for the site can be found here). First of all, it saves the organizers time, and secondly it gives us attendees a familiar framework when registering, planning and voting on sessions. When we finally get a DrupalCamp Idaho off the ground, using this distribution will be a slam dunk.
There's some good topics being covered, such as deployment, Drupal 7 theming, Open Layers and SEO. I've also submitted a few sessions on AJAX development, Drupal security, themeing, and making friends. I've also been asked to do a BOF (Birds of a Feather) on the Navigate module. You can check out what sessions I've voted for by going to my profile page and clicking "My picked sessions."
I've you're planning on attending and want to say hi, drop me a line. Look forward to seeing you there!
Victoria BC DrupalCamp wrapup and slides from "Drupal development evolved!" presentation
One thing I appreciate about Drupal is that it attracts fantastic people. Every time I attend a Drupal event, I know I can grab some random person to chat with (which I often do) and end up in an interesting conversation, and the DrupalCamp in Victoria BC was no disappointment. The event was held in the offices of NorthStudio, a web dev / marketing firm and training facility. I judge a venue selection successful when the rooms are just barely big enough to fit the audience with standing room only, and the two rooms chosen for the presentations were perfect in this respect. Because the the rooms were their training facilities, everyone seated had a shiny Mac computer (running Windows) they could use to follow along with.
While I tend to gravitate towards lobby-talk during presentations, I caught most of several presentations that were quite interesting, and heard good things about the others. Here are some highlights.
DrupalCamp Highlights
Open Layers with Patrick Hayes. Open layers is a Drupal module that allows users to generate layered maps, with virtually any base layer (Google maps, Yahoo maps, NASA, etc). You can draw geometrical shapes and save them as nodes, as well as traditional points. After chatting with Patrick and Charles (his business partner over at GeoMemes), I heard my first ever argument for using PostgreSQL over MySQL. In summary, MySQL's support of geographical calculations and indexing flat out doesn't compare. Good to know. The demo was compelling and well presented, and makes me really excited to have a reason to use Open Layers.
Information Architecture, Design and Theming. Tom James and Alex Ventpap from Image-X gave a dual presentation on tips for designing, including wireframing, using Photoshop effectively and handing the finished design off to the Themer. I now have a few new Photoshop tricks up my sleeve, like make repeating backgrounds vector graphics (they're smaller in file size and expand more cleanly), clear your cache every once in a while to free up RAM, and a bit I need to follow up on about how you can minimize the file size of your PSD with a couple minor settings. After Alex's coverage of design, Tom took over and gave some good tips about theming, including using Aegir for deployment, minimizing theme customization by starting with a custom theme and using version control.
Next, Vanessa Turke, another member of the Image-X team, presented on information architecture (IA). She managed to cover a ton of stuff in a really tight time slot. A couple bits I took from it is 1) If your client doesn't buy into IA, and you can only spend a little time on it, then find out what the primary goal of the site is. I know from experience that you can't get far without that bit of info, but it's good to hear an IA expert say so. Also, Vanessa stepped aside to let a really fun, enlightening video about the typical web user play through. The video was a set of street interviews where the interviewer asked 'What is a browser?'. The bottom line was that you shouldn't overestimate your audience. They tend to not know what the **** they're doing, so you have to help.
Dan Howard with a bag of Developer tricks: This presentation was particularly cool because I'd just recorded a series of Drupal training videos for new developers at Build a Module.com. Dan covered a lot of similar topics, and it a spookily similar way. It's strange how even though each developer is different, we all develop a common set of tools and strategies (and mistakes).
Drupal Development Evolved!
Finally, I had a great time presenting a session called "Drupal Development Evoloved!" The core of the talk was meant to give new and intermediate developers a grasp of the tools that they might use someday soon to improve their workflow. Afterwards, some of the attendees suggested that the scale could be used to help people explain where they are in their personal development. The scale is based loosely on the number of sites one has built, but I discovered that some people find it more effective to use one of the strategies in the middle even though they've worked on many more sites. Here's the scale:
- 1st site: Download Drupal, install, download modules, install modules, etc.
- 2nd site: Copy the first site and gut it, use it again
- 3rd site: Create a base install and use this as a base (prevents embarrassing leftovers from copying and gutting)
- 4th site: Create multiple base installs for different kinds of sites (blogs, e-commerce sites, social networks)
- 5th site: Integrate team development
- 6th site: Share and collaborate using install profiles, Features, distributions and the like
The presentation featured many references to WebEnabled, a pretty groovy service I did a writeup on a while back and have more recently been doing some User Experience (UX) work for. At several of the stages outlined in the presentation, WebEnabled offers handy shortcuts and powerful deployment options. For example, instead of setting up a database, downloading and installing Drupal, you can just spin up a new instance of Drupal 5, 6, 7 or Acquia Drupal with a click. It sets up a shell account automatically for the application, so you can use an IDE like Coda or Komodo to work with the files remotely. Think Drupal Gardens for developers. It's pretty neat, if you haven't seen it yet, check it out.
I unfortunately wasn't able to record the session live, but below are the slides, and a dry run I did to get some peer reviews before the camp:
Summary
Overall, I was happy to make the 13 hour trip from Idaho to Victoria BC. I met a lot of great people, derived several insights form interesting conversations, and had some rather excellent sushi. Next year, I'm going to plan on sticking around a little longer to explore what I've been told is some of the most beautiful coastline in Canada. And I'm going to bring some extra garden burgers.
Book Review: Cracking Drupal by Greg Knaddison
It recently came to my attention that there are some gaps in my conceptualization of Drupal security. I was fortunate enough to have this pointed out to me by the Drupal Security Team, and not by a DOS, CSFR, SQL injection or XSS attack. After publicly bemoaning the mild lashing I received, four members of the Drupal community suggested I read Cracking Drupal. One of them even sent me a copy. No other book was even mentioned, which says to me that - considering how recently it was released - the book fills a void of knowledge that was seriously aching for coverage, and fills it well.
Over years of developing, I've become familiar with the various vulnerabilities that make their way into code, but I've never felt like I could build a complete defense. My knowledge has been piecemeal, drawing from documentation, books, interesting conversations and other people's code. In my case, Cracking Drupal did a fantastic job of gluing these pieces together into a comprehensive frame of mind.
What becomes clear very quickly in Cracking Drupal is that Drupal is quite a wily beast that gives developers real incentive to learn security. There are few functions in Drupal whose exclusive purpose is security, and Greg makes it clear that learning how to secure your site has definite side benefits: "When developers learn and use the API, they are not only safer but more effective and more efficient." When you learn how to use different aspects of the Drupal API (forms, translations, helper functions, theming) you gain bits of security as a bonus. If you set out to learn Drupal security, you'll come out the other end with a pretty solid grasp of Drupal APIs. Either way, it's a win.
Cracking Drupal is surprisingly brief. In 134 pages, Greg covers a lot of ground including:
- An overview of the different types of attacks one is likely to encounter, from physical to social
- Most (if not all) aspects of the Drupal API that have security implications
- Coverage of security-related contributed modules
- An introduction to the Drupal Security Team
- Demonstrations of exploiting common weaknesses in Drupal modules and how to fix them
An interesting choice is made in Cracking Drupal to keep a somber atmosphere around the subject matter. In almost any other context, this would be an immediate turn-off. I appreciate humor and optimism to drive my enthusiasm when reading. In contrast with other instructional books which end a chapter with a "go for it, get things done!" message, this book ends chapters with lines like "This paranoid perspective is a good one to maintain as you write, review, and implement features on your site." and "Remember that it is nearly impossible to fully protect yourself from a dedicated and persistent attack." and "If nothing else, I hope this chapter has scared you a bit about the realities of just how easy it is to exploit insecure code and sites".
In a book covering attacks that can result in a very serious loss of time and money, this lack of optimism is probably a good thing. And the final chapter, "Un-cracking Drupal" does leave the reader with the sense that something can be done. It's difficult work, but it's doable. Ultimately, I think the book drives home the fact that the most effective way to make a module or theme secure is to do it right from the start.
The title chapter of Cracking Drupal was probably the most lively and hands-on part of the book. I came out of it feeling like I could really enjoy exploiting vulnerabilities for the greater good. Because of this reaction, I think it would have been a good candidate for a first chapter to really whet people's appetites.
Overall, I think Cracking Drupal does a tremendous service to the community by pulling together the most important aspects of Drupal Security into one solid, compact document. While I came into the book having already been introduced to many of the concepts, it filled in a few gaps, and made the subject matter finite and approachable (albeit a little scary). I suspect this book will serve well as a guide and quick reference as I dive into identifying and patching up vulnerabilities in the modules I maintain.
A couple things I learned
While the greatest benefit to this book was the broad, sweeping overview of security, there were a few additional gems that will come in handy later on:
- There's a lot more to hook_menu() than I was aware of. Good coverage of examples on p.55
- I didn't realize that you had to exit after using drupal_access_denied(). p.59
- Ah, db_placeholders() - a useful function for passing a number of variables to db_query() p.65
- I had no idea there was such a robust node access API. Wow!
Notes in the margin
Below are a few unorganized comments that constitute my wish-list for future versions and complements to the author:
- Good quote regarding the definition of security: "For this book I’ll define site security as follows: A site is secure if private data is kept private, the site cannot be forced offline or into a degraded mode by a remote visitor, the site resources are used only for their intended purposes, and the site content can be edited only by appropriate users."
- I would have liked to see more AJAX security strategies and techniques covered.
- I liked all the Drupal 7 references, gives a good feel as to the direction of things
- I was surprised that there were not more brutal admonitions about hacking core, but suspect that's because they represent much fewer vulnerabilities than badly designed contrib.
- I was happy to see some coverage of CVS and DRUSH, namely using CVS to keep code up-to-date
- Nice coverage of security-related modules starting around p.41
- A brief mention is made that using mixed-mode SSL is pretty pointless. This is a big deal, I wish it had gotten further coverage.
- Being more of an optimist, I appreciated this particular phrase: " Every day there are more and more techniques beingdeveloped to attack sites, but every day there are also Drupal users reviewing code and providing new modules and enhancements to core to keep your site safe." Ahh, a glimmer of hope!
- Would have liked to see more coverage on the use of form tokens. If one must step outside of the forms api, this could be very important
- I liked that theme safety was covered, and thought the take on it was interesting: Make the theme secure by giving themers no reason to make stupid mistakes.
- Since the 'Vulnerable' module was patched up in the end, maybe it should actually be named to indicate that it's meant to be a useful module. That would feel more like a practical example.
What do you want to do with your life? Leverage envy to find out.
I keep running into people who lead more interesting lives than I do. I realize that this is just an elaborate illusion concocted by my mind in an effort to create a useful mental model of another human being who is way to complex too comprehend, but it still gets me down sometimes.
I'm a naturally optimistic person, and there's gears that start spinning whenever I repeatedly run into a source of emotional drainage. Experience has indicated that there's truth to be uncovered in most pain, and that once the truth is found, the pain dissipates to reveal some kind of rich experience.
So, a while back I started thinking about what kind of rich experience envy would leave behind if one found it's real source. I started digging, and found that I could trace envy to very particular things. At different times I've envied genius programmers, beautiful artists, and eloquent speakers. Identifying these qualities is EXTREMELY valuable, because it generates a list of stuff you want to be. I've sat down many a time and tried to make this kind of list off the top of my head, and it's really hard to do. I've also drawn the conclusion that this is a common problem because I know a number of people who are not very satisfied with their current life, but if you ask them what they want instead they can't tell you.
So, experiencing envy gives you some serious clues as to what you might want. The next step is weeding out the parts that only sound good if you don't think about them too much. Consider rock stardom. Sure, all the middle school girls love you, but would you enjoy travelling 8 months out of the year, sacrificing your relationships, practicing hours every day, and playing the same songs over and over to audiences who hate all your new stuff? Knocking down these fuzzy, badly articulated dreams minimizes a lot of the pain associated with envy. What's left is a list of qualities that you genuinely desire.
So, say by doing this sorting we've reduced the pain of envy by about 50%. Dealing with the last 50% requires a little meditation and one very useful piece of information.
Some of the items on your list (like rock stardom for most people) are relatively easy to dismiss. The remaining items require careful weighing of the positives and negatives. The more clear these become, the more you realize how many options you have. We all have lots of options open to us, but most of the time none of it sounds doable or attractive enough to stop what we're doing and switch gears. But if you give it a little thought, they become more tangible. Vacations or camping trips are great for this kind of meditation, I've found.
The bit of information one needs to fully appreciate the qualities one envies in others, and to understand their cost, is the law of 10,000 hours to mastery. Research has shown that for someone to become a master at something, they almost always have to spend 10,000 hours (3 hours a day for 10 years) practicing it. This law holds for Bill Gates and the Beetles. The example that stuck in my mind was that the Beetles performed over a thousand times before that really got the recognition we remember. That's more performances than most bands have in their entire careers. So, when you see a quality in someone else that you want, think about the time it took to obtain that quality. Then, consider what qualities or skills you've been cultivating over the years. Invariably you will have something valuable that the person you envy does not. For me, this completes the deflation of envy. Instead of thinking about the qualities I don't have, I've instead fostered a sense of respect for the work that someone else has dedicated to develop their qualities, as well as recognized what unique qualities I have, and - very important - what qualities I wish to acquire.
I think you can ride this wave of clarity a little further. Now that you know what you want, and you don't have negative feelings associated with your own qualities or the qualities you seek, it's a perfect time to make some decisions about what to do next. Developing skills and qualities takes time, so what do you want to work on? Coming to a decision on this then helps you take advantage of opportunities to develop these.
In my own case, this lead me to leave my job and seek work in a very particular area. I'm now willing to turn down lucrative opportunities for ones that will help me develop the skills and qualities I desire. Being so purposeful means that every time an opportunity presents itself, I have to reflect on how the opportunity might or might not aid in the fulfillment of my goals, which further articulates and evolves them.
This perhaps complex train of thought begins with simple envy. Envy is useful because it's an instinctual - and thus reliable - reaction. I'd encourage anyone who experiences bouts of it to try riding it for a bit and turn it into something positive. And let me know if it works for you too!
Query-Based Views (Q-Views) Drupal module intro and backstory
Open the Drupal.org project page for Query-Based Views
One of my first Drupal modules ever was Ajax Table, which gave some rich tools to users who would would normally circumvent Views to create a report or feed by constructing it programmatically. The problem being solved was "what does one do when they need to build a report starting with a query?" The Views answer is to expose everything you need to Views through modular hooks. This is an awesome long-term solution because, once your tables and custom output functions are exposed to Views, they can be used by any other view, and you can combine stuff in really novel, nifty ways.
However, a lot of people don't have the time or expertise to do that. They need to start with a query, and they would normally create a custom function, run the query directly and then generate the output programmatically. I think that there will always be use cases for this, and even if the same report could be created in Views, some people will do it this way simply because it's faster for what they need. Ajax Table was a utility module for these use cases. By running a query through a helper function and passing a couple parameters, users could generate ajax-reloading, searchable, sortable reports with very minimal work. It was handy, and I used it all the time. I still use it for my internal time-keeping / invoicing / proposal generating system.
The functionality was useful enough that I built out a second iteration called Query-Based Views, this one using Drupal configuration instead of straight-up code. I demo-ed the module to my local Drupal User Group, and got some positive responses regarding of the ajax functionality, rapid development and in-line editing. However, the general consensus was that the functionality would make a much greater impact if contributed as a Views plug-in, or as patches to Views itself.
So I shelved the project, thinking that until I knew enough about Views to integrate this, it would be better not to fork efforts.
Then a few days ago it struck me that maybe I should ask Earl Miles (merlinofchaos), the developer of Views, if the idea of starting with a query was actually Views-compatible. I was thinking that maybe the Views query builder was just an element of the UI that could be replaced out with something supplying a raw query. He said that it really wasn't. Too much of the power of Views is derived from abstracting out the query building process into the UI that's there.
That means there's actually room for this type of module. It's true that a lot of functionality is duplicated, but Query-Based Views runs on a different paradigm that's incompatable with Views, so it's reasonable for it to do so. Some specific bits like in-line editing could be abstracted more to be able to work with Views and Q-Views, but as a first effort, I think this module should fit the bill.
So I spent a couple of days porting the Drupal 5 version of Q-Views to Drupal 6, fixed a bunch of bugs and am releasing it as an alpha. The bulk of the code is written by the Chris Shattuck of yesteryear, who was not as well versed in Drupal ways, so if the module is useful enough a code rewrite is in order for a non-alpha / beta release. But as it stands, it's functional and ready to roll.
Video Demo
Q-Views has a lot of functionality, so this is a longer video (20 min). Feel free to skip around, though.
WebEnabled - A solid service for Drupal developers (if you don't get how it works, keep reading)
WebEnabled is really neat, so neat you have to give it a few minutes to sink in.
If you're a Drupal freelancer or web shop, you spin up new Drupal sites all the time. If you've been doing it long enough, you've probably figured out ways to make the process quicker and cleaner. If you've got a team, you've most likely established a system that allows multiple people to work on the same project. You've got a system for demo-ing Drupal to potential clients and for capturing your work so that you don't do the same stuff over and over. However, if you're considering adjusting your current workflow, have some gaps that need to be filled, or are starting from square one, then it's worth your while to meditate on what WebEnabled can do for a moment.
After signing up for WebEnabled, the first thing you'll want to do fire up an 'application'. WebEnabled has a one-click installer, which installs the latest versions of Drupal 6, Drupal 5, Drupal 7 dev or Acquia Drupal. While cool, a one-click installer is not novel in itself. What is novel is the feature set that accompanies the application. You can set up an app on a fresh .webenabled.com sub-domain, or link it up with your own domain. You can share applications with other users, which makes team-driven development a snap. SVN is also supported out of the box, if you roll with version control. Once you have your app set up, you can clone it. Imagine this workflow: You have a few different flavors of sites you work with, say blogs, e-commerce sites and social networking sites. If you start from scratch, you end up running the same configuration every time, installing the same modules, making some basic theme adjustments. If you've been doing this long enough, you've probably got a folder and database set up locally which you copy every time you start a new project. WebEnabled take this one more step: Fully automated cloning, complete with database config changes, a new database and new SSH account. Again, all this with just one click. It's hard to get simpler than that. After its cloned, you can continue to make improvements to the base site.
Okay, so we've got the ability to create a new site and clone it in just a couple of clicks. Perfect for solo folks, but what about managing default installations with a team? Here's one place where the number of options in WE is a little overwhelming, and detracts from the central awesomeness which is that if you want team-driven development, you can have it. For one, you can use integrated Subversion to manage team development with version control. Version control is a common solution to the problem of team development, but you can also connect different WE accounts to the same project to give several team members access to work with files directly.
The above feature set was enough to get me excited, but WE does one more really unique thing that I personally think is brilliant.
In the Drupal community, there's a lot of work sharing that goes on. Users contribute modules, themes, documentation, and support so that other users don't have to go through the same rigamarole that they did. Fixing people's problems is a two-way exchange. You help people, and earn a name for yourself, and perhaps meet some of your other goals (financial or otherwise). One thing I haven't seen is a good method of sharing base installations. Install profiles and the Patterns module can do something similar, but they take time that most folks don't have. People can package up distributions and share those, but maintaining a distribution is a daunting task that's difficult to do well.
WebEnabled allows you to publicly share your default installation, again with one click. What this does, in essence, is elegantly fill this missing gap for a community-based mechanism of sharing base installations. One doesn't need to go so far as to create and maintain a distribution, and updates made to the default install are automatically available, so there's no overhead in making the default install public. A WE account is required to initially import the default install, but because the free WE account allows up to 3 application installs, there's no cost to download. A public URL is given to a shared install, so you can promote the install however you'd like.
A plan is in the works to provide a marketplace so that developers have the option of selling their default installs. This would work in the same fashion as the free / premium theme model. Supporting this model means that people can actually derive some financial motivation to construct good default installs, and that could benefit the Drupal community and help users at all levels.
One more use case - Drupal training
One thing I think is worth mentioning is that WE is being used by at least one Drupal training firm to get their students set up and learning Drupal. It's easy, ubiquitous, and the only thing that you have to help people set up is an SSH browser of some sort. I can see WE being used for all kinds of Drupal training, both by instructors demonstrating, and students following along.
Criticisms and Concerns
From a User Experience standpoint, the interface assumes that you're a seasoned developer, and I think that might be a mistake, especially considering that students and new developers provide some really solid use cases. So, there are some gaps in documentation and some of the messaging was a little cryptic. There were several points during the initial setup where I asked myself 'okay, what's next?' Once I sorted those out, moving forward was reasonably clear.
I get the feeling that WE is still wrapping their head around their target markets. If I hadn't talked to one of the WE developers, the site wouldn't have called out to me to re-think the way I was doing things. It took a longer conversation to get enthusiastic about it, and to think about ways to incorporate WE into my workflow.
At it's core, WE is a hosted solution. While they've got a bit of a head start, with the open availability of Aegir, and with the Garden / Fields Acquia hosting projects, they're going to have some formidable competition in the marketplace really soon. WE is already stepping up their marketing, and that's good to see. WE has the opportunity to fill a real niche amidst some different rising options, but they will need to carve it out and perhaps even define it as they go.
My experience experimenting with WebEnabled left me pretty excited about its future. I can see that it's headed in a good direction, and it already has what appears to be a solid platform for creating default installs, supporting team-based development, and distributing the install packages. WE can be an awesome addition to a Drupal developer or firm's toolbox, and solves some rather difficult problems quite elegantly.
Top Notch Themes pre-releases a landmark theme called Fusion
At DrupalCamp Colorado, Stephanie Pakrul and Jay Wolf spoke about the new module Skinr and how it relates to Panels for theming, and I left the session with a few pleasant goosebumps. For the uninitiated - as I was - Skinr is a module sponsored by Gravitek Labs which allows themes to expose style presets to blocks. The upshot is that once you create a nice style, you can allow users to apply the styles to virtually any area of a page with a couple clicks. This effectively incorporates several principles that have up until this point been applicable mostly to modules, like reuse of code, config-based changes and ... well ... general modularity. I could immediately see that this was an idea with really big potential. Even in its infancy, the Skinr module can do some pretty neat stuff.
Along these lines, Top Notch Themes did a pre-release of their new Fusion theme which incorporates Skinr functionality. The folks at TNT have really been quite genius with their positioning of the Fusion theme, and I think they have really wrapped their minds around where theming is headed over the next couple of years. Their base message is that Fusion is the only theme you'll ever need - a tall order for any one theme, and an interesting proposition. The theme is grid-based and comes in fluid or fixed 960 variety, and a plethora of styles are made available through Skinr for layout and look and feel.
The main purpose of the Fusion base theme, however, is not to provide a look and feel, but rather to supply a solid foundation for sub-themes and - get this - pluggable, extensible style packs (my term). So, instead of having to cut and paste stylesheets and images from one theme to another, instead you paste these style packs in. I really like this idea. Fusion will ship - I believe - with an example sub-theme that looks pretty decent out of the box. Fusion also exposes some nice configuration options you don't see in a lot of themes, like font settings and setting the default text in several areas of the site.
Fusion will be released into Drupal contrib, and then TNT will be selling sub-themes on their site. The fact that they will be moving their themes to Fusion says something really important about Skinr and Fusion. If a leading Drupal company that needs the support of the community to survive is throwing their weight behind these technologies, it's a good indication that it's something to watch very carefully.
I think the move to create a one-size-fits-all, highly modular theme is inevitable, and comes at an excellent time considering how important it is to the Drupal community to attract more designers and themers. I also think it's a daunting task that can be accelerated if there is a model to drive the development commercially, alongside community development, so I appreciate TNT's and Gravitek's roles in this venture. The ability to create 'style packs' (again, my term), is another way that themers can contribute, and Fusion / Skinr will allow designers to do an awful lot of design without worrying about theming. That's pretty powerful stuff.
I'm really looking forward to seeing how this moves forward. TNT and Gravitek have their work cut out for them, but I hope that quickly it will become a minor movement to change the way we look at theming from here on out.
I can haz some Google love? A simple Drupal internal linking strategy.
I spent a little time today exploring some options for improving the internal linking on my blog. I'm not particularly worried about getting my site high up in the Google, but because I regularly add content it's a good sandbox for testing modules and techniques in achieving search engine friendliness.
A huge focus in SEO is getting higher ranking sites to link to yours, called 'incoming links', and the emphasis on this strategy leaves a lot of room for getting an edge using other techniques. In particular, 'internal links' - or links from one of your pages to another - is a technique way less exploited, but also much more under your control. Here's a couple of principles I've picked up over the years:
- Links from one of your pages to another one is just as valid as a link from an external site. What matters is the PageRank of the page. Think "pages" not "sites"
- The longevity of links comes into play, so rotating links aren't as effective in the long run as permanent ones
- You can link to several pages from one page without diluting the PageRank that page passes onto the others, possibly up to a hundred
So, what this calls for is a strategy for easily creating permanent links from one page to another. Also, by linking to new pages from several others you increase the speed of getting indexed (in theory).
Here's what I done:
1. Installed the Related Content module
The Related Content module allows a user to create one-way associations between one node and several others. These associations can then shown in a variety of formats on the node page, or you can use an API to get a list and do your own formatting. To use it, you first have to set up a view and that's used to display a list of nodes to choose from. I thought the implementation was pretty witty, and I've got some ideas for improvements I'd like to see. For example, automated relationships based on keywords, 2-way associations, hiding the current node (so you don't associate the node with itself), supplying a default view, adding a few more formats, and ajax-loaded views so that exposed filters can display. Doesn't look like the module hasn't gotten much love in the last year or so, but it's functional and think it's a great start.
The role this module fills in terms of search engine friendliness is that it allows nodes to permanently link to multiple other nodes. For real users, it also gives them a next step on your pages. For pages with a high bounce rate, it lays out something that might be a bit enticing.
2. Installed the Vocabulary Index module
You can set up Views to create a list of taxonomy terms with links to the term pages, or you can install Vocabulary Index, which does that out of the box, and also includes a count of nodes for each term. This exposes links to vocabulary terms, which then provide internal links back to articles. I see this as another factor in a good internal linking strategy.
3. Installed the Clean Pagination module
Clean Pagination is a module I put together that will change links from /view-list?page=2 to /view-list/2. Google does a good job at indexing query string-ed pages, but it's generally thought that using clean URLs even in pagination is a stronger method. A setting in the module will also change your pagination links to include keyword-rich, more descriptive URLs in pagination links, which get replaced out with plain numbers when the page is loaded. I'm not sure if this is a good idea or not, but makes sense from an accessibility and search engine friendly perspective. Anyway, the option is there.
4. Used the monthly archive view
A monthly archive is an excellent way to generate permanent internal links. By using a monthly archive view (export found here) and adding it as a block, you expose the index pages for spidering. It took me a while to dig this view up, so I've included the code below for Views 2 in Drupal 6. Here's the view:
$view = new view;
$view->name = 'blog_archive';
$view->description = 'Display a list of months that link to content for that month.';
$view->tag = 'default';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('sorts', array(
'created' => array(
'id' => 'created',
'table' => 'node',
'field' => 'created',
'order' => 'DESC',
'granularity' => 'second',
'relationship' => 'none',
),
));
$handler->override_option('arguments', array(
'created_year_month' => array(
'id' => 'created_year_month',
'table' => 'node',
'field' => 'created_year_month',
'default_action' => 'summary asc',
'style_plugin' => 'default_summary',
'style_options' => array(
'count' => 1,
'override' => 1,
'items_per_page' => '30',
),
'wildcard' => 'all',
'wildcard_substitution' => 'All',
'title' => '%1',
'relationship' => 'none',
'validate_type' => 'none',
'validate_fail' => 'not found',
'default_argument_type' => 'fixed',
),
));
$handler->override_option('filters', array(
'status' => array(
'id' => 'status',
'table' => 'node',
'field' => 'status',
'operator' => '=',
'value' => 1,
'group' => 0,
'exposed' => FALSE,
'expose' => array(
'operator' => FALSE,
'label' => '',
),
'relationship' => 'none',
),
'type' => array(
'operator' => 'in',
'value' => array(
'blog' => 'blog',
),
'group' => '0',
'exposed' => FALSE,
'expose' => array(
'operator' => FALSE,
'label' => '',
),
'id' => 'type',
'table' => 'node',
'field' => 'type',
'relationship' => 'none',
),
));
$handler->override_option('access', array(
'type' => 'none',
'role' => array(),
'perm' => '',
));
$handler->override_option('title', 'blog archive');
$handler->override_option('items_per_page', 30);
$handler->override_option('use_pager', '1');
$handler->override_option('row_plugin', 'node');
$handler->override_option('row_options', array(
'teaser' => TRUE,
'links' => TRUE,
));
$handler = $view->new_display('page', 'Page', 'page');
$handler->override_option('path', 'drupal-blog-archive');
$handler->override_option('menu', array(
'type' => 'none',
'title' => '',
'description' => '',
'weight' => 0,
'name' => 'navigation',
));
$handler->override_option('tab_options', array(
'type' => 'none',
'title' => '',
'description' => '',
'weight' => 0,
));
$handler = $view->new_display('block', 'Block', 'block');
$handler->override_option('arguments', array(
'created_year_month' => array(
'id' => 'created_year_month',
'table' => 'node',
'field' => 'created_year_month',
'default_action' => 'summary asc',
'style_plugin' => 'default_summary',
'style_options' => array(
'count' => 1,
'override' => 0,
'items_per_page' => '30',
),
'wildcard' => 'all',
'wildcard_substitution' => 'All',
'title' => '%1',
'relationship' => 'none',
'validate_type' => 'none',
'validate_fail' => 'not found',
'default_argument_type' => 'fixed',
),
));
$handler->override_option('block_description', 'Archive list');
$handler->override_option('block_caching', -1);Book review: Drupal 6 Javascript and jQuery by Matt Butcher
After reading Drupal 6 Javascript and jQuery (Matt Butcher, Pact Publishing), I gained a new appreciation for writers attempting to expound on a one specific aspect of Drupal development. jQuery, for example, can be used by nearly every layer of Drupal, from module building to theming, from the file system to forms. How does one boil down the many and varied applications of this multi-purpose tool into a reasonably sized book? I think Matt Butcher did a fantastic job of doing just that.
The book was not quite what I expected, and that's a good thing. For one, the author assumed a minimal amount of experience from the reader, and started at square one with some basic terminology and a first 'hello, world' tutorial. Like most tech tutorial books, the chapters are comprised of 1-3 mini projects where some new ideas or techniques are introduced. For the most part, each chapter builds on previous chapters, illustrating more complex functionality. Another thing that struck me from the start and continued to impress me throughout was the quality and creativeness of the example projects. While few of the examples were production-ready, they solved common issues in a compelling way. Here's a quick list of some of the mini-projects:
- Load an RSS feed via AJAX
- Create a live in-page alert when new comments are added
- Create a text editor
- Create a random, rotating node teasers in jQuery
- Write a jQuery plugin
A lot of these projects have crossed my mind as things I'd like to dig into at some point anyway. In addition to being interesting ideas, these projects are also executed in a way that brings together many aspects of Drupal. Having used jQuery and Drupal for a couple of years now, I felt like I knew the basics, but I was pleasantly surprised to learn something new in virtually every project. Some things I learned, but didn't expect to:
- How to use JSON - I've been wanting to wrap my mind around that for a while
- How to use translations in jQuery
- What are Drupal behaviors - If you don't know about them now, you absolutely need to! They solve one of the more complex problems I've dealt with in complex jQuery apps
- How to theme in jQuery - Awesome, I didn't know you could do that
- Creating jQuery functionality in themes - I had thought this was a purely modular job, but no!
By the time you make it through the book, you've been introduced to all of the major parts of Drupal. If I had known nothing about Drupal from the start, I would come out the other end with the ability to create themes, modules, and jQuery plugins. Not bad for 318 pages, probably half of which is code. And the fact that I was still satisfied even having worked with Drupal and jQuery for the last couple of years says something to the depth of the material covered.
I was excited enough about the new stuff I learned that I picked up a module that had been languishing for a while and re-wrote a bunch of the code using the principles addressed in this book. The code is now a whole lot easier to understand and debug. The 2 major concepts I applied were object oriented javascript and Drupal behaviors. Drupal behaviors is binding jQuery actions to html elements on the fly, so if you load up some new content via ajax, you can then attach all the jQuery stuff to it without affecting the rest of the page (like accidently attaching an action a second time, which can have undesirable consequences). I've found all kinds of ways of dealing with this is the past, and they've all been really ugly in comparison. Behaviors are a breath of fresh air, and there were lots of examples in Drupal 6 Javascript and jQuery to really anchor the coolness of them.
Minor Nitpicks
My criticisms of the book are really minor in comparison with my praise. There were quite a few typos and consistency errors. In another genre of book I wouldn't be as concerned, but when dealing with code where one misplaced character can break an entire script, running into typos in the text reduces confidence that the code will work if copied verbatim, especially for the unexperienced programmer. I actually worked through every example up until the last two chapters, and was pleased to find out that they all (with one exception) worked as advertised. The one exception was in Chapter 7 where a module is required that does not produce valid JSON. It took me a while to discover the problem, look and find a patch to the module. One more really minor thing is that I felt that the tone vacillated a bit, assuming at times that the reader was new to programming, and at others more experienced. Sometimes a good bit of work went into describing more complex programming conventions, and at other times they were more casually alluded to.
Summary
Overall, I was really happy to spend the time reading this book. I'm not the fastest reader, and working through the code examples takes me some time, but it was worth it. It anchored some important Drupal 6 conventions, illustrated some best practices for jQuery which can extend from simple to complex projects, and introduced me to some of the ways that jQuery integrates with the different aspects of Drupal. I'm looking forward to reading more from Matt, and would recommend this book to anyone aspiring to jQuery ninja-dom.
Notes in the margin
I made several notes in the margin of the book that didn't make it into the above review, so here they are for those interested:
- Until later on in the book, the example code snippets were short, which I appreciated
- I liked the idea of introducing jQuery in the theme layer in early chapters. Really simple, good call.
- Good callout in the translation chapter, which says 'hey, translations are really important, don't skip this chapter'. By the title, it was the least interesting chapter to me, but I really enjoyed it.
- Excellent job covering lots of gotchas: Syntax coloring, can't call ajax on a different domain
- Creating a javascript templating engine - weird and cool!
- Would have liked a chapter on jQuery.getScript() - dynamically load javascript
- How to handle cookies in jQuery - yea!
- I like the .info file trick - stick your own stuff in there, use it later
- I really liked the using caching for search auto-complete example. Will definitely use that one in the future.
Navigate module infuses Drupal with new level of sexy administration
To celebrate by recent release from employment, I spent several days busting my butt to put the sexy back in administration. Namely, I updated the Drupal Navigate module to include some new features, and to fix some long-standing bugs that had been making administrators feel less than sexy for the last several months.

For the uninitiated, Navigate is an administration module that works a little like Administration Menu. It loads a sidebar with widgets which allow users to search the menu, nodes or users, construct favorite lists, and load up expandable / collapsable menus. It works really well for clients who aren't used to Drupal. The newest release allows admins to set default widget sets, and adjust user sets. You can also theme it (a funky lemon theme is included as an example).
There's a video demo below, but here's a quick list of improvements made in this release:
- Made snappier through quicker transitions and fewer ajax calls
- Added ability to manage default widget sets for users and user roles (all ajax, btw)
- Made theming Navigate really easy
- Fixed compatibility issues with Administration Menu
- Added keyboard shortcuts
- Added XHTML compliance
- Added import / export ability for Favorites and for entire widget sets, so you can quickly deploy a set from one site to another
- Added 'customize' permission, to keep *certain* users from messing up their own sets
- Added ability to search users
- Squashed some bugs
- Re-factored lots of code to be more Drupal-esque
- Made some minor layout adjustments
I'm hoping to put in some work to help with the current administration tools in D7, but before that, I needed to grease my wheels a bit with some contrib work to to anchor some jQuery techniques I'd learned, and re-familiarize myself with D6. It feels good getting so much done so fast. You can do that with contrib work, but it's hard to be that productive in core Drupal. Things just move at a different pace there. Now that I've gotten a bit out of my system, I think I can crack down a bit and start seeing what I can do for core.
And here's the demo video to celebrate Issue Queue Zero (at least for the D6 version):
DrupalCamp Colorado - Scary hostels, friendly people, amazing grilled cheese
Last weekend I attended DrupalCamp Colorado, and thought I should jot down a few of my personal highlights.
The Hostel
I reserved a dorm bed at a local hostel. Maybe the creepiest place I've ever been. When you register, on the counter is a ventriloquist doll, folded in half with it's legs behind his head. Next to the doll is a communal bowl of chips. Like, potato chips. BBQ flavored. Now, I appreciate the sharing attitude, but would have been far more comfortable plunging my hand into a bowl of individually wrapped candies. After a series of strange events which I hesitate to recount (just in case involved parties are tracking my posts) but which kind of pushed me over the edge of creepiness, a fellow attendee offered to let me stay at his place, and I gratefully accepted. After I presented at one session, someone who actually stayed at the hostel let me know that out of a couple of months of traveling through Europe and Asia, the Denver hostel was the dirtiest he'd seen, and I'd done good by not staying there. The result is a good story with lots of embellishments if you're (un?)fortunate enough to hear the whole tale in person.
The Sessions
I ended up attending a lot of sessions, which I haven't done at previous camps / Drupalcons. I got some good stuff out of the security session with Greg Knaddison, Ezra Gildesgame and Ben Jeavons. Also, got some D6 theming goodness, presented by Stephanie Pakrul and Jay Wolf from Top Notch Themes. The stuff going on with the Skinr module really got me excited, and hearing how TNT improved their conversion rates so drastically using just a few intuitive techniques and very little time was excellent. Ended up sitting in on a few sessions that were a little under my point on the learning curve, but I enjoyed those as well because I was watching for presentation styles, since I gave my first session ever on Sunday.
Good wifi access, fun backchannel discussion, excellent lunch with TNT people and my friend Josh Brauer. There was enough time between sessions to get some socializing done (my favorite part of Drupal events) and meet some Denver folks.
The People
I got a really good vibe from everyone at the Camp. In contrast to Drupalcon (I'm still pretty green when it comes to Drupal events), I enjoyed the atmosphere of a smaller event. Ended up talking to the same people several times, and felt less lost in the crowd. I met a lot of people I'd love to chat with again, and got to put a lot of faces to names I'd only seen in IRC. I came home seriously considering the idea of taking an extended vacation (6 months or a couple years) in the area, just to be around such an active, fun bunch of Drupal folks. The experience anchored my resolution to attend a decent-sized event at least once every couple of months, to keep connected with the really neat people that make up the Drupal community.
Giving a Presentation
I was thankful to have the opportunity to present a session, and that the audience was probably too sedated by the unlimited pizza lunch to judge me too harshly. It went well, at least from my perspective. I kept on time, didn't freak out, and managed to make a few people laugh. The goal of the session was to jumpstart folks who haven't really taken part in community discourse yet, and go over the basics of getting involved. So hopefully, a couple more folks are a little closer to making that leap, or better yet actually took it. I learned that 45 minutes is pitifully short to cover a subject in-depth, and that it would have been nice to have more time for answering questions and getting feedback about what was missing from the presentation so I can make it better next time.
Conclusionary Stuff
I'm looking forward to presenting again, got a little more excited about doing a DrupalCamp in Idaho, am considering taking my wife back to Denver to evaluate an extended vacation there, learned that if you teach something you end up believing it simply through extended exposure, was surprised at my stamina after waking up at 3am, hope to pay some hospitality forward in turn, and am looking forward to hooking up with a lot of the great folks at the camp again. Oh, and if I get back to Denver I'm totally hitting up Chedds. A grilled cheese bistro? Beautiful.



