learning

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:

1. 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().
2. 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.

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!

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)

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.

I've spent a good bit of time the last couple of weeks getting my thoughts straight for a session I may present at DrupalCamp Colorado called "Plugging into the Drupal community - Essential tools". The process of formulating my thoughts regarding my experiences with the Drupal community and what the project is all about has been a really good one. As a friend pointed out the other day, I'm more of verbal guy, so I've been thinking / practicing out loud and jotting down good thoughts when they come out. I remember David Byrne once saying that he writes music in a similar way.

The idea of the session is to help atendees wrap their mind around the social channels used by the Drupal community so they can get plugged in quick. Not just the technological aspects, but also the cultural implications of how the community uses them. I've been involved with the community on some level for a couple years now, and in hindsight I think my climb up the Drupal learning curve would have been greatly accelerated if I had gotten plugged in to the community earlier. Drupal is really a social solution to a technical problem, not the other way around, and realizing that can have a positive impact on the speed of learning and the ability to make a meaningful contribution.

Based on the voting so far, the session is lagging behind a bunch of other great-looking sessions - probably the material I'm covering seems too basic for the typical DrupalCamp crew. But I think I like the idea of putting a session out there, regardless of if it gets presented, just for the nudge to get some ideas in order. If I end up not presenting, that's just one more session I can either attend or skip out on to rub real elbows with some virtual friends.