This module is useful when we have more than one content type.
We might not want to use this module if we have content type

drush dl content_type_overview

We started getting a spam registration a minute – granted, only for a couple minutes – but it was still worrying enough to look for some anti-spam firepower.

drush dl mollom

Push the changes to our live site.

Enable Mollom at admin/modules.

Register the site at Mollom.com.

Copy the API keys for public and private to the Mollom settings page on our site, admin/config/content/mollom/settings

...

hmm. It tells us "The configured Mollom API keys are invalid."

Developing a module for hire can be a lot of fun, especially with a good client, because the requirements are figured out and laid out for us.

Although the request was to build off of an earlier module (made public but not released on Drupal.org), the goals expanded enough that it makes sense to start fresh— the client, who has Drupal 6 needs, even OKd a Drupal 7 first approach.

We make a new module in a working copy of Drupal and immediately start a git repository for the module.

As seen on twitter.

The leadership. Jen Simmons taking the lead on HTML5 in Drupal, and Dries Buytaert directing a fellow keynote speaker (secured and chosen by Morten and others who took the lead in organizing the Drupal Conference) to Jen.

Dries: Can't wait to add #HTML5 support to #Drupal. @adactio, thanks for the great #DrupalCon keynote! Talk to @jensimmons if you want to help.

The passion. A Drupalista attending her(?) first(?) DrupalCon... without sufficiently prepping her twitter followers, it turns out:

It's hard to convey just how important knowing how to make patches really is.

We can look at an issue queue and see all sorts of feature requests and bug reports. Some may have detailed suggestions of how to do a feature or even have code pasted into the comments that worked for one user. Some bug reports or follow-ups may have the problem identified down to the line of code.

But imagine that we made this module because we needed it, but we don't need the suggested feature or haven't run into the reported bug ourselves.

Most module maintainers (and maintainers of other projects) consider any issue in the support request category to never rise to the highest Priority level of critical.

Find a place.

Electricity and internet are all we need, but it never hurts to plan on feeding the code sprinters, also.

Find some people.

Some veteran programmers signed up before calling a sprint helps ensure that all issues can be handled. Ideally, someone with commit access to the project or projects that will be worked on should be present, or at least committed to work remotely.

[not tested, notes jotted down while helping fellow code sprinter test the translation of Forum titles]

Enable locale module

[new] In Drupal 7, the fastest way to add a language is to place the package of po files in the Drupal root directory and then add the language. It finds the po files automatically. (We do not go to import a language as in Drupal 6. Now we only use import for individual po files we add later.)

Microsoft has put a lot of resources into promoting Drupal
http://www.microsoft.com/web/drupal/
Cygwin gives us most of the UNIX-y goodness used in this book:
http://randyfay.com/node/70

A View with exposed filters begins like any other View: Administer » Structure » Views, Add new view (admin/structure/views/add). View name, suggestions (remember this is akin to the machine name), View description, Suggestions (this is the name used on Views administration pages), and View type, Node.

Next page, the real View configuration.

Greg Dunlap (heyrocker)

a markup editor with an real-time preview is a superior solution to WYSIWYG, because there is no true WYSIWYG

and AJAX preview allows us to see what is truly going to be there when we hit save

in the dgd7 project folder:

For the 6.x-2.x branch of BUEditor, all we need to do is change the Preview button code to js: E.prvAjax();

http://drupal.org/project/examples

Heather James sings the project's praises:

If a theme uses only default regions or feature settings, it does not need to define them in its .info file. If even one additional region is used, it must define all regions, the default ones it wants to keep and the new ones. The same holds for features. This is true for subthemes, also: If our parent theme uses only the default regions, and so doesn't define any, and so our copy of its .info file doesn't define any, we'll lose all the default regions the moment we define a region ourselves.

When things are terribly documented, we go to the source. No, we don't bang on the developer's door at three in the morning and demand an explanation. We look at the source code.

"I honestly believe that any shop that doesn't follow community practices as part of developing a site is doing their client a disservice."

— Boris Mann, http://bmannconsulting.com/2899/drupal/elephants-community-roi-too

In some chapter there should be a section on best practices for roles. Every site should have a Content Editor role that has Administer Nodes & Content Types. Discussions would also include managing Comments and Users.

Drupal developer Ben Buckman shared a script he wrote to create scripts for synchronizing a database between a remote and a local server. Commenters on his web site pointed out that Drush could do this, and do it even better.

grep "_form_alter" $(find . -name '*.module' -or -name '*.inc' -or -name '*.php')

The dot represents the current directory. Find works recursively (searches nested directories) by default. "_form_alter" can be the _something from any hook_something (or, of course, any text).

Usually a debugger is a better way to find all what a hook invocation actually calls.

Shell line adapted from http://benbuckman.net/node/6277/s5

We should almost never change universal values for existing fields. Drupal 7 does heroic work at allowing almost all field settings to be specific to the content type or other entity the field is attached to in a given instance. (Incidentally, that is what Drupal calls internally a unique field-and-entity combination: an instance.) Sometimes, however, we'll want to change one of the global configuration options at the bottom. We shouldn't, most of the time. We should create a new field, in this case, rather than re-using an existing field.