Planet Drupal

Links Corralled by Lullabots

FCC Sponsors API Work

The recent launch of a newly-redesigned FCC.gov web site is a big win for Drupal, and a great example of public-access APIs being built into large government web sites. Seabourne Inc.'s post about the migration also details the new contrib module, Content API, that the project spawned. Built on top of the popular Services module, it automatically exposes select content types on a Drupal site via a REST interface. A little bird told the Lullabout Roundup Cowboy that a D7 version of the module is coming soon, as well...

Give it a REST

Speaking of REST and web APIs, an interesting article by designer Luke Wroblewski discusses the potential for API driven and server-side tools to simplify the implementation of responsive web designs. Confused? Check out Jared Ponchot's article on responsive design, and developer Steve Klabnic's article, Nobody understands REST.

All Documentation Isn't Equal

In this screencast I'll cover the newly created Regions API that I built while developing ELMS. There seemed to be a million different ways that people were handling the adding of bars in drupal. Regions Module Project Page Download Regions Module ELMS Nav Right Module

read more

The Drupal Community track will be used for discussing and presenting ways to continue to grow the Drupal Community. As the community grows, we are continually faced with the issue on how to keep the communications open and helpful to as many members as possible.

Angie Byron is a community role model. Her dedication to the Drupal community and excitement about the project is truly unprecedented. She's the Drupal 7 co-maintainer, co-author of the O'Reily book, Using Drupal, a Drupal Association board member, and currently works for Acquia as the Director of Community where her primary duty is to help the Drupal project and community grow. Angie has presented at camps and cons across the world and we are thrilled that she'll be speaking in Denver.

Johan Falk is a Drupal trainer and a frantic producer of screencasts for site builders. His passion lies in making Drupal modules work well together and showing others how it can be done. His book Drupal 7 – the Essentials is being donated to the Drupal community as a starting platform for new documentation. We're honored to have Johan speak at DrupalCon Denver!

There's already quite a few sessions proposed in the Community track, but we're always looking for more! How do we attract new contributors? How do we keep the old contributors interested and engaged? What's the best way of presenting the community information to the members of the community? Answer some of these questions or come up with your own to present at DrupalCon Denver. Submit your session proposal by October 26th!

The increasingly rapid growth of the Drupal project has been the subject of some recent debate and discussion within the community. Some Drupal developers have argued that the core software is getting too large and too complex to sustainably maintain, while others have expressed concerns about the evolution of the business ecosystem and the perceived consolidation of developer talent. (A more detailed summary can be found here)

While these kinds of debates can sometimes get fairly heated, I think the fact that these issues are being discussed openly is a tribute to the strength of the community and a point of difference between Drupal and other software projects.

Back in the fall of 2008, as the global economy was teetering on the edge of oblivion, I happened to be reading Jared Diamond’s “Collapse”, a book that explores the reasons that some human civilizations flourish while others fail. A section of the book that describes the “bottom-up” approach to solving problems employed by the people of the Papua New Guinea highlands resonated strongly with my recent experiences at DrupalCon Szeged.

Before the arrival of European colonial powers in the 20th century, New Guinea highlanders lived for thousands of years with no centralized authority. Decisions in each village were made by community consensus, with anyone able to chime and and offer their opinion on a matter under discussion. There were no formal leaders or chiefs: some people were informally recognized as “big-men”, whose voices were more influential than others, but these people otherwise had no special status or privileges.

As Diamond describes it:

Decisions were (and often still are today) reached by means of everybody in the village sitting down together and talking, and talking, and talking. The big-men couldn’t give orders, and they might or might not succeed in persuading others to adopt their proposals. To outsiders today, that bottom-up approach to decision-making can be frustrating because you can’t go to some designated village-leader and get a quick answer to your request; you have to have the patience to endure talk-talk-talk for hours or days with every villager who has some opinion to offer.

Anyone who’s spent any amount of time in a Drupal module issue queue, participated in a discussion on groups.drupal.org, subscribed to a Drupal e-mail discussion list, or participated in a Drupal coding sprint will immediately see the parallels. Decisions are rarely made quickly within the Drupal community; they’re discussed, debated, and argued over at length before a consensus is reached. Even when everyone involved is in agreement, people still often feel the need to chime and express their opinion. And while there are some folks whose opinions carry more weight than others, they can still be overruled by the will of the community.

Just as the outsiders often find the experience of interacting with New Guinea highland villagers a frustrating one, navigating one’s way within the Drupal community also often requires patience and perseverance.

Lest anyone be concerned by the fact that I’ve just compared the Drupal community to a tribal society lacking in advanced technology, Diamond points out that over the years, the people of the New Guinea highlands developed sustainable farming methods so sophisticated that Western agronomists draw inspiration from them even today. These methods were iterated over thousands of years, with people freely and openly sharing knowledge with each other, then building on it with each succeeding generation.

Likewise, Drupal innovates through the free and open sharing of information, with each release building on the lessons learned from previous versions. This is one of Drupal’s key strengths, and an advantage it has over other platforms that are either tightly controlled by a single entity or have less robust developer ecosystems. I think it’s important that the community recognize this and embrace it as a natural part of the open source software and community development process.

At the same time, I also think it’s also important to recognize that not everything in the community can or should be driven by consensus. Even within bottom-up societies, there are numerous examples of “top-down” problem-solving techniques being applied to issues that go beyond the immediate needs of the existing community.

A couple years ago, I argued that as the popularity of Drupal continues to grow, it's inevitable that the majority of its users will become people who are not involved in or even aware of the community that develops it. Being able to meet the needs of this audience will require going beyond purely consensus-driven approaches because not all voices will be equally represented in the discussion. Consensus-driven models assume that all interested parties can participate in the decision-making and we need to be candid that as the community continues to grow that cannot and will not always be possible.

We’ve already seen that successful execution of large community projects like the drupal.org redesign, the Git migration, and the bi-annual DrupalCon conference requires some degree of structure, project management, and leadership. This is why the Drupal Association has spent the last year hiring staff members and restructuring so that volunteer board members are less responsible for the day-to-day operations of the organization. These moves will not only strengthen the Drupal community, but also make it easier for more “invested, but disengaged outsiders” to become involved.

I also think we need to be cognizant of the fact that as we debate and argue in the open, there are more people watching than ever before, and many of those people lack important context or background on many of the issues that face the Drupal community. Frank and open discussion is a good thing, but it needs to be respectful of others and not people away from the community. That’s why we have a Code of Conduct, which provides an excellent set of guidelines on how to interact with others in a way that preserves the Drupal community’s welcoming spirit.

Drupal is not in a crisis, but it is growing rapidly, and rapid growth sometimes requires change. The people of the New Guinea highlands faced numerous changes to their environment, population growth, and other challenges over their 46,000 year history, yet still succeeded in developing one of the most stable and sustainable civilizations in human history. I believe that the Drupal community has the potential to succeed in the same way.

Over the last of couple weeks we’ve been working on a mobile site/app, with a very standard layout: a location bar fixed on the top, a menu fixed on the bottom and the content being printed in between. I thought this would be a walk in the park until I realized that Safari on the iPhone doesn’t support scrolling inside divs, and “position:fixed” doesn’t really behave like it does on desktops.

read more

As you may have heard, Rackspace is Pantheon's primary infrastructure provider. When explaining ourselves to Drupalists and web professionals, people often ask, "Why? Why Rackspace?"

This the first in a series of posts where we answer some of these common questions that don't neatly fit into a standard FAQ. We hope you enjoy the "Inside Pantheon" tag!

Performance

We've got deep roots in the world of high-performance Drupal — David is the main author of Pressflow, and Josh put together the popular "Mercury" stack. One of our primary commitments with Pantheon is that it should run as fast as possible, always. That includes the sites we power as well as our own control panel.

Based on our years of experience in consulting, we know the two most common (and difficult) bottlenecks for Drupal on the infrastructure side are CPU and disk I/O. When diagnosing a slow site, if it isn't an obvious flaw in the server configuration, or site-specific code gone wild, it almost always comes down to execution of PHP or database accessing the physical disk.

The Rackspace Cloud offers good guaranteed CPU speed, as well as the ability to burst if there is idle capacity on the resident chassis. They also bundle high-speed RAID-ed disks which offer the best we've seen in terms of cloud I/O performance.

In contrast, we know from our experience releasing Mercury as an AMI that EC2 doesn't lead the field in either of these areas. Their instances are relatively underpowered in the CPU department and the virtual disk they provide is slower.

While there are some trade-offs in every decision (e.g. Rackspace provides smaller disk quotas and lacks as mature a services ecosystem vs EC2), we felt that performance and reliability should come first. That made our decision easy.

Hybrid Vigor

Rackspace's Cloud also has some attributes that just aren't there with a lot of other providers, specifically the Hybrid model, which lets users intermingle traditional hardware solutions with cloud resource as needed. This is used by the likes of Github, the Grammys (thanks to Lullabot), and others.

One hybrid use-case is for extremely heavy database loads, where physical servers will always outperform a cloud. Another would be to provide PCI-compliant backends for high caliber ecommerce use-cases.

Being able to leverage the "best of both worlds" between VMs and bare metal has a lot of potential as we look ahead with Pantheon. We haven't implemented any of these solutions so far (no, Pantheon is not yet PCI compliant, yet), but these possibilites are another reason we chose Rackspace.

Supporting Open Source

We're open source to the core. In addition to supporting Drupal in a myriad of ways, we also sponsor the Twisted project (hey guys!) and make patch contributions to BCFG2 and Libcloud.

Rackspace is the primary supporter of OpenStack, a coalition initiative (including NASA, Dell and others) to create standard software for cloud management. In the long run, this is hugely important for the growth of a vibrant and open Internet. There should be many clouds, large and small, and we should have solid open source tools at this layer just like we do with TCP/IP, HTTP and Linux/BSD.

In addition, they continue supporting Libcloud after the CloudKick acquisition even though it interfaces with all sorts of clouds, not just theirs. They also maintain a great collection of RPM packages, and have a tradition of supporting the projects their business is based on. We can relate to that, and we feel good with a partner who shares our commitment to the continued flourishing of open-source.

This post is the first in a series where we answer some of the common questions people ask us that don't neatly fit into a FAQ. We hope you all enjoy the "Inside Pantheon" series, and if you have other topics you'd like to see us cover, let us know!

It's that time again for another Town Hall meeting. Since the last town hall meeting DrupalCon London was held, DrupalCon Denver and DrupalCon Munich were announced, and we are working on a number of new initiatives. At our Town Hall meetings we open our doors to connect with the community to hear from you, listen to your ideas and suggestions, and answer any questions that you may have. 

Come join us!

read more

Zivtech's Senior Developer, Howard Tyson, recently conducted a Node.js webinar with our partner Acquia.

read more

For the last two weeks, I've talked about A Developer's Perspective on Mobile Websites (part 1 | part 2). This week, I'd like to close out by going through a couple of the decisions I make for each mobile site I make:

read more

I hated the block system. There I said it. Many of you probably felt the same way. I've used everything I can think of to get around the block system and have built sites every different way imaginable. Recently though, I've had a revelation. The block system, while not perfect, actually is pretty good.

Lets start at the very beginning though. Originally I started out using the core modules that came with Drupal and placed blocks on pages which were usually nodes. This became kludgy very quickly as there became more and more nodes and blocks. The visibility rules for those blocks were usually really nasty php code that would totally hose the site if a syntax error occurred. Not only that but doing more complex layouts got difficult in a hurry as they required modifying the theme to add regions and then put those blocks in the region. Often times clients would want to have a page with a paragraph on top and then a two column set of images/text below. There was no easy way to do this. Either hard code some html and css in the node or edit the theme, add a two regions below the main region and add the css to make the columns line up. The latter was no good because to edit the page contents there would be 1 node and 2 blocks containing the content. Clients were confused.

Then along came panels. Ah, panels. Panels has some very ardent supporters out there (I'm looking at you, EclipseGc) and I'm sure to hear from them because of this. Panels solves the problem of the different layout styles and allows you to have the different columns on the website. Several problems start showing up though. First, the panels interface is daunting. As in way more daunting than views. Views has many options to choose from but it is basically one page with lots of options. Panels has a myriad of wizards and pages that are specifically designed to confuse newbies (ok, slight exaggeration here). Secondly, if you go panels, you have to go panels ALL THE WAY. Mixing panels and non panel pages is an exercise in frustration both from a usability standpoint (How do I change the block on this page? Oh, is it a panels page or not?) and a theming perspective (Why aren't the columns on this page the same width as the rest of the site? Oh, it's a panels page). In the end, we end up with client and themer confusion again.

We also have views which create pages of lists. Often times the client wants to put text on the top of the page. Then they ask how to change that text. Oh crap. First, edit the view. Ignore all the millions of confusing options and find the tiny one in the middle called "Views Header." Oh nevermind. I'll do it. Again, client confusion.

Another entrant came along called the context module. Context was the most awesome thing since sliced bread. You could specify conditions and reactions for just about anything. Granular control without programming. We were in heaven. Then we delivered the site to the client. Same old problems started occurring only possibly worse. How do I place a block on a page? Uh, go to contexts and add a context. See, you want to set up your conditions for when it is visible and then add a reaction for blocks... Oh nevermind, I'll do it. Then, they ask why a block is on a specific page and how to get rid of it. Crap, which context is placing the block there? Time to bust out the admin module again and start hunting through contexts. This leads to everyone confusion.

Oftentimes we'll get wireframes and comps for a site and start building. For each page on the comp we'll pick the type of module to build the page that most closely fits the comp. If the page is simple text and images we'll use nodes. If we see a list of things we'll use views. If we see column data on a page we'll use panels. To place blocks we'll use context. Then we deliver to the client. As stated above, this is where things get messy. Clients don't understand views, panels or context. They don't understand why on one page they can click edit and start changing text but on another they have to edit the view and on another they have to navigate through panels. I've heard plenty of frustrated phone calls about how to add or remove blocks through context as well.

The thing I found again and again with clients is that in the end they just wanted a simple way to manage their blocks. Make it consistent and simple regardless of whether or not it was elegant. I'd build these amazing and complex systems and it confused them. They didn't mind entering 25 lines of node pages for block visibility so long as they could figure it out. This led me to a revelation.

The blocks system actually does work.

Why had I been doing everything I could to avoid it all these years? I'm not entirely sure but as I started playing around with Blocks in Drupal 7 things seem to just work. Yeah there is still room for improvement but it more or less works.

One of the things I've constantly run up against was that the blocks page gets very cluttered quickly. Often there are dozens of blocks in a region, each with different visibility settings. To help improve the situation I recently wrote the block_visibility module. It adds a column on the block admin page that shows the visibility for that block. This helps the situation considerably.

While looking around for other modules I found the viewreference module. At that point I had a revelation. Why not make (almost) every page on the site a node? Clients would be happy because every page would have an edit tab at the top where they could edit the page. By using viewreference I could attach a view at the bottom of the page. Then as I was building I realized that not everything I needed to attach was a view. Often clients want quicktabs or some other block to attach to a node. This is when I found the blockreference module. It is very similar to viewreference. It defines a field where you can attach a block to a node. When the node page renders the block is wherever the field is set.

As I set about building the site everything just worked. All the pages were the same page content type. The content type had two additional fields, a view reference and a block reference. If either one was set then the page would have some additional more complex information below. All blocks were set with the block system so the client could figure out how and where to set things. Since all the pages were nodes, it was fairly simple to figure out.

So far this has been such a huge success in simplifying the administration of the site that I'm planning on doing very similar things with other sites as much as I can. There will still be a few cases where a views page is appropriate but overall I really like how it works.

What's funny about this is basically I've gone back to using nodes and blocks they way they were originally intended. This is probably a testament to how much Drupal 7 was improved.

If you enjoy our content, please consider subscribing through RSS, so you can read our posts in your application of choice.

After 6 months of planning, DrupalCamp Montreal finally came together mid-September. We were all really excited for how this year would pan out. With a smaller, leaner organizational team, the core group of volunteers quickly secured a location, set up a website and selected keynotes.

Tags: DrupalCampMontrealMultilingualDrupal Planet

During DrupalCamp Berlin fago, sun and fubhy (me) actively discussed the entity concept and especially the entity controller concept.

The topics we talked about

1. How to split up the current EntityController into separate, more specialized controllers (storage, cache, etc.).
2. How to combine functionality of separated controllers in cases where two or more controllers need to collaborate (e.g. storage and caching).
3. How to design the structure of hook_entity_info() to support multiple controllers.

Dividing responsibilities

For maximum flexibility Drupal 8 entities will need separated and specialized entity controllers. The benefits of this are obvious:

We would be able to simply override the cache controller to include a persistent (database?) cache on top of the static caching or the like.

It is also a matter of purity: Each entity controller should really just do one thing: Caching // Storage // Display // Form // Access or module integrations like Views integration … and so on.

By providing specialized controllers we provide clean interfaces and allow the “end-developer” (heh) to easily access and manipulate how entities are integrated in the system. Developers can choose among the provided controllers or customize them to their specific needs.

Separating entity controllers is going to help us with disentangling the mess in core.

The logic around the entity controllers

There are a few slightly different suggestions for how retrieving entity controllers should work.

1. The entity() function as universal entity controller manager.

This proposal comes with a new function named entity(). This function would deprecate entity_get_controller() and would be universal, as it would be able to fetch and return any type of controller that is available to the entity type. This function would accept two arguments: a) the entity type and b) the name of the controller. Such a function would probably work like this:

<?php
function entity($entity_type, $controller_name = 'storage') {
  // Return an entity controller.
  // Note: It might be handy to make $controller_name default to 'storage'.
}

// Examples:
entity('node', 'cache')->flush();
entity('node')->loadMultiple(array(1, 2, 3));
entity('node')->save($entity);

// Or consider other possible controllers:
entity('node', 'display')->view($entity);
entity('node', 'form')->build($entity);
entity('node', 'form')->validate($entity);
entity('node', 'access')->access('view', $entity);

// Further controllers could be added by contrib,
// which would have to care about exposing the data to their own hooks.
// Some pseudo examples:
entity('node', 'views')->viewsData();
entity('node', 'rules')->eventInfo();
?>

2. The entity_$controllerType() function as proposed by pounard

Another suggestion was to use entity_$controllerType() instead of the plain entity() function. We would then have one dedicated function for returning one specific controller type instead of a universal function. This would give us auto-complete as well as static code validation, and so on. However, there is also a disadvantage in comparison to the plain entity() function: Each module that comes with a new controller type would have to declare a function for retrieving said controller type.

Working with the pattern from this proposal would probably look like this:

<?php
// Examples:
entity_cache('node')->flush();
entity_storage('node')->loadMultiple(array(1, 2, 3));
entity_storage('node')->save($entity);

// Or consider other possible controllers:
entity_display('node')->view($entity);
entity_form('node')->build($entity);
entity_form('node')->validate($entity);
entity_access('node')->check('view', $entity);
?>

With this proposal it might still be good to fall back to a universal entity() function for the centralized static caching of the instantiated entity controllers. This would make the entity_$controllerType() functions nothing but shortcuts for the entity() function.

3. The magical entityFactory as proposed by chx

This suggestion is based on the following code snippet:

<?php
class entityFactory {
  function __construct($entity_type) {
    $this->entity_type = $entity_type;
  }

  function __call($name, $arguments) {
    $info = entity_get_info($this->entity_type);
    $class = $info['class'][$name];
    $entity_object = new $class;
    return call_user_func_array(array($entity_object, $name), $arguments);
  }
}
?>

It would allow us to use entity($entity_type)->$methodName() like magic. Every $methodName would need to store its class into the entity info. As for now, even though this looks pretty cool at first glance, it might make things more complicated then they should be.

Conclusion

Whichever solution we might choose: With this concept we will be able to access all entity controllers quickly, provide clean and readable code while also allowing (contrib) modules to provide their own custom entity controllers (e.g. ViewsIntegrationController, etc.) easily by adopting this pattern.

Extensible integration controllers would allow contrib modules to provide a good generic default implementation for entities, while the entity-type providing module can easily customize or exchange the default by customizing the controller. That way alter hooks like hook_views_data_alter() remain unused, so it remains available for other modules.

Separating and combining entity controllers

Now we got all these really cool specialized entity controllers that all control one thing each and work independent of each other. But how do we achieve collaboration between all these? We agreed that it is important to separate the single controllers from each other. Therefore collaboration should really happen on a higher level and outside of the controllers. A good example for this is entity_load(). This function would first try to retrieve as many entities as possible from the cache via the cache controller, and then continue to load all remaining entities via the storage controller. This means: A controller never loads one of the other controllers and invokes methods on them.

Deletion and saving of entities would work similar: Every time we delete an entity via something like an entity_delete() function we first delete it via the storage controller and then remove it from the cache controller.

We also discussed whether it would make sense to add a “wrapper” controller around all entity controllers and use that as the place where the collaboration of the specialized entity controllers would happen. However, eventually we all agreed that this would be overkill as the wrapper functions are actually pretty simple.

E.g. the entity_load() function could look like this:

<?php
function entity_load($entity_type, $ids, $conditions) {
  // Initialize an array to be populated with entities by the cache and storage controllers.
  $entities = array();
  if (!entity($entity_type, 'cache')->getMultiple($ids, $conditions, $entities)) {
    // The cache controller was not able to retrieve all requested entities. Retrieve the remaining
    // entities via the storage controller.
    entity($entity_type)->loadMultiple($ids, $conditions, $entities);
  }
  return $entities; 
}
?>

Another example of how much simpler and easier our code would become is entity_load_unchanged():

entity_load_unchanged() first resets the cache for the entity that is requested. This is bad, because we don’t really want to lose the cache here... We just want to load the original (unchanged) entity from the database. With the concept outlined here we could just skip the cache controller and load the requested entity directly from the database:

<?php
// Before
function entity_load_unchanged($entity_type, $id) {
  entity($entity_type)->resetCache(array($id));
  $result = entity($entity_type)->load(array($id));
  return reset($result);
}

// After
function entity_load_unchanged($entity_type, $id) {
  return entity($entity_type)->load($id);
}
?>

entity_load_unchanged() is a wonky workaround currently as there is no (clean) way to skip the cache while loading an entity, since that is a part of the current load method in the controller.

There surely are more examples that prove this point but as you can see we would be able to control entities much easier by invoking completely specialized operations instead of functions with 2, 3 or 4 different purposes.

Declaring responsibility

We would like to change the structure of hook_entity_info() to reflect the changes in the entity controller concept. Here is an example (simplified):

<?php
function node_entity_info() {
  $info['node'] = array(
    'label' => t('Node'),
    'controllers' => array(
      'storage' => array(
        'class' => 'NodeStorageController',  // Custom storage controller
        'base table' => 'node',
        'revision table' => 'node_revision',
      ),
      'cache' => array(
        // It’s debatable whether we need an intermediate controller or
        // whether we can directly rely on the already defined cache system interface.
        // For advanced caching functionality (like LRU caching) we would still need a custom
        // implementation of course.
        'class' => 'EntityDefaultCacheController', // Permanent cache() + static cache controller
        'class' => 'DrupalDefaultDatabaseCache', // As known as cache($bin)->get()/->set()/etc
        'bin' => 'node', // Custom cache bin
        'static cache' => TRUE,
      ),
    ),
  );
  return $info;
}
?>

The settings of each controller should be defined together with the controller class in a sub-array to keep the parent array level clean. Each controller has its own, unique array key to work with the entity() function. Each controller is initialized with a) the entity type and b) the settings that are defined for it (additionally the controller could still pull the whole entity info by invoking entity_get_info($entity_type).)

A way forward

As this is a massive change in the architecture and would affect all entities that are currently defined in core I would suggest this:

1. Start by creating the controller interfaces and their default implementations.
2. Change the hook_entity_info() structure to work with the entity() function (as suggested).
3. Split the current entity controllers to use the new pattern.
4. Change all functions like entity_load() etc. to work with the new controllers and assign the new controllers to all core entities.

Tomorrow is the last day of Summer but the Drupal training scene is as hot as ever. We’ve scheduled a number of trainings in Los Angeles this Fall that we’re excited to tell you about, and we’re happy to publicly announce our training assistance program.

First, though, we’re sending out discount codes on Twitter and Facebook. Follow @LarksLA on Twitter, like Exaltation of Larks on Facebook or sign up to our training newsletter at http://www.larks.la/training to get a 15% early bird discount* toward all our trainings!

Here are the trainings we’ve lined up. If you have any questions, visit us at http://www.larks.la/training or contact us at trainings [at] larks [dot] la and we’ll be happy to talk with you. You can also call us at 888-LARKS-LA (888-527-5752) with any questions.

Beginner trainings:

• Drupal Fundamentals on October 31, 2011

Intermediate training:

• Drupal Architecture (Custom Content, Fields and Lists) on November 1 & 2, 2011

Advanced trainings:

• Scalability and Performance on October 31, 2011
• Developing RESTful Web Services and APIs on November 3, 4 & 5, 2011

All our trainings are $400 a day (1-day trainings are $400, 2-day trainings are $800, etc.). We’re excited about these trainings and hope you are, too. Here are some more details and descriptions.

read more

At the last Druapl Indy User Group meeting, I did a presentation on integrating Openlayers and Apache Solr. In the presentation, I walk you through how to setup and configure the modules necessary to display search results on a map in Drupal 7. This is the same basic process which we used on Energy.gov.

The video is about 45 minutes long, so here is a general outline of the presentation. Be sure to watch the entire video or you will not see how all of the pieces are integrated:

read more

Today, we issued the Alpha release of OpenPublish on Drupal 7. This is truly a "developer's release" focusing on core capabilities necessary for a news and publishing website. Unlike OpenPublish releases in the past, it comes with no flashy sub-themes, no bells and whistles. This is an early release of OpenPublish, meant for testing, use, and contribution by experienced developers in the Drupal community. You won't find a "website in a box" here, and we have good reasons why.

The Mobile track at DrupalCon Denver is focused on building Drupal sites and services for phones, tablets, and other non-desktop devices. Mobile technologies — both in terms of web development and native mobile apps — are rapidly changing how visitors and site administrators interact with the web, and this track will cover how we can make the most of Drupal across these new frontiers. We're excited to feature two speakers: John Albin Wilkins and Kyle Browning.

John Albin Wilkins is a core contributor and maintainer of the ever-popular Zen theme and several contributed modules. He will be speaking on practical responsive design in Drupal. Responsive design is a philosophy that designs should adapt to the capabilities of a device, and do so smoothly and efficiently using media queries, CSS, and JavaScript.

Kyle Browning is working on native mobile applications and Drupal. He's using Drupal as a framework to power applications across a wide variety of platforms. Drupal is a very capable backend for mobile, and Kyle is going to show you that it's actually not as hard as it sounds.

Do you have an idea for the Mobile track? Are you using Drupal in interesting ways on phones or tablets? Propose a session! The session submission deadline is October 26.

A week or so back, Mediacurrent wrote a thought provoking blog post about how Drupal is at a crisis point and losing the CMS marketing battle. The article expounds upon Dries' DrupalCon London State of Drupal keynote, calling on the community to better market Drupal. While I wholeheartedly agree with the points in the post, I think there is a bigger picture opportunity for marketing that is being missed.

In the three and half years LevelTen has been doing Drupal there have been a couple things that seem a bit odd to me about how the community promotes Drupal:

1. Drupal shops spend a lot of time marketing to other Drupalers
2. Drupal pundits are very focused on the technical benefits of Drupal

It seems that most Drupalers primary focus is on building cool stuff. It even says it on several Drupal shop websites, "we build cool stuff". The buzz is always on how technically awesome Drupal is. But at the end of the day, what the CIOs, Marketing Directors and Brand Managers want are business returns. More and more, websites are owned by the marketing department.

Sure, we are developers. Fields/CCK, Views, Imagecache, Features, etc. are all really cool stuff. But these are just features, it is benefits that sell; at least to marketing directors that don't know a node from a content type. When you talk to a marketing person about all these features, their eyes glass over. I know, being a developer I have a tendency to engage in Drupal techno babble with the wrong audience.

So here is the good news: Drupal is really awesome at getting business results.

There are a fairly sophisticated set of elements that are required to make a website successful: UX/branding, traffic, social integration, visitor engagement, conversion, retention, process improvement, continual innovation, etc. Drupal does it all, better than anything we have seen in our 12 years of building websites. It is why we switched to Drupal in the first place. It's why other businesses and non-profits should switch too.

But wait, there's more.

If an organization really wants to get a jump on the future, they should be diving into Enterprise 2.0 & social business initiatives. While Drupal is called a CMS, it is really a social platform. Drupal goes well beyond today's standard toolbox for getting results like SEO, social media integration and content interactions. It allows organizations to truly engage users, build community and foster brand champions like no other platform I have seen. Drupal Commons is probably the best example of this.

We need to get the word out.

What to do

• Go to non-Drupal meetups, particularly those that involve web strategy and marketing. Here in Dallas we like to go to things like DFW Scrum, Social Media Club, American Marketing Association, Startup Happy Hour, Usability Professionals Association, Dallas PHP, Print & Web Designers, etc. Get involved in the discussions. To implement strategy and marketing, you need tools. Drupal is an awfully good tool.
• Start a beginner Drupal meetup. I am sure your normal Drupal User Group meetings are like ours. A bunch of techies that have discussions that scare newbies. Start a separate meetup to ease people into it.
• Start a web strategies meetup. We just launched one in Dallas. We are going to have two montly meetups. A regular one with topics about marketing, project management, UX, etc. We are also doing a jumpstart course to help people build a solid foundation for driving results – and, surprise, the platform is Drupal. This is not a Drupal heavy group but we will weave it into the discussion. After all, great strategies need great tools.
• Drupal Business Summits. Houston had one, we had one in Dallas, Atlanta is having one, there is one in New Orleans. These are great ways to reach out to business and non-profit managers that would feel out of place at a typical camp.

Got any other ideas? I would love to hear how others are reaching out to business and marketing managers.

Photo by joshua aaron

Jakob Persson (aka solipsist) of NodeOne talks about his early estimation process for scoping out requirements and estimating the number of hours to build a project.

He talks about the process of breaking down the project into discrete features, determining whether or not you've built it before (add in more uncertainty if you haven't), and then estimating the number of hours in a range from high to low. If there are vague requirements, then it's going to add more complexity to the process.

Persson also describes the difference between making agile vs. fixed bids, and the importance of meeting with the client face-to-face in order to understand their requirements and to have the developers be able to ask direct questions. Finally, he mentions some of the most common overlooked things to account for such as testing, deployment, and managing communications with the client.

For more information, be sure to check out Persson's DrupalCon Chicago presentation on "Getting Early Estimates Right." Also be sure to check out Seth Brown's article on The Art of Estimation.

Release Date: September 22, 2011 - 9:58am Album: Drupal Voices Length: 9:59 minutes (6.91 MB) Format: mono 44kHz 96Kbps (cbr)

In this article I would like to talk about creating low bandwidth versions of websites running on Drupal 6.x.

The times of dial-up and other types of slow internet connections are (almost) over, but sometimes it's still important to give your users the option to experience a light version of your website. I will explain how to implement such functionality using the context module. This will also serve as a good example of how to write context conditions.

The idea is pretty simple; If a user clicks on a 'Low bandwidth version' link, we hide some “heavy” blocks on the site. As the context module can hide and show blocks, we only need to implement a condition and use it to switch between versions of the site.

read more

What this is about:
We've been hearing a lot from the community about wanting more transparency with regard to the Drupal 8 initiatives and their advancement. Every two weeks, the Drupal 8 initiative owners, along with Dries, webchick, and a team of project managers have “scrum of scrum” calls where each person goes around and talks about what they worked on since last time, what they’re going to work on for next time, where they’re blocked, and how the community can help.

So we're trying out this format for sharing these meeting minutes with you, and allowing a place for you to comment on and participate in these initiatives.

How you can get involved:
- Share your comments
- Contact an initiative leader to take on one of their action points!

Configuration Management

Greg Dunlap (heyrocker)

Status: Green

Headlines

• Sandbox code now reflects conversations that have happened since the initial summary.

Next steps

• Get some weekly or bi-weekly IRC convos going to get people involved. These will be every two weeks on Tuesdays at 19:00 UTC, starting on September 20.
• Speaking on 3 or 4 camps ( Copenhagen, pacific northwest Drupal summit, badcamp, do it with Drupal) in the next month, get some sprints planned to increase momentum. The first one will be in Copenhagen on Friday, September 23rd at the Nodeone offices.
• Review associated patches around entities and wscci.

Call to Action

• Need community to review the code and issues in the sandbox
• Get involved in the discussions.

Web Services

Larry Garfield (Crell)

Status: Green

Headlines

• Submitted Symfony2 HttpFoundation patch: http://drupal.org/node/1178246
• Held another IRC meeting, discussing architecture: http://groups.drupal.org/node/175544

Next steps

• As soon as we get HttpFoundation available to us in the WSCCI sandbox (either through the core patch or just put it in ourselves), we need to write a context handler for it. That will let us build a lot of additional context items atop it. This is a semi-blocker: http://drupal.org/node/1279942
• There's some important context core engine details being sorted out here: http://drupal.org/node/1261156#comment-4983832

Call to action

• Review/provide feedback on the UX issues: http://groups.drupal.org/node/160144
• Review code that people are submitting. (Please!)

Design

Jeff Burnz (jmburnz)

Status

Amber

Headlines

• Summer was slow; lots of people on vacation and some personal stuff.
• Ramping up and next week things will be rolling.
• After talks with Neil Drumm at DrupalCon, going to move design site from design.drupal.org to Drupal.org.

Next steps

• Make public statement of progress on the Drupal 8 initiatives group.
• Get Drupal.org testing site up and running.
• Figure out timing/scheduling of this initiative relative to HTML 5, Snowman, etc.
• Collaborate with Jacine on unifying accessibility and markup improvements under the same umbrella

Call to action

• Start fixing HTML 5 issues! http://drupal.org/project/issues/search/drupal?status%5B%5D=Open&issue_t...

Multilingual

Gábor Hojtsy

Status

Green

Headlines

• New and Improved: D8MI video and slides available http://groups.drupal.org/node/173569

• Sprinting in Montreal!

• Group of people working on UX issues (http://drupal.org/node/1260690)

• People working on documentation

• Big group of people working on Entity translation module issues, core API work, etc. It’s exciting!

• For example, we are hard at work to design how the initial screen would look for Drupal 8 in the installer:

Next steps

• Document as much as possible of our discussions so others can join in from the community
• Follow up on active issues; the initial install screen issue is getting good discussion there!
• Help drive more of the API changes in

Call to Action

• Review/provide feedback on the UX issues: http://drupal.org/node/1260690
• Work on the API issues: http://drupal.org/node/1260488
• Work on entity system, http://drupal.org/node/1269842 and followups

HTML 5

Jacine Luisi (jacine)

Status

Green

Headlines

• Activity is slowing down, we're not sure why
• Discussed the Modernizr going into core, CSS clean up
• Trying to collaborate more with the accessibility team
• Backported all the theme related issues that have been committed to the HTML5 project.
• Tracking community participation (yay!)

Next steps

• Write update for community on the last 4 months, status & next steps
• Try to get feedback about Modernizr + core, talk to Matt Farina, Katherine Senzee and Alex Bronstein about this.
• Try to identify community leaders who are interested in tackling some issues.

Calls to action

• Get feedback on including Modernizr (feature detection library) in core. HTML5 & JS experts please chime in here!
• Help is needed to update documentation for: Making your theme semantically correct
• Check out the Drupal 8 Markup Gates: http://groups.drupal.org/node/160254

PM Team

Angie Byron, Shannon Vettes, Melissa Anderson

Status

Green

Headlines

• Lots of people feelings lost as to overall status of D8 initiatives
• Working on reporting format for the community

Next steps

• Plan to discuss: dependencies, scheduling/deadlines, criteria for must-haves

Action items

• Post this report! :)

Core