Drupal Dork

tl;dr: I release Simplenews Threaded Send this weekend.

Let me start by saying that I love working for Jackson River. About a month ago, management anounced that we would be trying out a monthly Day of Personal Enrichment, not unlike Google's 20% time, but more realistic - who can afford to spend a day a week goofing around? We've staggered them so that the whole company doesn't shut down for a day at a time, so my first DOPE was this past Friday and I wrapped up my project over the weekend.

This week, I've learning a thing or two about Drupal search indexing. On the search settings page (admin/settings/search) for a client's site, the percentage of the site that had been indexed remained really low, even after running cron a few times. The search functionality still seemed to be working though, so I knew something weird was going on.

What I found was that the search_dataset table had well over a million records in it, so indexing was definitely happening. After checking the code used to calculate the percentage shown in the admin, I found that it only checks published nodes when determining how much content has been indexed - but, the node module chooses from all nodes when choosig a batch to index during a cron run. Since this site had about a thousand published nodes and over 100,000 unpublished nodes (the reason for that is a different story altogether), thousands of the unpublished nodes had been indexed, but not many of the published nodes had.

Display Suite for Drupal 7 included a lot of updates. The big ones are the inclusion of the previously-separate Node Displays and Views Displays modules, and support for more region layouts (the D6 version had a single pre-defined layout).

The feature that's making my life easy today, though, is a little thing: positioning the node post date separately from the node author. This was an option in D6 too, and I knew the module could still do it, but could not for the life of me figure out how. On the Manage Dislpay tab for my content type, my only options were the node body and taxonomy fields.

So, for your reference and mine: Display Suite fields only become available once you choose a layout under "Layout for [node type] in default" on the Manage Display tab.

I have a feeling I'll forget this step in the future, but hopefully I'll remember to look here for the solution!

A former employer emailed me recently and asked if I could provide a couple bullet points about why I preferred Drupal over Joomla. Since I was writing it up anyway, it seemed like a good thing to share:

I know it's been over a week, but I'm finally getting caught up on sleep and email after Drupalcon.

This was my first DrupalCon - well, my first anything-con, really - and it wasn't quite what I was expecting. I don't mean that in a bad way: I just didn't really know what to expect, I guess, so reality wasn't quite what I was imagining. I had a lot of fun and learned all sorts of things, but I definitely learned some important lessons for next year.

Sleep more the week before the con. This one is obvious, and I even had fair warning that it would be a sleep-deprived week, but because of other projects I didn't get to stock up as much as I should have. Frankly, I got a solid 6 or 7 hours every night I was there, but there was so much going on all week that it was far more exhausting than a regular week at home.

I never did get around to writing anything about the Webchick Drupal 7 Tour after the Lullabots came through DC a few weeks ago, but at this point, DrupalCon looms much larger on everyone's mind.

I couldn't be more excited. Even though I worked for four years at an event management company, and handled on-site IT for several technology conferences during that time, I've never actually attended a conference. I started working with Drupal just a few months before San Francisco, so it was too late to make arrangements to go by the time I really got into the project, and I couldn't afford a trip to Europe for Copenhagen. But, I have spent the past year attending the Drupal meetups here in town and occasional training events (like the Webchick tour), and from everything I've seen, next week is going to be a big hotel full of 3000 people that I'd really like to hang out with. They say, "Come for the code, stay for the community," and it's true: the Drupal community is so much friendlier and more welcoming than that of any other open source project I've dealt with.

The Webform A/B Testing module that I built recently is now available in the contrib repository. This one is better documented than my first contrib module, Multi SMTP, and is likely to have wider appeal. It adds a new content type for A/B tests of webforms, so that a site administrator can test a couple webforms against each other to determine which version results in the best conversion rate.

Development of both of these modules was supported by my employer, Jackson River. We have several more modules that we have been using internally for months and will be adding to the contrib repository soon; for the time being, they are available from our website.

My first contributed module has its first release:

http://drupal.org/project/multi_smtp

Hurrah!

"BrockBoland,
We are pleased to inform you that your CVS account request has been approved…"

Hurrah! The notice email included a list of links to documentation pages I want to read before I do anything else, and I need to figure out how to use CVS. I had been using the git migration as an excuse to put off applying for a CVS account, with the hopes that I would never even need to learn CVS, but I think I can master the basics enough to get through the next month or two.

Once I get through that, the first module I post will be Multi SMTP, the one I submitted with my CVS application. It sits on top of the SMTP module and adds the option of managing multiple servers. Then, there are three or four other modules that I want to polish up before I contribute them, and I've got ideas for a couple more that I'll need to find the time to build.

In any case, I'm really excited. I have been trying to get more involved in the Drupal community, and I'm excited to be able to give back some of the work I've been doing.

Sometime over the past few weeks, Drush stopped working for me. I could run drush st just fine, but anything that actually touched the database (like drush cc or drush up) gave me the dreaded "Drush was not able to start (bootstrap) the Drupal database" error. And since I'm always tweaking and changing settings on my system, I had no idea what I had done to break it.

My first thought was that I had killed it with Homebrew. I recently nuked my manual install of Drush so I could use Homebrew to update it every now and then. Once you install Homebrew, you can have Drush installed and configured really easily: brew install drush The same command will update it, too. But that wasn't the problem.

Xdebug is a must-have for local development, giving you step-through debugging and nicely formatted error messages, among other things. One of the mixed blessings it brings is that it overrides var_dump(). The display is a little nicer than the default, but it also cuts off at the third level of nested arrays or objects. This cuts the legs out from under Drupal developers: everything in Drupal uses nested arrays, and if you're trying to debug a problem or figure out where some data is stored, chances are good that you'll need to go five or six levels deep into an array to find your answer. Thankfully, the Xdebug developers were kind enough to include a configuration settings for this: xdebug.var_display_max_depth. You can increase the depth limit by adding a line to your php.ini file. I bumped the limit to 10 on my machine: xdebug.var_display_max_depth = 10

When it comes to showing things like related news, or section highlights, I've gotten so accustomed to using node reference fields or a View to list nodes tagged with the same terms. I forget that sometimes, the content administrators will be perfectly happy to build their own list in the node body with a WYSIWYG editor. On a current project, they want more fine-grained control over the list, and it saves me time as the site builder. Everybody wins!

(Originally posted on BrockBoland.com.)

Sometimes I want to update the Drupal core without updating all the modules and themes I have installed. By default, drush up will update everything, but that's not what I wanted to do today. This seems like the kind of thing that would be easy to find on Google, but no such luck. So, for the benefit of the next drush newb:

drush up drupal

Makes sense, right?

(Originally posted on BrockBoland.com.)

Thursday night, Dave and I braved the wilds of suburban Maryland to check out the Drupal MD group.

It was a nice change of pace from the DC group. The DC group meets in the upper room of a local bar. There are typically around 20 to 40 people there, and a few people will give lightning talks, then everyone kind of mingles.

(Originally posted on BrockBoland.com.)

On one of my current projects, I'm using Display Suite to layout various node displays. This is only the second time I've used DS and I haven't needed to get too deep into it, but so far, I'm finding it to be a lot quicker than coding different versions of node.tpl.php - and it allows the site admins who will maintain the site to modify things without getting into the code, something I talked about last week. Panels is another very popular option for things like this, but the one time I used it, I wasn't too impressed; for whatever reason, it just didn't click for me.

(Originally posted on BrockBoland.com.)

I have always felt that a site admin should have the option to disable or change functionality without having to hire a coder to do it for them. In my early days of web development, this meant I produced pages and pages of admin options. Instead of being highly customizable for the user, these apps were just highly confusing.

(Originally posted on BrockBoland.com.)

(Originally posted on BrockBoland.com)

It is imperfect, but I finally found someone who figured out how to get TextMate to talk to Drupal using the Blog API. In short, the blog setup needs to include the content type you are using for blog posts after a pound sign, such as: Blog Name http://user@www.website.com/xmlrpc.php#blogpost Unfortunately, it doesn't support taxonomies at all, so it's unlikely that I'll bother using it until I feel like putting more work into it.