drupal

Scaling the Drupal Community - Notes and Reflections

The sparsely-attended 'Scaling the Drupal Community' session, led by webchick and heyrocker, was one of the few sessions I've attended at DrupalCon Chicago that held my interest throughout. And, since a few people on IRC asked me to post my session notes, I thought I'd do so and put them up on the Planet.

If you, like me, thought there were too many awesome sessions during this timeslot that you decided to go to another one, then this post is for you—I believe that anyone invested in Drupal's future stands to gain something from reflecting on what webchick said at the session.

Now, on to the notes. I will give a summary of a statement by webchick, then my reflection (kind of a Q&A format):

On 'Drupal Answers' vs. a drupal.org solution for Drupal Support

Drupal Answers is a new Stack Exchange site for answering Drupal questions, and it's in public beta right now. The site is hosted off the 'drupal.org' family of sites, and has a few hundred users so far...

Webchick: Webchick basically stated that she's leaning towards what we already have (with slight adjustments). She mentioned that there's no good answer for the question of motivating people to help support drupal newbies without incentives (a karma or reputation system).

Also, she said that moving the support away from drupal.org is potentially very dangerous; this could lead the 'newbie' community away from the 'expert' community (which tends to discuss things in drupal.org issue queues. Right now, 'newbies' typically hang around in drupal.org forums, and 'experts' typically stick to their trackers and issue queues.

Git through an NTLM Proxy (Corporate Firewall) for drupal.org

Borrowing from answers in this Stack Overflow question, here's how you can get through a corporate (Microsoft) NTLM Proxy to clone git repositories from drupal.org:

cd into your drupal contrib directory (or wherever you want to put the repository).

$ export http_proxy="http://username:password@proxy:port/"

$ git clone http://git.drupal.org/project/[projectname]

Basically, you're first setting an environment variable to tell your shell to use an HTTP proxy, with your username/password combo. This variable will be used when making connections to git.drupal.org (and other services, like github). You can also set this in your ~/.profile, .bash_rc, or .bash_profile so it will be saved for future Terminal sessions.

Gitting Started with New Drupal.org VCS

This is half for my own reference, because I have a few other computers I still need to set up, and I don't want to keep referring back to drupal.org docs to get everything ready for Git.

In case you've been under a rock lately, drupal.org was down for a while yesterday, while a team of dedicated Drupal peeps spent a few hours migrating everything in drupal.org's version control system (which was running CVS) to Git. Git is an excellent tool for version control, and I've been using it for a few months for my personal projects (most recently, I've started using Tower on my Mac to make Git easier).

Without further ado, here are the steps/links you need to 'git' started with Git on drupal.org:

Drupal 7 Front-End Performance - Shared Hosting Recommendations

Speedometer - BoostedI've spent a lot of time working on making sure my smaller Drupal sites (mostly run on shared hosts or very small VPSes) run lean and mean. This helps the pages load faster, users are happier, and my hosting providers don't have to shut down any of my sites, even when they're under pretty heavy load.

Here are my three recommendations for making your Drupal 7 website run great on a shared (or low-end VPS) host:

Integrate a Webform (3.x) with PayPal

For quite some time, I've wanted to integrate a particular webform with PayPal, since many nonprofits I help use that payment service. With older versions of PayPal, one could add some PHP code into a webform on the site to do this, but it was (a) hackish, and (b) a much less maintainable and secure way of accomplishing the goal I was trying to achieve. So I never did it.

However, after reading Additional processing in Drupal's Webform 3 module (from Drupal Coder), I found that Webform 3 has a hook that runs just after webform has saved a form's data to the database, but before the webform returns the user to a predefined redirected page. hook_webform_submission_insert() is the perfect time to hook into Webform's process and send a user to PayPal, along with that user's data.

WYSIWYG Force Linebreaks - a Module for Input Format/WYSIWYG Zen

A few months ago, I was starting to get fed up with having to manually re-patch the WYSIWYG module on about five of my sites every time it was due for an update, to incorporate functionality that I had hoped would make it into WYSIWYG as a regular button/plugin (see issue).

Well, after months of that issue's inactivity, I decided to take the bull by its horns and write up a proper module that would hook into WYSIWYG and allow me to (a) provide the functionality I needed to a wider audience, and (b) save me an extra minute of time per site upgrade (no more patches!).

Thus, WYSIWYG Force Linebreaks was born.

This module helps me with many of my sites - for many different reasons.

Drupal 7 Released - The World's Best Content Management System

Get Started with Drupal 7

Today, January 5, Drupal version 7.0 was released (download Drupal here). Drupal 7 release parties will be held worldwide on January 7 (which also happens to be my birthday - yay!).

Congratulations to the team of almost 1,000 developers who helped make Drupal 7 a reality, and congratulations to Dries Buytaert, the founder of Drupal, and webchick, the person who shepherded (and continues herding) the community as the Drupal 7 core maintainer!

My Simple, but Nerve-Calming, drush Update Workflow

Just posted for my own reference - here's my workflow for updating a D6 (probably also D7) website using drush. Comprehensive information about all drush commands can be found on the http://drush.ws/ website. If you're not yet drinking the drush kool-aid, you need to—if you use a Linux server, of course.

  1. Visit admin/reports/updates page on your site, read through any relevant release notes for required updates (to check if there are special requirements for said update).
  2. $ drush @site pm-updatecode <module1_shortname> <module2_shortname> (add all modules to be updated)
  3. $ drush @site updatedb (updates the site database - update.php)
  4. $ drush @site cc all (clears all caches on the site)

The reason I do this manually, instead of running something like pm-update or pm-updatecode is that I like the granularity and security of doing all the updates discretely—especially when I'm updating a larger site, where I like to know exactly what's happening when I update.

Drupal Performance Guide - Drupal and the LAMP/LEMP stack

LAMP Stack with Drupal - Druplicon, Linux, Apache, MySQL, PHP

Drupal is a scalable, flexible, and open source content management system that is built to run on a variety of server architectures. The only real requirement is that PHP runs on your system. You can run Linux, Microsoft, Mac OS X, etc., along with Apache, IIS, nginx, MariaDB, MySQL, PostgreSQL, etc. if you're willing to do a few extra things.

However, the overwhelming majority of Drupal websites use the most popular LAMP stack on the backend: Linux, Apache, MySQL and PHP, or the 'LEMP' variation, with Nginx instead of Apache. This white paper (which is a living document – I'll be updating it as time progresses) provides my thoughts on performance considerations for Drupal on a LAMP stack, but this information can be used for pretty much any system on any server, if you look at the basic principles.

Sections: