Planet Drupal

So You Wanna Be a Rock Super Star?

One important factor of running a company, as well as becoming a rockstar developer, is efficiency. Here at LevelTen we are constantly tweaking and revising our development processes to become as efficient as possible while still providing clients with the best possible solution for their website needs.

LevelTen has developed a number of internal tools to help standardize work across our small team of developers. These tools not only help with efficiency, but also with work consistency, and code portability. What this actually means is that rather than reinventing the wheel each and every time a client requests a common feature, like a blog, we can simply copy it from a repository of features, and tweak a few things to meet our clients' needs. While this requires a lot of time and thought to develop these features in such a way that is reusable, it dramatically reduces the amount of time spent per client to build them out.

Here I will talk about a few of the Drupal modules, and other tools we use to standardize our internal development workflow.

Features

http://drupal.org/project/features

Features is the heart and soul of creating a packaged set of reusable functionality. In case you're unfamiliar with this module, the general idea is that it allows you to export configuration settings into a "feature" which is really just a module. The point of this is to get it out of the database and into the codebase which will allow you to store things like views, and content types, in a version control system rather than the database. 

LevelTen uses Features to package specific functional use-cases, like an entire blog, in such a way that the functionality is general enough to be reusable across multiple client sites as a solid foundation for customization. 

Twitter Bootstrap

http://twitter.github.io/bootstrap/

http://drupal.org/project/bootstrap

Twitter Bootstrap is an awesome Less/CSS framework for creating really beautiful, responsive, and very consistent looking websites. Out of the box, it is nothing more than some basic Less and javascript libraries for things like form fields, buttons, drop downs, accordions, and various other common page elements. However, if you're at all familiar with theming a website and writing CSS, you probably know how frustrating it is to try to change the styles on a site that someone else themed. In the past, there had never really been a best-practice for writing CSS; everyone seemed to have their own opinions on how things should be done and they were ALL different. Bootstrap IS a best practice for writing Less/CSS and HTML.

Display Suite

http://drupal.org/project/ds

Like Features, Display Suite has been around for a while. Display Suite enhances Drupal's core templating engine allowing you to structure the display of node pages(among other things). So you need to display an image in the left column of a page and the body inside the content area? Before Display Suite(and Panels) this may have required some clever CSS wizardry and template overrides. Now it's just a matter of dragging fields into the proper region and clicking save - all of which is exportable using Features.

While it's arguable whether or not Display Suite is superior to Panels, some reasons why LevelTen prefers Display Suite are:

  1. It uses Drupal's core templating mechanism and the Field UI, so the learning curve is much smoother than with Panels. In other words, with Display Suite there's really no need to re-learn how to do something the "Display Suite" way.
  2. We can render entity displays using Drupal's internal view modes inside of views rather than using views fields. Views fields are messy and require a lot of work to keep consistent. Imagine a site where you have 5 different views all displaying a blog teaser. With views fields(or panels), you would need to update every view to keep them all consistent each time a small change is made. With Display Suite, you can simply edit the blog teaser view mode. When paired with something like Twitter Bootstrap(or not), this is a powerful way of maintaining a high level of consistency across a website, which is an important usability tactic.

Bean (Block Entities Aren't Nodes)

http://drupal.org/project/bean

Content types are to nodes as beans are to blocks. We've all run into situations where you need to display blocks of data formatted a certain way inside the WYSIWYG. Bean solves this problem by allowing you to assign fields to a block type and output using templates rather than using something as free-form as the WYSIWYG. Bean block types are also fully exportable which allows us to include them in our Features.

Source Tree

http://sourcetreeapp.com/

I think we can all agree, Git is complicated even for power users. Trying to manage workflow on a team of two or more is difficult. Git is designed to make this possible without overwriting someone else's work, but some may argue that it actually hinders efficiency and over complicates everything. I know I've caught myself asking "why can't we just go back to the good old days of using FTP?" Still, the positives still outweigh the negatives. On the surface, Source Tree looks like another Git tool for developers. You're right, except that it has this nifty little "Git Flow" button that puts your team into a Git workflow. This workflow allows you all to do your jobs with little interference from anyone else and it's relatively easy (at least in terms of using Git).

See here for a better explanation of what is actually happening. http://nvie.com/posts/a-successful-git-branching-model/

Honorable Mentions

Bakery

http://drupal.org/project/bakery

If you've ever tried to build a really big site with lots of functional components on Drupal, then you probably know how out of hand it can get in terms of trying to QA and fix bugs. Bakery is specifically designed to function as a single-sign-on for multiple Drupal sites (and it does a pretty good job). At LevelTen, we've been tossing around the idea of using it along side a standard multisite setup to "quarantine" large functional sections of a single site, thus creating a sort of "unified multisite". Although this method does present some other challenges(which we're already working on), it should, in theory, lessen the complexity of the different sub-sites enough to make them a lot more manageable.

Entityforms

http://drupal.org/project/entityform

Entityforms is similar to Webform in that they are both designed to solve the same problem. Webform has been around for a long time and has been the defacto standard for creating forms ever since. Unfortunately, it uses its own API and UI for creating fields while Entityforms uses Drupal's core Fields instead and is fully exportable using Features. This simply means that you can use all of the core fields and field type contributed modules to build your form, thus adding another level of consistency and availability of field types.

EVA (Entity Views Attachment)

http://drupal.org/project/eva

EVA is especially cool when paired with Display Suite. Because rather than creating a views block and placing it somewhere inside a region in a page, you can attach it to an entity as a field. This allows you to place the contents of the view using the Field UI.

Pantheon

https://www.getpantheon.com/

I'm including Pantheon in the honorable mentions section because we haven't fully adopted it at LevelTen just yet. However, we've got nothing but good things to say about it, and it's a fantastic efficiency tool for setting up Drupal environments.

 

Any thoughts? Leave us a comment below!

Icons and Drupal: These are the Years of our Lives

The title alone says it all. If you're reading this post, it probably is because you desire an easier way to insert a simple icon into your Drupal site. Many times this involves adding an icon library into your theme and doing some pretty undesirable pre-processing or template overrides to insert them where you want.

What are icons?

They're images right? Well, technically yes. Icons are a visual representation of some intended object or action -  a pictogram essentially (think of a stop sign). What I'm really asking though is:

What file format/method are or should be used for icons?

This question has pretty much been answered for years. Whether it be a single static image or one massive image used for CSS sprites, they're usually a GIF, JPEG or PNG file. Pretty standard stuff and all is happy in the world. Well, guess what world? Meet font icons.

Font Icons

While this concept really isn't new, it probably isn't as widely known and has really changed how some of us themers approach icons in general. Fonts are vector-based in nature so they can be scaled, colored, text-shadowed... pretty much every CSS trick/method you can apply to text can be used for a font icon. This has really changed the game:

While font icons are great, they do have a few limitations. (I only mention this so I don't get a comment about it below.) They are mainly monochromatic in nature, given the limitations CSS text coloring. In theory, it is possible to apply perhaps another secondary color if your font icon provides ligature support (IcoMoon). If you still need full-colored icons though, sprites are still probably the best way to go. Simplistic and flat silhouette icons are "in" right now. So in retrospect, perhaps font icons aren't as "limited" as some may believe, but purposefully and strategically left this way... at least for now.

Regardless of how one might perceive it, fonts icons have simply added to the noise of what "icons" are now considered to be and the markup that comes with it. Ironically, one might think this would complicate matters more, but in reality font icons are typically easier to implement and are overall easier to maintain.

Icons in Drupal

This problematic issue isn't anything new to the Drupal community. In fact, there are issues and discussions that span all the way back to 2007 (if not farther). With a SoC initiative and a couple more attempts to put icons into Drupal, they either didn't gain much traction or have just failed over time, miserably. As a themer, I have noticed that often times the lack of icon support in Drupal has perhaps limited the design or even affected the choices in how we build a site.

Let's take a step back and look at the underlying issue though. It's never really been about the icons themselves, has it? Rather, "How do we get them in the site?", "Do we put them in the theme or a module?" or "Do they need to be interchangeable?". It is no wonder this issue seems to go around in circles and can never really seem to come through to fruition. Often times, we've been more focused on putting the actual icons in Drupal, instead of looking at the bigger picture.

Icon API

We need a framework/API. Period. Something that can manage our wonderful, varied, multi-licensed and different methods approach to icons. We also need a way to list these icons so they can be inserted into many common places throughout Drupal.

Icon bundles (sprites and fonts) are also inherently bandwidth vampires. Often times, we don't need all the icons on the single page request, just a few. This is where services like Fontello and IcoMoon have really soared. Granting us the ability to pick and choose only the icons we need, instead of loading an entire library, most of which we don't use.

Ultimately, my goal is to figure out the best approach for dealing with fully modularized icons. To elaborate and give one possible solution: base64 embed the icon data (image/font glyph) into a separate icon specific CSS file with just that class. This would allow the icon to be aggregated into the page's CSS and loaded only when that specific icon is being used. I'm not sure how useful this would ultimately end up being and further testing needs to be done on it. There are always pros and cons to any idea, especially anytime you consider performance.

So despite the obvious challenges ahead of me, I decided to take on this whole icons in Drupal issue. I spent quite a bit of my time researching the best approach to solve and ended up building the new Icon API. Recently, l released the first public beta:

Icon API - 7.x-1.0-beta1

This API provides the necessary framework for modules and themes to provide icon bundles inside of Drupal. The power really lies within the sub-modules though. Their ability to integrate an icon selector into the key areas of Drupal is really the primary goal of the API. Currently these integrations enhance the block, menu and field systems. There are plans to support content areas in a filter/WYSIWYG sub-module, but given the nature of what this entails, it may be a while.

In reality though, the possibilities are endless! You can integrate icons anywhere you can think of. Please feel free to create new feature requests in the issue queue (and of course submit bugs... there will always be bugs). The icon selector is still very rudimentary at the moment, mainly due to the focus being on the back-end integrations. Future plans also include making this very dynamic in an effort to support things like icon variations (icon sizes, colors, additional classes, etc).

Warning to non-drupal co-workers: Drupal themers and developers may involuntarily and randomly throw their hands up in the air to celebrate this newly and long awaited integration. This is completely normal and to be expected. Do not be alarmed.

Photo credit: ocean.flynn

Breaking up the Monolithic Drupal Site with a Subdomain Multisite

When building a Drupal website, do you ever notice that the site sometimes gets too complex and has too many modules installed? We run into this with clients that want a lot of features in their website such as commerce, forum, blog, knowledge base, and more.

The problem comes from the fact that there are dozens of modules that need to be installed and configured for commerce, forum and every other feature to work right. As more and more modules get installed and configured, they start clashing and adding massive complexity to the site. Sometimes different features will need things to be configured differently.

Since each module is being used on every page, the memory footprint becomes enormous. When doing commerce, it really shouldn't need all the hooks and code for all the forum code and vice versa. We've even seen sites with massive memory footprints that take 768MB to 1GB of ram PER INSTANCE to run.

We've found a better way.

Instead of building out a complex site in a single monolithic install, we're breaking it out into multiple installs using subdomains and Drupal's multisite functionality. This allows us to focus on the specific functionality for a part of the site on a single install. For example, the forum would be installed at forum.example.com, the store at store.example.com and the main marketing website at www.example.com.

The trick to all of this is that we have to make this seamless to the end user and in a maintainable way.

ISSUES WE'VE HAD TO SOLVE SO FAR:

(I'll be writing about the rest of these in later blog posts)

Managing sandbox, dev, test, production for a Subdomain multisite.

First, let's look at how we keep things maintainable.

Each part of the rollout process is going to need a top level domain name. This is important later on as we start setting up settings. For this blog post, we'll pretend to use example.local for our sandbox, example-dev.com for the dev server, example-test.com for the test server and example-prod.com for the production server.

There will be a single repository and code set for all of the subdomains. We don't want to break them out into separate repositories as that would get unmanageable in a hurry.

One of our best practices is to modify the core .gitignore file to add in the main settings.php file but ignore any local.settings.php files.

First edit the .gitignore file and change the settings ignore to:

sites/*/local.settings.php

Then add the following to the end of the sites/*/settings.php file:

if (file_exists(dirname(__FILE__) . '/local.settings.php')) {
  include dirname(__FILE__) . '/local.settings.php';
}

This allows us to override any of the settings.php settings on our sandboxes.

We will also need a "Global" settings file. There are lots of things that will be shared between the sites. Instead of trying to keep those in sync manually, we can just add them to a global settings file. To do this, create a file at sites/global.settings.php and then add

if (file_exists(dirname(__FILE__) . '/../global.settings.php')) {
  include dirname(__FILE__) . '/../global.settings.php';
}

to each of the sites/subdomain/settings.php file. Any $conf settings put in here will be global across all of the sites. We like to put in the Acquia network settings and account settings for a start. Pretty much everything that is global should be put in here though.

The next step is to create the separate subdomain installs. It is actually fairly easy to do this. Start with a basic Drupal repository. We are going to be doing most of the work in the sites directory.

Create a folder under sites for each of the subdomains. Here are some of the ones we've used.
sites/accounts
sites/forum
sites/knowledgebase
sites/marketing
sites/store
There should already be a sites/all and a sites/default.

In each of these sites folders, create a settings.php file with settings for that subdomain. Then create directories for "modules" and "files". These are modules and files specific to that subdomain. Please see below about contrib modules.

Next edit the sites/sites.php file (or create one if it doesn't exist) and add:

// Accounts Site
$sites['accounts.example-dev.com'] = 'accounts';
$sites['accounts.example-test.com'] = 'accounts';
$sites['accounts.example-prod.com'] = 'accounts';
$sites['accounts.example.local'] = 'accounts';

// Marketing Site
$sites['example-dev.com'] = 'marketing';
$sites['example-test.com'] = 'marketing';
$sites['example-prod.com'] = 'marketing';
$sites['example.local'] = 'marketing';

// Knowledgebase Site
$sites['kb.example-dev.com'] = 'knowledgebase';
$sites['kb.example-test.com'] = 'knowledgebase';
$sites['kb.example-prod.com'] = 'knowledgebase';
$sites['kb.example.local'] = 'knowledgebase';

// Forum Site
$sites['forum.example-dev.com'] = 'forum';
$sites['forum.example-test.com'] = 'forum';
$sites['forum.example-prod.com'] = 'forum';
$sites['forum.example.local'] = 'forum';

// Store Site
$sites['store.example-dev.com'] = 'store';
$sites['store.example-test.com'] = 'store';
$sites['store.example-prod.com'] = 'store';
$sites['store.example.local'] = 'store';

One of the issues we came across early on was where to put contrib modules. At first we were putting subdomain specific contrib modules under each subdomain. Then we quickly ran into a problem where we needed to share modules we didn't expect and then either had to move them out of the subdomain modules folder and into sites/all/modules or create an additional copy in the other subdomain (bad). We decided on a policy for a Subdomain Multisite that ALL contrib modules that are needed on any subdomains would be placed in sites/all/modules. This makes for easier sharing between sites when you don't initially expect it and easier maintainability since we will always know where contrib modules are located. So far this has worked out very well for us. Note that the modules don't have to be ENABLED on all of the subdomains but they are AVAILABLE.

So what do we put in the sites/subdomain/modules directory? We put in features and custom modules for the subdirectory. We add basically the content types, views and other pieces that are specific to that subdomain.

Set up this way, we now have a single codebase with a multisite install that will work on sandbox, dev, test and prod. It is also about as maintainable as we can make it.

Sharing the Theme between subdomains

Since the sites should be seamless to the end user, they should all share the same theme. This is actually relatively easy and straightforward. Add the theme to sites/all/themes and ensure the theme is enabled and set to default on each of the subdomains (either manually or in a shared module) and all the sites will look the same.

I'll be blogging more soon about the other issues we've solved when developing subdomain multisites. Have any ideas on how to improve this process?

Please share your comments below!

Using Drupal 7 Entity Reference to help Create User Dashboards

Over the years, I have noticed a significant increase in the need for businesses to create user dashboards from which their customers are provided account details, up-to-date reports, downloadable documents and other important information. As more clients ask for user-driven websites that provide user-specific information, the need to relate or reference various types of content/data together is becoming commonplace.

I live in Dallas, Texas so let’s use this scenario. Imagine you are an energy company that provides partnership opportunities to individual investors. Each Partnership consists of three gas wells. At the end of each month, your investors should be provided with personal financial reports, drilling reports, etc. Investors should also have the ability to view a list of the Partnerships they belong to and the wells that are attached to that Partnership. This information is shared across any user who belongs to the Partnership. Are you with me so far?

While this might be a nightmare to program, the use of Drupal 7 entity references makes this possible within a fraction of the time. The process might look something like this:

  1. Create three content types – Document, Partnership, Well
  2. Install and configure Entity reference, which provides a field type that can reference arbitrary entities.
  3. Add user references to both the Document and Partnership content types. This allows you to attach/associate specific users with this content.
  4. Add a node reference to the Well content type and under Field Settings > global settings, select Partnership, which is the type of content you would like referenced. This allows you to reference/associate a Partnership with a well.

These simple steps provide you with a basic framework from which a user could login to the site, be directed to their dashboard, and gain access to documents that belong to them, Partnerships they are associated with, and potentially a map which provides a listing of all the wells they own interests in. Pretty cool!

Obviously, there are security measures that need to be considered when creating user-specific dashboards of data, but we will leave that for another discussion at another time.

If you’ve solved some fairly complex issues using user or node references, I would love to hear from you. The use cases seem endless. If you are interested in other ways to use the Entity API, check out Randall's post.

Share your comments below!

 

Drupal Learning Curve too Steep for the Weak

I am sick and tired of hearing that the Drupal learning curve is much steeper than the WordPress learning curve. The reality is, both platforms are starting to converge in several areas.

If we're going to look at Wordpress vs Drupal, let's be fair. Drupal is a web content management framework that can be extended vastly. WordPress is the Best-of-Breed blogging platform that continues to evolve into an extensible content management system. Different? Absolutely. But as both platforms progress, both become closer in both capabilities, the ability to extend, ease of use, design and even...difficulty to learn.

I'll begin by giving a little background into my experience and then go from there. I have a degree in graphic design. If I'm going to use a web application, it's very important that little programming experience is needed because I have a limited skill set to troubleshoot bugs. That being said, I've built my own osCommerce sites nightmares and know the pain that comes with trying to search through lines of code to hack in a module or extra functionality. In addition, I also ran my own WordPress blog for at least 3 years, but migrated to Drupal once LevelTen moved to Drupal; needless to say I can shoe string something together if I must.

When we began using Drupal here at LevelTen, it took a good 6 months to really get my head wrapped around it. At the time, there weren't the excellent books, videos and other resources that exist now. Drupal training wasn't something you could find in a local class, but thankfully today, that's an option almost every day of the week. Plus, there's no need to start at ground zero and download Drupal out of the box; instead, start with one of the great Drupal distributions that are readily available to accelerate your development and learning time.

Personally, I've been using Drupal for 6 years now and I continue to learn every day. The web also changes every day and there's an ever expanding selection of modules to make Drupal better. Guess what? 99% of the clients I work with don't need to know about those changes; they just need their website to work and not be locked into a solution that can't grow with their business.

In the end, learning anything new is never an easy task, but if you use the tools that are available to your advantage you'll be able to get that simple WordPress learning curve on your super powerful Drupal website.

Do you find that Drupal is difficult to learn? When you look at Wordpress vs Drupal, what are your thoughts? Share your comments below!

Twitter Chooses Drupal Again, This Time for Gasp, Their Blog

Twitter recently re-launched their blog and they chose Drupal over WordPress

I've been telling people for years that if you just want a blog, WordPress is a great option. Twitter's decision to use Drupal as a blog makes me wonder a bit. Why would a company with their development and technical expertise choose Drupal vs WordPress if they're just building a blog? 

Here are a few reasons why I think the decision was a no-brainer:

  1. Let's all agree that Twitter isn't some mommy blogger or small business, so their needs are probably a little different. Saying "It's just a blog" isn't true.
  2. They built dev.twitter.com on Drupal so they're already familiar with Drupal's ability to be customized and expanded; plus why introduce a new technology that team members have to learn?
  3. Drupal's security and protocols are a major plus over WordPress. Why else would WhiteHouse.gov have chosen it over other options? 
  4. Not that they need it, but Drupal offers Enterprise Class Support with Acquia. Where's that solution on WordPress?

Look, my goal here is not to bash WordPress. I've used it in the past and it has its place; but in the end decisions like this only help to reinforce the argument that Drupal is the superior open source platform.

Do you think it was a good decision for Twitter to use Drupal over WordPress? Let us know in the comments.

Best Drupal 7 Responsive Themes

When I told Mark Carver that I was compiling a list of responsive themes for D7, he rolled his eyes and shook his head at me. While Product Owners (and some clients) may be seduced by a pre-built theme, experienced themers know better. Mark eagerly pointed out to me, “just because it looks good, doesn’t mean it works." I laughed to myself, having learned this lesson in my early 20’s.  

You see, there's more to a pre-built theme than meets the eye. It often comes with a little site build of its own, making it very difficult to mesh with an existing Drupal distribution or site. That said, if you're starting from scratch and Marinelli just doesn't do it for you, a pre-built theme may be just what you need to get started.

Is this your first Drupal rodeo? Start with one of these cheap and easy Drupal themes. They are good looking, responsive, and simple to get up and going.

In Drupal for the long haul? Consider the following eye-candy inspiration for your next custom theme:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  

 

 

Facet Block - The Unknown Hero

If you have ever worked with Search API, Facet API, and Solr, you know how awesome and powerful these tools are, especially when combined with Views. Unfortunately the way it works, sometimes you're forced to build some things a little bit differently to get around some of these pitfalls. Sadly, I haven't seen one piece of documentation on the Facet Block views plugin, and it took me awhile to figure out that the hell it was there for, so I'm sharing my research with the people of the internet.

Starting with a quick run-down, whenever you use a Views search page, you base it off the index you built in Search API. So if I defined and built an index for all nodes that filters on a title, body, and taxonomy fields, that is the index we would build the view on. Once you have your search view and facets configured, you're all set! Now we can go to our search page and start filtering out results to drill down to exactly what we're looking for. The facets work by hooking into the query that is being run by Views to alter what is being returned based on the selected filter. Let's put these facets on a landing page so people can immediately start searching for something!

… derp. Nothing. The reason the facets don't show up is because there isn't a search query being run on that page, and I don't want to have to make another search view page for a landing page, and blah blah blah. It gets ugly. So what are some other options? Well, the most popular fix was something I call "faux facets". We basically create a regular block view of taxonomy terms for whatever vocabulary I'm indexing, and then rewrite the URLs with the equivalent search URL, which may look something like this:  

http://example.com/content-section/search?f[0]=field_category%3A36

That's a bucket of fun if I've ever seen it. Now I have to style the thing to look just like the facet block I already have. It might not have the same count number as the facet, however, and it's very frustrating. Luckily, we now have something up our sleeve - the Facet Block display. 

We can create a Facet Block display on our current search view, give it a name, tell it which search page we want it to redirect to if someone clicks on a filter, and what Facet field information (like a Category taxonomy) we want to display. And the best part is, we can put this anywhere we want! No more random view pages or faux facet taxonomy blocks, we can use the data given to us by the search index.

 

Do you use Search API often? What are some of the tricks you use to build more effective searches?

Made-to-Order Maps with Leaflet API

There are a number of solutions for building maps within Drupal - GMap and OpenLayers being the de-facto standard for doing mapping. However, Leaflet is an up-and-coming module and is great if you need highly customized maps, which can be a bit strenuous using the other options.

What is Leaflet?

Leaflet is a free javascript library from CloudMade for generating maps. The nice thing about this is that you are not tied to any particular service for generating your map layers. In fact, if you're using something like the MapTiler app (for MacOSX), or any number of free open-source map-layers, you can get some pretty wild looking map designs. MapBox is an awesome 3rd party tool that gives you the ability to easily customize the colors of a standard map, which is usually exactly what clients want.

Check out some of the examples on the CloudMade site.

How do I use it?

While the Leaflet module is still pretty new, you can probably accomplish most of what you'll need to do with little configuration, and maybe some custom code. Let me show you how to create highly-stylized maps using the API.

Start by installing the following modules:

You may also want to use the following modules for geocoding addresses (if that's what you're into):

There are also several modules that provide additional map styles.

  • leaflet_mapbox - MapBox gives users the ability to control the styling and colors of a map. This is an awesome solution for anyone needing a little more control over the general "look" of the map that's not provided with the other map styles.
  • leaflet_more_maps - Provides a number of other custom map styles for use wherever Leaflet is integrated. 

You'll need to start by adding a geofield to a content type. This will be used to contain the longitude and latitude coordinates of the map point. In this demo, I'm creating a "point" content type and adding a geofield called "field_coordinates"

Next, build your data set. There are a number of ways to do this, and although you can use views to build Leaflet maps, views will load each entity which can be very taxing on the system when you've got many points (ie: thousands of points). You probably want to write some kind of custom query. For this example, I'm simply going to query every published "point" node.

In doing this, we will also build our data array to pass into Leaflet to build the map. 

The $points array is where the map data is being stored. For large data sets, it will probably help to utilize the canvas circles instead of image icons on the points. This will drastically increase load time. This can be done by applying this patch and using the following structure instead:

Now, using hook_leaflet_map_info() provided by the Leaflet API, define your map style and defaults. This is where you would specify the URL to the map tiles using the urlTemplate attribute in the map layer. In this example I'll use the Toner map from Stamen, although there are a number of places to find other fancy map styles.

Lastly, use hook_menu() to create a page where you will render the map, and use leaflet_render_map() to return the map:

And there you have it, a nice looking black and white interactive map. You won't find that with OpenLayers or GMap.

Have any questions, suggestions or comments? Leave us your thoughts below!

Top 13 Reasons to come to DrupalCamp Dallas NEXT WEEKEND!

Just one week from tomorrow is the 5th annual DrupalCamp Dallas, and it's going to be 5 MILLION times better than any Drupal event ever.  Especially my session on the Hyperbole module.  But just in case you are still on the fence, here are 13 reasons why you need to gently climb down off that fence without getting any splinters and get your ticket right now:

  1. Jeff Walpole from the Drupal (and Wordpress :) powerhouse Phase2 is giving our Keynote Address on Can Drupal be a Disruptive Force in Social Business Software?  You wouldn't want to work at an unsocial business, now would you?  So come learn how to make it social. With Drupal.
  2. Three full tracks of great sessions, all day long.  Beginner?  Then come learn about Drupal SEO, Design, Tricks & Tips, and Scaling Drupal.  Expert?  Then how about sessions on Zombie.js, Mobile Video, and Drupal 8 Deep Dive?  Auto mechanic?  For you there's Chris Ruppel's session on Advanced Frontend Performance!  Heh .. get it?  Front-end?  Also a car term?  Uh, yeah, ok nevermind..
  3. Case Studies: Higher education, CiviCRM and Texas Instruments and possibly more.
  4. Pantheon is hosting a two hour training session Saturday afternoon on Development Best Practices and Building Sites on Pantheon.  Everything you need to be a great Drupal developer- version control, continuous development, workflow, and working in the dark until 4am while jacked on Jolt cola.  Do they still make Jolt cola?
  5. Acquia experts will be on hand Saturday morning for Acquia On Tap - come ask any questions you have on security, performance, architecture, how well Dries can ski, and whatever else you might think of.
  6. Sign up for our companion Results Oriented Web Summit (ROW) on Friday and also get into the all-day Friday Drupal in a Day training event at the same venue.  Or go to some of the Drupal training, and attend any ROW sessions you want.  You should see the lineup of speakers they have at ROW.
  7. Once again we'll have the entire back room at the nearby Fox & Hound Pub on Friday night with free drinks and food.  Come show off your pool, darts, and sitting skills.  The ROW crowd will be joining us, and I think I can say without stereotyping that all marketing people are much more attractive than us Drupal developers.  So you'll want to make that party.
  8. Spud and Sandwich Bar!  Keeping the DrupalCamp Dallas tradition going of having the best food of any other Drupal event, we are planning a make your own sandwich and spud bar. Make your own lunch- 'cause we are not your mother.
  9. Giveaways!  We'll have some very nice sponsor gifts, including full Drupal development and sitebuilding video courses from Buildamodule.
  10. Robert Ristroph submitted so many session ideas that we are just going to go ahead and give him his own track.  All Robert Ristroph, all day.  Sessions will be held in the Robert Ristroph room.
  11. Last year we tried to kill Josh Koenig from Pantheon at our post-Camp mountain bike ride. He survived somehow, with a cunning mix of biking skill and total lack of fear.  So we'll be trying again this year, Sunday morning at nearby Rowlett Creek Preserve.  Join us!
  12. Remember when we did the Camp in summer, and it was 107 degrees?  Ahh, good times. Current forecast this year is sunny and in the 70's.  That walk from the parking lot to the air conditioned Culwell Center is going to feel great!
  13. and finally ... one really, really big surprise.  Really.  No hyperbole this time.

Ok- if all that doesn't convince you to spend next Saturday (and Friday!) with us, then all hope is lost.  Just go ahead and enjoy a beautiful weekend playing golf or spending time with your family instead of a bunch of sweaty Druplers.  We'll understand.