Tag Archives: drupal

Easy Planet 1.1 released

We lost a few features moving mhvlug.org from Drupal 6 to Drupal 7, as modules just didn’t exist. One of the ones I missed the most was the Planet function provided by UD Planet. This was an extremely simple to use module that let you have an attractive Planet (a collection of user blogs) on your Drupal site. The original authors of the module have long since gone inactive. So this past weekend I decided to just port it to D7 and be done with it. It took about 8 hours, and now we have Easy Planet!

Easy Planet 1.1 is now out. This is a straight port of UD Planet to D7. The only functionality which isn’t there is the disabling of aggregator menu items, which I’m not convinced was a good idea in the first place. It’s live on http://mhvlug.org/planet, for anyone that wants to see what it looks like.

One of the most important things to me was smooth transition from UD Planet installation. Because mhvlug.org was a D6 -> D7 migration, I still had udplanet tables and settings in my database. I wanted the experience of easyplanet to be: turn it on, all your stuff is back. I managed to get it there last night, so I’d be extremely interested in others that are moving from UD Planet -> Easy Planet to make sure it’s as seamless for them.

For more info, and to download the code, check out the project site.

Node Announce writeup

I’m happy to say Lullabot featured Node Announce on Module Mondays:

Unfortunately, one of the most useful calendar applications can remain elusive: sending users an email when something is about to happen. That’s where the Node Announce module comes in. It can use date fields on a node as cues to send out email to specified addresses — notifying authors when their nodes will be published, attendees when events are about to occur, and so on.

Multiple friends pinged me yesterday about it, giving me congrats. Good thing that I fixed that critical Drupal 7 bug on Sunday when taking the new mhvlug.org live (fixed in 1.2). That would have been embarrassing to white screen everyone’s websites on theme rebuild.

Feature requests and patches welcome.

Drupal Meetup Events Module

I just released version 1.1 of the meetup_events module for Drupal. I started building this about 6 months ago when we started using Meetup for Mid Hudson Astronomical Association to draw in new members.

I hate data entry. I find entering the same data twice into a computer one of the most soul sucking things I could do. So having both events on our website, and on meetup, meant I needed to automate things.

Meetup events was thus born. The model is simple, your Drupal site is considered the authoritative resource. You select which node types (which have date fields) you want to sync to meetup, and whenever you create or update an event of that type a meetup entry is made (or updated) accordingly. The body content that is synced is tokenized (and I added a few tokens for getting nodereference content). Venues are a little hokey right now, but I just provide a selector for a numeric field either on the main type or on a nodereference which maps to it.

meetup_events settings

Once you set up the module, including your API key and group url, you pretty much forget it is there. Then you just edit as per normal. Any time you save a type that you are syncing you’ll notice this:

Which includes a link to the meetup event that was just saved.

One of the more recent things I worked on was integration with views so that there is now a Meetup Events: Meetup Link view field for nodes. If you add that to a node listing (and you’ve registered for an oauth key) you’ll get the meetup dynamic RSVP button for your event.

That required a bit of tweaking of the rsvp javascript to make it play nice with Drupal, but given that the meetup team was kind enough to release that code under open source.

There is plenty of work remaining here, ways this could be nicer, but I’m pretty pleased with the results so far. It’s made me learn a bunch about Drupal’s ctools module, more than I ever wanted to know about the drupal settings system, and how to pull in incompatible versions of jquery in custom tools.

I’ve also been really happy with my experience with the Meetup team. They’ve added multiple API calls for me to make my life easier. Thanks guys. If every developer facing team acted like that, the world would be a much better place.

The meetup platform is turning out to be a really great way for our Astronomy club to draw in new people, and I’ve started using it for MHVLUG now as well. Now that I’ve got meetup_events, I can do that seamlessly without data duplication, or degrading our native experience. If you are interested in doing the same, check out the module. Bugs and patches welcomed.

CiviCRM and the Poughkeepsie Farm Project

Every year since I first started volunteering for the Poughkeepsie Farm Project we’ve had a pow wow in the fall about what would be the right task list for me to try to get ready by the start of the season in May. For the past couple of years all my focus has been on the website.

This year, things are different. While there are still a few things I’m going to do to the website, I’m diving into a brand new space. The PFP, like many organizations it’s size, is largely run by lots of disconnected spreadsheets. A for instance, asking a question about who attended both key fundraising events last year requires hours of effort, as those attendee lists are in completely different formats in different places. So the focus is going inwards, and we’re going to see how much better we can make this with CiviCRM.

CiviCRM is an open source customer relationship manager that attaches to an existing Drupal (or Joomla or WordPress) installation. It can handle donations, membership management, event planning and ticketing (including online payment). It was not where I started the investigation, but when I finally came across CiviCRM, and ran it through it’s paces, I was quite happy with what I saw. I’m also really impressed by the development community, who has been super helpful. I’ve gotten a couple of minor patches in already (and working on some more major ones).

This is going to be a really interesting journey at many levels. To do this right I’m really learning how the internals of a small non-profit works, and how we map the concepts across. We’ve got some good check points in place, and I think reasonable goals on what functionality I can get online this year. It’s probably a 2 year journey before we really take full advantage of what it can do for us. I’ll be writing about this journey here, and also talking about it very regularly at our Hudson Valley Drupal Meetup. So if you are in the area and are contemplating implementing CiviCRM, or have and could share, come out and find us.

Node Announce

At the September Mid Hudson Drupal Meetup I talked a little about a drupal module idea I’d been kicking around. Most of my drupal websites are about groups that have meetings. So I’ve got content types with cck date fields. Experience has shown that people need reminders, like via email, otherwise they forget to show up. Drupal has a lot of modules that will send notifications to users of the website, but that doesn’t work in my situations, because what I really want is the email going to a mailing list. Seemed like a good idea to me. And when I brought it up with the group, two people immediately said “oh, that would be great.”

That, it turns out, was enough motivation for me to get off my butt and implement it. node_announce 1.0 was released today. I’ve had it live on my sites for about 2 weeks, though the UI was in flux enough that I held off for a full release until now.

You want this module if you’ve got an announcements mailing list, and you are using the Calendar module on a drupal site to display events. I’ve got a list of ways I could make the module better, but for now it does the basics quite nicely. If you want to give feedback, do so via the issue queue, and I’ll do my best to respond.

Revitalizing a software project

I became one of the co-maintainers of the epublish drupal module this year, as we are an active user of it at the Poughkeepsie Farm Project, where we use it for our newsletter. I had about 6 big fixes to it that we needed, and so I was eventually just added to the project so I could commit them myself. Since then I’ve tried to clear out some of the backlog of issues, and added a few features.

In doing so I realized how fragile some pieces of the code were, as I broke things pretty regularly. Fragile code is the biggest inhibitor to innovation, because no one wants to try anything exciting and new when just keeping things working after simple patches is so exciting (and not in a good way).

So I decided to take on the project of revitalizing the code, in a couple of steps.

Add Automated Tests

Drupal has a framework called SimpleTest that lets you include automated tests in your code. These tests simulate a non javascript browser, much like using mechanize in ruby. There are also a lot of convenience functions for testing the results. In Drupal 7 this is a built in, in Drupal 6 it’s an add on module that requires a small patch to core.

Before actually making any substantial changes, I wanted to actually nail down current behavior, so that I know if I’m going to break anything. Over the past three weeks I’ve been figuring out how SimpleTest works, and writing tests for the code. I’m now up to 798 assertions, and have covered a lot of basic workflow, creating / deleting / updating publications and editions. I’d say I’ve probably got 1/3 of the coverage I should have, but I’ve ensured I’ve covered the goofy bits around article ordering that I broke multiple times in the last six months. I consider this a pretty good start.

As with all testing, the hardest part is the first test. That takes about eight hours to understand the system, and build and run a test that makes sense. I did that on a rainy Saturday before vacation. After that adding tests is easily done in 30 minute increments, which I puttered on in the mornings before Susan woke up during our vacation. In the process of getting these tests to work, I found and fixed a few critical bugs as well (when things didn’t work like they really should). Epublish 1.13 reflects these changes.

Extract the Database Layer

Step 2, which I’m starting on now, is to remove the database layer from the core epublish.module. My goal is to have no SQL statements in the core module file, and instead have those all in an epublish_api.inc file. They can be replaced with functions like “epublish_list_publications” and “epublish_add_publication($pub)”.

Again, this can be done in small increments, mornings while sipping coffee, or after work. I’m mostly looking for the kinds of SQL statements currently used, and trying to come up with the sane and well understood function name that they would map to.

Additional possible refactoring

One thing I found in doing the lending module is that it’s actually pretty nice to isolate the 3 form functions (display, validate, submit) for a specific form into it’s own include file. This makes it easy to know you are looking at everything about a transaction in one place. I’m going to see if this makes sense after the database pull out.

Theming functions also make sense to have in a separate place, they are logically quite different than other code in a drupal module, as they are the one place you’ll get markup included in the file.

New Features

All of this is really about adding a new and better interface for managing the articles in an edition, as the current interface leaves a lot to be desired, especially because of the automatically imported calendar entries we’ve got on the PFP site. It will also mean that a port to Drupal 7 can really happen. There are lots of other things holding the PFP site back on Drupal 6, but this is one of the bigger ones.

Brownfield Development

When you are a young and eager developer you always want to start from scratch on projects. The assumption is you can write a replacement in less time than it takes to figure out what the existing code does.

I’m now of the opinion that a whole sale rewrite is almost always the wrong thing to do. It means a very long period of time where you have nothing working, which means there is a good chance you give up on the project all together, with a lot of wasted effort.

This kind of incremental refactoring, adding tests along the way, lets you make pieces of the code better, and continue regular releases on existing function (even finding some bug fixes as you go). If this becomes uninteresting to me at any point, I’ll still have made the code easier to read, created a solid battery of tests, and handled edge conditions much better.

And this is how the majority of real software projects work. You aren’t there at the beginning, you aren’t there at the end. Your impact is really whether you can leave things better for the guy or gal that comes after you.

CMS vs. Wiki

This past week we had the second meeting of the Hudson Valley Drupalers, over at Marist College, which was really impressive. Vonn gave an overview of some of the really amazing things you can do with Taxonomy in Drupal, which I’d not even thought about. It was incredibly inspiring, and making me think about how I’ve created content types in all my sites, and how to do it better. And it’s really gotten me thinking.

At work we largely work with Wikis. Over the years I’ve been really a big supporter of wikis (heck, the wiki that our division uses is one that I started for our department years ago that got successful enough for our infrastructure folks to take over), but as I watch a current effort to organize some information on an internal wiki, I see how tough it really is. Wiki is largely a write only medium. Yes, with lots of effort, you can create something like Wikipedia. But you have to remember that 100x more effort goes into editing to keep it consistent then the initial content creation. Content Management Systems are really read mostly media. You only get to change a small amount of the page, then that content is sliced and diced in many ways throughout the system. This may seem like a trivial distinction, but when it comes to organizing information, the power of that slicing and dicing is huge. There doesn’t need to be only one way to see the data, there can be many ways in, and many ways through.

Maybe it’s time to try to introduce the CMS model in our area, and see if it would help productivity. I might make that a “Think Friday” activity once the Day of Service is over. The wiki experiment from 2004 took this path, and eventually got adopted on a broader scale.