Kevin Kaland's Developer Blog

Fixing duplicate field collection item references in Drupal due to Content Translation bug

I just left a comment in the Field Collection issue queue and thought it’d be good to spread it more widely; maybe people need this fix.

For anyone still getting burned by this bug (or for that matter getting burned by using Node Clone on nodes with field…

View Post

Introducing Internationalization 404 for Drupal

I released a new module for Drupal a couple days ago called Internationalization 404. This module helps you automatically use Content Translation-translated localized language versions of your 404, 403, and home pages.

Normally, you have to install…

View Post

HabitRPG and Remember the Milk Synchronization on the Command-Line

If you, like me, are a user of both HabitRPG and Remember the Milk, you may have been looking for a way to link the two. I developed habitrpg-todo-sync (HabitRPG Todo Synchronization) to do just that.

The README file explains in good detail how to use it.

View Post

DrupalCamp alert: DrupalCamp Gothenburg 2013!

If you haven’t been following any of the calendars listing DrupalCamps, you may have missed the arrangement that’s coming up in Gothenburg, Sweden in a couple weeks. This wouldn’t be surprising, since it’s being marketed in Swedish. People of all…

View Post

What I want in a Drupal development VM

I’ve tried a few of the Vagrant-based tools floating around and haven’t quite found what I wanted yet. So I thought I’d write it down. Once I did, I thought it’d make sense to post the list and see if anyone had input.

Without further ado:

Has to have

AUTOMATIC SETUP of Drupal.
SETUP AUTOMATION — Rakefile or whatever.
CONFIGURABILITY - change memory, CPUs, IP, mostly memory
PERFORMANCE - don’t slow me down?
WORK ON MY MACHINE - don’t make me jump through hoops
NFS folder sharing.

Nice to have

AUTOMATIC INSTALLATION of modules (or customizable makefile), declarable prior to running VM.

Which ones have I tried?

drush-vagrant (drupal-up and aegir-up)

vagrant-ariadne

Closest so far?

drupal-up, actually. aegir-up with the maintainer profile was almost there, but it it is broken atm :( The problem with drupal-up is that it doesn’t have NFS and isn’t conceived with it, so it fails “NFS” and “work on my machine.”

Do I need all these windows open!? (or: silence, MacBook fan!)

I’m faced with a peculiar, though probably common, plight.

My Mac eats up too much memory. And I have 16 GB.

Now, Mac OS X’s memory management is not to die for. This is evidenced by how 7.61 GB is currently allocated for swap despite me probably not needing that much. But that’s another story. I have to play the game within the parameters of the game, so obviously I have too much stuff open.

I used to run 3 VirtualBox/Vagrant VMs — one with 256 MB (since merged with the next one), one with around 1280 MB, and one with 4 GB (since knocked down to 3 GB).

So, 2 VMs, one 3 GB and one a bit over 1 GB. Two Chromes (two different profiles, personal and work) and my other usual always-running apps (iTerm2, Spotify, Skype, TogglDesktop, among others) exhaust all the memory.

I’d probably be best off restarting more often. And so that’s what I want to write/think about in this post — how can I close things down and/or restart quickly but still be able to regain context on projects I was working on? The latter issue — how to regain context on projects — is actually part of a larger question, and one that I’m slowly trying to solve.

It obviously depends on the project. For me, a “project” usually consists of an iTerm2 window with a tmux session inside, possibly (but not usually) an SSH session or two, a MacVim window, a running Vagrant VM (but if working on the server, then the tmux session is within the SSH session), and a Chrome window or two. The only part here that is actually tricky to save state on is the local tmux session. I probably need to teach myself to use one of the tools for automating tmux startup (e.g., open certain windows) and start writing definitions per project.

But I kinda wish there was something that would just care about all that and do it for me. I’d pay money for that. I’m sure I could probably also do something with AppleScript, but I dunno…it’s not really worth it.

But achieving cheap project resumption is definitely a nagging goal of mine. If someone solves it well and reads this, please let me give you money. Otherwise, I’ll probably wind up cobbling together more stuff to solve it for myself (and maybe collect some money of my own).

Cash Flow released

The first release of Cash Flow has just been cut. If you’re fast, you might get there before Drupal.org even generates the package (but you probably won’t).

Same URL: http://drupal.org/project/cash_flow

I don’t know if anyone will try it, but since I put it together, I’m kind of interested in what people think and if any of their ideas will help improve my workflow and stuff.

“The Finance System” gets a name and a home

You’ve seen talk of the mysterious finance system for quite some time. The mystery, however, will soon be revealed.

I’m almost done testing the Features Package that I’ll release on drupal.org.

It’s called Cash Flow. The project page already exists: Check it out.

Drupal idea: Anonymous statistics collection and surveys for contributed modules

I was just tweeting a bit with @longwave and decided to share a need I came across today. I don’t think this’ll happen without some help.

I’m currently working on the 7.x-2.x release of Fill PDF, and I realized it’d be neat to ask users of the module what throws them off or surprises them the most about the module’s workflow or the way it works, what would be easier, maybe other questions. It’d be nice to run a survey, that is to say.

The options I can think of are:

• Project page
• Issue queue
• Twitter/Facebook
• IRC?
• In-module

None of them have particularly good reach. In-module feels wrong if it’s Fill PDF-specific.

However, I think a contributed module for collecting anonymous statistics (e.g. actions the user takes in the module, whatever) and conducting in-site surveys would be valuable. It would have to be as unobtrusive as possible. I envision the workflow being something like:

1. Module developer (for example, me) writes a hook implementation to tell the statistics-collecting module (let’s codename it Extension Statistics) that I’m using it. This will cause Fill PDF to appear on the Extension Statistics configuration page.
2. Module developer adds Extension Statistics as dependency.
3. Administrator downloads and enables the module.
4. Drupal message appears saying that one or more modules would like to collect anonymous statistics and run unobtrusive surveys from time to time, that it will not impede the performance of the site more than having any other module enabled would, and that it won’t display anything to site users. That all data will go into improving the contributed modules that gather it, etc. There is a link to the configuration page.
5. They click to the configuration page and check the box saying it’s OK. They do this separately for any module that wants statistics. All collection is disabled by default.
6. Whenever the module provides surveys, another message appears at the top. The administrator can dismiss these, and there will be a configuration option never to see them. They’ll still be available from an overview page. Normal variables can be used to record when they’ve already been submitted, and the module can override how this works in custom callbacks.

Survey architecture

Surveys would be normal FAPI forms. They’d get included via a callback probably configured in a hook. Let’s call it hook_extension_statistics_info(). It’s really important that this module is as lightweight as possible, so that’s why surveys would use normal FAPI forms and not, for example, Webform.

Where does the data get sent?

This is the big sticking point, and I suspect it’s why nothing has been done yet. This module, although open source and examinable, would be asking for a fair amount of the user’s trust. So I think that, by default, their statistics and submissions should be sent privately to the module author in some way. They could uncheck the privacy box and have their statistics sent to a public server. They’d be anonymous, anyway, and then potential module contributors could look at what people were saying and work smarter. I haven’t seen anything like this in the open-source CMS world yet.*

Also: Implementing modules could specify their own server. We would need to develop an Extension Statistics Server module and potentially install it somewhere. We could send them as JSON or whatever. People could run their own server and specify a custom remote URL in their hook_extension_statistics_info() implementations. These would not be used if the user elected to submit statistics publicly, though. Maybe implementing modules could even override that - not sure. Even if public, though, they should probably also be sent to the custom URL.

Who would run it?

That is the biggest question. Initially, probably whoever was interested. Split costs or take donations to cover costs, donate the rest to the DA. See what comes of that (maybe d.o or core or Acquia or someone would take interest). Would likely need a special trademark license for the domain if not everything was going to the DA, but that’s getting into details again.

Other stuff

Transparency: The module code and everything about it should be extremely transparent. That’s the only way to get anyone to use it. It should be commented and organized well enough that casual reviewers can verify that it isn’t sending all their internal URLs and passwords and whatnot somewhere :)

Liability: There might be need to be some kind of privacy policy or something though to make it legit, and some sort of terms to indicate that they know they’re sending anonymous data. But I think the configuration checkbox could serve this purpose because it would be turned off by default.

About the dependency: I actually dislike the idea of implementing modules instituting a dependency. I just ran with that in my description because it’s what flowed. But I could also imagine an Advanced Help-type workflow. Advanced Help says, “If you install the Advanced Help module, [module, e.g. Views] will provide more and better help.” So we could have, “If you install the Extension Statistics module, you can anonymously help us improve [module, e.g. Fill PDF].”

Remote surveys? I’m also wondering if having some or all surveys live on the Extension Statistics Server-using site would make more sense. Otherwise, new users of a module will see every survey ever right at the beginning unless the module author commits the removal and makes a new release. That’d be poor DX. If they were on the server, then we could use Webform for them as well. It might actually be a good model.

* Maybe for good reason?