drupal 7

You can do a lot of great things with field display in Drupal 7's 'manage display' tab for a content type. You can control the order and label position of each field attached to a node type in that tab for Full node displays, Teasers, and RSS displays (or other displays you set up).

However, there's no way to change certain aspects of a node's display inside an RSS Feed, such as the 'creator' tag, the 'link' tag, or the 'title' tag. For a news aggregation site I run, I wanted to modify the <link> tag when displaying 'story' nodes, and make the link tag give an absolute URL to the original source instead of to my drupal site (so, instead of http://www.mysite.com/node/12, it would go to http://www.example.com/original-story-url).

A lot of blogs also use this kind of format for reposted blog items (such as Daring Fireball), so users go straight to the source when they click on the title of an item in their RSS reader of choice. My method below can be modified to conditionally change a link if a field has a value (say, a 'RSS absolute URL' field or something like that).

After reading A successful Git branching model [nvie.com], which I consider one of the best graphical/textual depictions of the ideal Git model for development teams (and most large projects), I simply wanted to adapt a similar (but way less complex) model for some of my smaller sites and multisite Drupal installs.

Since I'm (almost always) the only developer, and I develop locally, I don't want the complexity of working on many branches at once (master, hotfixes, develop, release, staging, etc...), but I do want to have a clean separation between what I'm working on and the actual live master branch that I deploy to the server.

So, I've adopted a simple 'feature branch model' for my smaller projects:

• master - the live/production code. Only touch when merging in a feature or simply fixing little bugs or really pressing problems.
• [issue-number]-feature-branches - Where I work on stuff.

Graphically:

Update: See comments below, and completely ignore this post. Nothing to see here...

module_load_include() is a great way to add code from other module's include files, but it doesn't always work as you'd expect. Recently, I was building a form in one module that pulled up a validation function from another module when a particular submit button was pressed:

I've had a nice go at making private messaging capabilities for flockNote work a lot nicer than the out-of-the-box Privatemsg module experience, by simplifying everything to the point that it's closer to the Facebook Direct Message system than the normal Privatemsg UX. (Privatemsg is the premiere way of handling private messaging in Drupal. It's already awesome out of the box... just needed a bit more help for our particular site ;-).

One thing I had wanted to do for a while is prefill the subject field of certain messages. I already have the new private message page appear inside an overlay popup after a user clicks on a link to send a private message to another user on the site.

Email is such a pain (I should know, as I'm currently working on a site that's sending 10-20,000 emails per day to 40,000+ users. Spam prevention, SPF records, bounce handling, abuse reports, deliverability, send rates, etc. are all huge hassles that must be dealt with when handling more than a few hundred emails a day.

For testing, I often like throwing in a quick bit of code to send me or someone else a simple email with a few bits of information when something happens on the site, or to test email addresses or formatting. Therefore I like having a quick one-line function call to send an email. In Drupal 6, there was a handy drupal_mail_send() function that would use some default settings and allow you to quickly shoot off a simple email (not translated, not pluggable, etc., but easy to implement).

I haven't seen much about this feature yet, so I figured I'd put it through its paces and share what I found. WYSIWYG editing on iOS devices is finally here! For a long time, contentEditable support has been lacking on iPads, iPhones, and iPod Touches, and it's been slightly annoying, as the only way to add richly-formatted text on these devices was doing a two-step through finding the carat characters and writing the HTML yourself.

Plus, some WYSIWYG editors (like TinyMCE) simply disabled the WYSIWYG from attaching to a textarea if it detected an iOS device. No longer, however: I've tested CKEditor (latest nightly) and TinyMCE (latest nightly), and both work perfectly (surprisingly well, in fact!) on the iPad running iOS 5 beta 6:

Since a few people who missed last night's St. Louis Drupal meetup wanted to hear more about Migrate module and my notes from a recent content migration for flockNote, I thought I'd post my observations and some tips here.

Migrate Module, v2

My prior experience with Migrate was on version 1.x, along with Table Wizard, for Drupal 6 (I used it in tandem with a bunch of CSV files that were used to import organizational data into the Archdiocese of St. Louis' website). A lot has changed in the process of Migrate upgrading from 1.x to 2.x... especially with Drupal 7!

On one Drupal site I'm developing, there is an 'embed code generator' in one of the site's forms. This embed code capability is similar to Twitter's embeddable timeline widget, in that a user can select some parameters (colors, mostly), then some code (usually an iframe with the contents provided by an external site) is printed in a textarea, which the user can select, and paste into his own site's HTML.

To help the user in the task of selecting the code, the entire contents of the textarea or textfield is highlighted when the user clicks any part, which ensures that the user will get every last bit of code without having to select and drag his mouse around the text box (sometimes I've seen people missing part of a tag, which makes the embed fail to load). That's what we want to do, inside our own Drupal form.

First, in the drupal form itself (or via an hook_form_alter()), we need to attach a javascript file in our custom module (in this example, I assume you have a module called custom.module, and a js file named 'custom.select-helper.js' in your custom module's directory, inside a 'js' folder):

Now that I've released a Drupal 6 backport of what I originally wrote as a Drupal 7 module, I figured I would write a little bit in the way of introducing one of the simpler, and more user-friendly ways of controlling spam in Drupal (as opposed to other also-helpful methods, like Mollom, CAPTCHA, etc.).

I'd like to thank Flocknote for giving me the development time to work on this module, as we needed something like it for the new 'version 3' launch of www.flocknote.com.

I've been getting errors like General error: Can't create/write to file, Error 2006: MySQL server has gone away, and other similar PDOExceptions and errors from time to time while developing on my Mac using MAMP Pro (this seems to happen more often with Drupal 7 sites than Drupal 6, for reasons I know not). I've noticed a few other developers are getting these errors too, and almost always on local environments as opposed to live servers.

I found that the easiest way to deal with them is by giving MySQL a nice buffer of memory via the max_allowed_packet and innodb_buffer_pool_size settings. Just bump those up to 256M or higher, and the errors above should go away. (In MAMP Pro, just go to File > Edit Templates > my.cnf, and search for those variables. Uncomment the innodb_buffer_pool_size variable if it's commented out.