I’ve been involved with the Drupal mapping community for more than 2 years, and in that time, the Drupal geospatial sub-community has made a lot of progress in whipping together a very powerful toolkit for making and sharing maps and locations within the context of the Drupal ecosystem. Also during this time, the online mapping community outside of Drupal has exploded with an amazing set of tools for creating and sharing geospatial information. Making custom maps with either Tilemill or CartoDB is incredibly painless. If you want lots of control over your display, D3.js, among other things, gives you a ton of tools to make really, really interesting map displays. Even Github has gotten into the act by making it stupid-easy to share location data with maps via geojson files. When the rest of the web world is using tools like these to share geospatial information, why would anyone want to use the mostly Drupal-centric tools that our modules currently provide? The honest answer, I think, is that unless you’re already invested in Drupal, there isn’t enough to draw people into using the Drupal mapping stack on its own merits. Drupal 8 is going to give us an opportunity to revaluate how we want to structure our goals for contrib modules. We’re going to have to rebuild everything anyway given the upstream changes to Drupal; we should avoid the trap of just doing a straight ports of modules and instead try to build for what we know are problems today and how we’d like to solve for them tomorrow.
Geospatial Data Manifest for Drupal 8
1. Focus on building (or migrating) Drupal 8 modules as small pluggable tools rather than previous large monolithic solutions
Once upon a time, creating maps in Drupal usually meant using the Location module. Location module is an all in one solution that handles geospatial storage, proximity searches, and a Google Maps-based mapping interface. If it meets your needs exactly, then it’s a great module to use. In Drupal 7, we have a few more choices available to us to build out maps, but the solutions available still tend to be somewhat isolated stacks. If you use Geofield, you can’t use Geolocation’s nice field widget. You can’t use the Leaflet module’s nice array config options to build a map in the Openlayers module, etc. While it’s impractical to expect there to not be overlap in related module sets, what would improve the situation is to work on breaking out components that might be useful for multiple projects into individual libraries. What if instead of creating a widget specifically for one module, we focus on creating an input widget that outputs its data into a common format like GeoJSON and have field-level modules register to use the widget itself?
2. Design for Drupal as an integration framework for 3rd party libraries, rather than rebuild those tools in Drupal native form
Drupal module code should primarily be a) glue code between useful libraries, external services, Drupal core, and Drupal contrib modules, or b) Feature’s type modules that wrap components together into a useful package/UI. If a piece of functionality doesn’t meet one of those two objectives, IMHO it should be broken out or folded into a standalone library. If we can use a pre-existing library, fantastic. If one isn’t available, our instinct should be to create a new library available for a wider audience instead of trying to bake that functionality into a module directly. For example, in Drupal 7 we have the Geocoder module, which is is primarily a) an engine to handle server-side geocoding across 11 different services (5 external like Google’s Geocoding service, 6 internal like EXIF data) b) integration with the Geofield, GeoLocation, and Location modules. It’s a great module to use, but all of that code is managed internally by the module and can’t be used elsewhere. In the wider PHP world, there’s the great Geocoder-PHP library, which supports double the number of providers and also supports reverse geocoding. It’s widely tested through a comprehensive set of unit tests and the sheer number of projects using it. To me, it makes so much more sense to do away with the Geocoder module and to have Geofield/Geolocation/SuperAwesomeNewD8LocationFieldModule to use the library directly. If we have a Geocoder module at all, it’s there primarily to handle the configuration of API keys for the library itself.
3. For each feature module, ensure it actually provides a discrete, identifiable service/function
By focusing on building individual tools/libraries to handle the majority of the business logic, we can focus modules to solve specific problems instead of trying to be all things to all people. This should significantly improve the experience and stability of using these modules, since they’ll be focused on far more specific problems. If an enterprising developer wants to build a Store Locator module to contribute, I would love for her to deal more with that specific problem and rely on a set of battle tested tools instead of having to either code everything from scratch or try to copy thousands of lines of code from a semi-related implementation.
Why is this less risky?
Going from a module mindset to a toolkit mindset definitely has some risks. What happens when a library that a module is relying on for basic functionality has an upgrade that breaks integration upstream? We already have some of these sorts of issues currently between Geofield and modules relying on it. It also doesn’t help that Drupal itself has historically not had great tools for managing external code libraries, Drush Make and Libraries API notwithstanding. That being said, I think by ensuring the libraries we chose are properly maintained and version themselves well (ideally through semantic versioning), we can target our Drupal integration modules towards versions that are known to work and not have to worry as much about upstream issues. We should also encourage Drupal itself to have better tools to react to differences between module versions, and make use of what it has available already. Also, there are going to be issues with breaking down some concepts to separate libraries. For example, there will likely still be a need for a somewhat generic Geofield/Geolocation type module to hook into Drupal’s field system, and trying to break that sort of thing into a separate library seems impractical. That being said, breaking out chunks of functionality into smaller, useful libraries should continue to make those integration modules simpler to maintain.
So, what do you think? What geospatial-related features are you missing that you’d love to see in Drupal? Are you part of a different sub-community and some of this resonates with you? Also, if you’re interested in this, there are a few great opportunities for you for followup. If you happen to be at DrupalCon Prague, there is going to be a mapping sprint. I’m also hoping to speak about this very subject at BadCamp. Also, to take part of the larger conversation, many of the contributors involved with the geospatial Drupal community are active on IRC (#drupal-geo) and at http://groups.drupal.org/location-and-mapping.
- Mapping With Drupal - Great presentation by Patrick Hayes on the current state of the D7 mapping stack.
- Your CMS Is Not Your Web Site - Post by fellow P2-er Tobby Hagler about how a content management system is not the entirety of a website, and how decentralizing the components can make it easier to manage in the long run.
- Drupal and "Invented Here" – The fear of writing your own code - Very interesting article by another P2'er Mike Crittenden on the the reluctance of writing custom code regardless of how convoluted alternative solutions might be.