drupal-planet

I've recently become more involved with map scripting in my work on LCREP, Save Our Gulf, Geomeridian, and a few others in the works. One commonality amongst all the projects was the need to display geocoded data on a map, a problem solved many times over. When I began work on the first of these projects this past spring, the state of mapping in Drupal boiled down to these tools.

Mapedelic

Mapedelic is the name given to the powerful and well established duo of Location and Gmap. The former stores address and coordinates as either CCK fields or in its own schema and can geocode addresses when called upon. The latter then renders those locations on a Google map. Gmap also plays well with Views. Both these modules have large install bases and have been in use for some time.

Pros

• Large, well established user base
• Stability
• Geocoding of addresses

Cons

• Location paradigm of collecting addresses is not applicable for more diverse use cases.
• Geocoding has some problems when updating addresses.
• You can't change between a fields and node based approach. Since fields is by far more flexible, and the future, there's lots of code debt to the pure nodes approach that most people don't need.
• Gmap uses the legacy v2 Google Maps API.
• Configuration and customization of the Gmaps output can be difficult.
• You're locked into using Google Maps.

Intel recently partnered with Nokia to launch Meego, a Linux flavored operating system targeting the mobile and device platform space.

MeeGo is an open source, Linux project which brings together the Moblin project, headed up by Intel, and Maemo, by Nokia, into a single open source activity. MeeGo integrates the experience and skills of two significant development ecosystems, versed in communications and computing technologies. The MeeGo project believes these two pillars form the technical foundations for next generation platforms and usages in the mobile and device platforms space.

Intel is taking advantage of Drupal reqularly these days, including the Atom Developer Program, which I consulted on, and Meego.com. It only made sense to build the Meego help system with Drupal as well. Intel initially contacted me about helping with a services layer on top of the help system allowing devices to access help content via open web standards. This will still likely happen, but it was temporarily put on hold. In the mean time, we worked on the actual organization and display of the help topics. There are obviously many approaches to solving this fairly simple problem with Drupal, the most obviously probably being Taxonomy and Views. With the various minor customizations we wanted, though, and in the spirit of keeping things as lightweight as possible, I decided to forgo Views entirely and just use core Taxonomy module plus some fairly simple glue code to make it all work. The basic setup is as follows:

• Create a vocabulary to hold all the help categories.
• Define a menu item for each term in the vocabulary, with a custom page callback that varies depending on depth.
• On the page callback, show the term description and any applicable nodes, followed by a list of all nodes grouped by child terms. There's some specific variation depending on the depth of the term being viewed.
• Breadcrumbs and active menu items are also handled on the page callback.

I recently had to implement what seemed like a very simple feature for a client, moving several of the local tasks located on a user's profile page into the site's primary menu. The menu paths in question are dynamic, E.g, /user/%/edit, /user/%/orders, /user/%/notifications, etc., which at first seemed like slight complication. So how to tackle this? At first blush, one might think that you can just use the Menu module to add a dynamic menu item though the GUI or menu API. Well, that won't work. You can only create a menu item that way for an existing path that you have access to. Luckily, Drupal provides a hook that seems like the perfect solution,

Great, so I can change the type of the menu items I want to alter by doing something like the code below and problem solved!

Sorry, I couldn’t resist the play on the words. This storied Minneapolis nightclub has been a music mecca since the 70’s, entering the national spotlight in the mid 80’s when it helped launch Prince and was the venue for the classic movie Purple Rain. Level OS first launched the site around 6 years ago on a custom ASP.NET platform (cut me some slack, it was my first project with my own company!). It was migrated to Drupal about 2 and a half years ago, right around v5.2. That version of the site featured a custom Ubercart integration allowing the club to sell both tickets and sightline seats to events, along with regular merchandise, heavy use of CCK and Views for features like blogs, forums, and galleries, sample audio tracks, and an online community. In the ensuing two years, both the code base and design lacked the flexibility the site needed, so we updated both. Side note: It’s amazing what passed in my book for Drupal best practices 3 years ago! The upgrade process was, well, extremely painful to be blunt, and this coming from a fairly experienced Druapler. The challenges we encountered included:

The Journey Gym is a exciting and innovative entry in the portable workout field just launched by Portland based startup Journey Fitness, LLC. It's been great working with their team launching the new site promoting and selling the gym. The site features:

• Shopping cart powered by Ubercart.
• Nutrition blog
• Custom theme development, done in part by Eternalistic Designs.
• Javascript rotating image galleries
• Intro video displayed via a lightbox, streamed from the site using Filefield.
• An FAQ section powered by the module of the same name.

Stay tuned for an online community and a system to put together your own workouts from a collection of exercise clips.