I wondered what I should call this post, and the title I picked seemed to fit. It’s been some time since I’ve written a proper blog post about my attendance to (or sponsorship of) camps. I’ve definitely tweeted about it, but the blog posts have been lagging behind. Time passes, and opportunities do too. I think I’d be beating a dead horse to try and catch up now. I’d rather just list the highlights since around July:

1. Was an individual sponsor of DrupalCamp LA (http://2011.drupalcampla.com/sponsors/wizone-solutions) and attended. Presented on hooks with Oliver Seldman and subbed in for Christefano’s presentation (http://2011.drupalcampla.com/sessions/professional-staging-and-deployment-todays-best-and-worst-practices). Also scored a great new photo courtesy of Sawako Leslie (thanks!).
2. Attended my first DrupalCon…in London (ahem, Croydon)! I also did an individual sponsorship for that (http://london2011.drupal.org/sponsor/wizone-solutions) and ran a couple informal discussion sessions (BOFs).
3. Experienced Drutober with nearly back-to-back DrupalCamps.The first was the Pacific Northwest Drupal Summit. This was a pretty cool event (yeah, sponsored this also. See a trend? http://pnwdrupalsummit.org/sponsors/wizone-solutions). It was targeted more at developers, apparently, and it was really well organized. I mean really well. Everything just went so smoothly and was so professionally done. My paltry $50 (OK, $200 total) was worth every penny.

   The second camp was the Bay Area Drupal Camp, a.k.a. BADCamp. (Individual sponsorship in profile: http://2011.badcamp.net/attendees/wizonesolutions.) I had to work for this one (the Coder Lounge was around 15 minutes away from the sessions), but it was worth it, and I made some new acquaintances. My session on Fill PDF also made it in at the last second (http://2011.badcamp.net/program/sessions/fill-pdf-module-web-form-data-completed-pdf-form-out). That was surprising, but cool, and the presentation went pretty well.

   Drutober was interesting because it was the first time I went to DrupalCamps with concrete goals. I think that helped me get more out of it.

4. SANDcamp 2012 (two sponsorships! https://www.sandcamp.org/sponsors#block-views-sponsors-block-11 and https://www.sandcamp.org/sponsors/fill-pdf-service) and DrupalCamp NJ (individual sponsor; see this page: http://www.drupalcampnj.org/event/attendees) are coming next.

So it’s been an interesting year. In the coming year, I’m hoping to polish up Fill PDF Service and make it properly rock. That’s part of the reason for trying to ramp up the marketing a bit. We’ll see how it goes!

(And I’ll try to write more.)

1. Using the development versions of Drupal modules is sometimes the best choice.
2. Using development versions as the project[module_name][version] parameter in a Drush Make file is always a bad choice.

How can we reconcile these two seemingly irreconcilable truths? The answer is actually very straightforward, and it’s even documented in Drush Make’s README.txt file itself¹!

I tweeted a link to this pastebin snippet the other day. Keep that open, and let’s take a closer look.

This example comes directly from a Drush Make file I actually use:

; Download the module with Git
projects[webform_userpoints][download][type] = "git"

; Find this revision by clicking View Commits on the project page
; in the lower right-hand column. Click on the most recent commit
; in the branch you were going to use. Copy and paste the full revision
; identifier.
projects[webform_userpoints][download][revision] = "25bfe11d2c6dc6480d0aabc79b1edb54dec06236"

; Tell Drush Make it's a module. This might not be necessary.
projects[webform_userpoints][type] = "module"

; You can erase or change the subdirectory. I like to separate
; my Git-downloaded modules.
projects[webform_userpoints][subdir] = "_custom"


The comments are there for explanatory purposes, of course. They explain the basics, so let’s look at the finer points. First of all, what was my thinking behind doing it this way? To answer that, take a quick look at the Webform Userpoints module and the available releases. I’ll wait.

OK, as you can see, this module only has a development release. However, I’ve also used this technique for modules where the development version had a feature (or even a bug fix) that I needed. The benefit of doing it this way instead of simply specifying the version as “1.x-dev” is that your site will never suddenly stop working after a Drush Make (or Aegir)-based deployment because of the latest development version having different code than you expect (i.e., new code). Git repository revisions are fixed points in time and code. You can rely on them not changing. This is a very good thing.

Finally, I thought I should include a screenshot of where to find the commit identifier. There are a couple places; let’s start with the one I used the first time:

Click the "View commits" link on a project to get here

That’s the View Commits page for Webform Userpoints. It’s accessible through the right sidebar. You usually want the latest one for the development version you need. Click on it, and then click here to skip ahead.

Sometimes, though, especially in actively-developed projects, you’ll find that there are so many commits that it’s impractical to find the revision that way.  In these cases, the Repository Viewer is the answer. To get there, click Repository Viewer on the Drupal.org project page of the module or theme with which you’re dealing, and then under the heads section, find the one that looks like the development version you wanted. This will typically be something like 6.x-1.x. Next to that, you’ll see a few links such as shortlog, log, and tree. Click log, and then click on the title of the latest commit.

With either approach, this type of page is your final destination:

Once you click a specific commit, you wind up on a page like this

The highlighted text is what you want. This will be different for you unless you’re doing this for the same revision of the same module.

Bonus developer method: Clone the repository with Git and check out the branch corresponding to the development version. Run git log and copy the full commit identifier. Stick it in the right place in the Drush Make file. You probably didn’t even need me to write all this if you’re using this method.

¹ http://drupalcode.org/project/drush_make.git/blob/086793e8887008a7841a5ef6081f8cf2766347db:/README.txt#l268

So check it out, and if any of the tools on it interest you, check them out!

Update: Oops, this wasn’t the problem at all. It was actually with the Content Permissions module. Forgot the site was using it! Pretty embarrassing

I just went through quite a struggle getting my CCK fields to appear on my Display Suite-managed node. I finally succeeded, though, in the end, and thought I would share the solution.

Don’t worry, there isn’t much to read: just disable and re-enable the Node Displays CCK (nd_cck) module found within in the Node Displays Contributions module.

I initially tried disabling and re-enabling all Display Suite-related modules, but that didn’t work. For some reason, however, disabling and re-enabling that specific one did.

Hope this solves someone’s problem!

(To read my full rant, check out this issue comment and the ones below.)

My goal here is only to share quickly how I actually got this working.

Alright, so you know the part where it says to add the directives:

AddHandler php5-fcgi .php
Action php5-fcgi /fcgi-bin/php5.external

This didn’t work for me no matter what I did. No errors were produced, so I knew that it simply wasn’t executing the Action directive for whatever reason. In checking the Apache 2.2 documentation for Action, I noticed that a MIME type could be given in lieu of an action-type (the php5-fcgi thing). Having exhausted all other options, and knowing that the PHP file was being sent to the browser unprocessed with the MIME type application/x-httpd-php, I decided to add:

Action application/x-httpd-php /fcgi-bin/php5.external

to my configuration. And, much to my shock, it actually worked!

So, if you find yourself as frustrated with setting up Apache + PHP-FPM as I was, I hope this tip may ease your suffering.

There will be pictures.

find . -name '[^.]*' | xargs perl -pi -e 's/192\.168\.1\.3/192\.168\.0\.3/g'

I adapted it to this for my task of replacing IP addresses. The first set of numbers is the old one (don’t delete the backslashes) and the second set is the new one.

This command assumes all files in the directory are configuration files and do not start with a dot.

Enjoy!

Update: According to a commenter, sed -i 's/thisip/thatip/g' * should also work. I didn’t try that since I thought it wouldn’t work with multiple input files.

Recently, I read the Stanford Tech Commons article on Cloning a Content Type in D7 at https://techcommons.stanford.edu/topics/drupal-7x/cloning-content-type-d7. It proposes a simple but (mostly) effective way  to wind up with cloned content types in Drupal 7. Summarized:

1. Create a content type and set it up as desired.
2. Export the content type and its field to a feature module with the Features module. *** WARNING: DO NOT ENABLE THE FEATURE MODULE YET. ***
3. The existing content type will be the clone, so edit it and change the machine name; this renames it and changes the type of all existing content to the new name.
4. Enable the feature module. Your previous content type is restored (potentially after reverting).

My Experience

I found that things didn’t quite go as advertised with this approach. I couldn’t get the existing content type to be recreated when reverting the feature. I found a workaround; it entailed editing database tables in phpMyAdmin, so it’s not ideal;  however, it does appear to be safe as it is only old data that is deleted. This should be done only if you have enabled the feature module and you cannot revert it, meaning that shows Overridden despite your best efforts.

1. Open phpMyAdmin or your database tool.
2. Browse to the field_config_instance table.
3. Sort by the bundle column and delete all rows corresponding to the content type encapsulated in your feature (not the already-renamed one).
4. Now browse to the node_type table.
5. Edit the row corresponding to the renamed content type, and you should see that its orig_type column still contains, predictably, the original name. Unless you’re sure you need this information, in which case you probably won’t be able to revert the feature module, edit this row and change the value of this column to the same as the type column. In other words, if the new machine-readable name for your content type is income, as it was mine, change the value of this column to income as well.

Try reverting your feature again. The content type will revert successfully, and the fields will remain Overridden. But don’t despair! They will be properly configured when you go and have a look. It’s just that Drupal adds some additional information that for one reason or another will not have been exported to the original feature, or wasn’t in my case. Recreate the feature module and re-export it to make it show Default again.

I hope these third-party errata help someone out.

• Drush Make makefiles for Drupal development versions
• Workaround for inability of Quickstart’s quickstart-create Drush command to create Git-enabled sites

There were two problems that were so counterintuitive, the urge to blog about them came over me. Disclaimer: I admit I’ve never properly read the Feeds documentation; I figured setting up a node importer based off a CSV parser would be pretty easy.

The solution is extremely simple:

When setting up your CSV importer and specifying Source column names, do not use spaces or uppercase letters. This means you need to avoid it in your CSV file as well.

That’s all! Instead of Body Text, call it body_text. What happens is that by the time Feeds Tamper receives your Feeds field, the data structure it uses to store them contains lowercase (and probably space-free) versions of whatever you had as the Source column names back in your updater. Using my tip ensures that these will be the same, and Feeds Tamper will be happy.

Have fun tampering.

P.S. The Latin in the title hopefully means, “Developer beware.”