Drupal

We've now wrapped up the first Drupal Coworking Friday and it was a resounding success. We had an estimated 100 attendees worldwide across three countries and 10 cities. The good news is even more cities want to participate this month!

I'm writing this post as a quick update so the curious know how it went overall but ultimately I wanted to thank all of the attendees, hosts and sponsors. Without these three groups this event (well, the first of many events) would have never happened. A special thank you to the hosts and sponsors that took time out of their lives/busy days (as well as money) to make this a reality for the general Drupal public.

Start:  2012-02-21 16:00 - 17:00 America/New_York Online meeting (eg. IRC meeting) Organizers:  Jacine

Please join us for our 20th bi-weekly meeting to discuss issues and progress related to the Drupal 8 HTML5 initiative. The meeting will be held in #drupal-html5 in IRC at 4 PM EST.

Agenda

During the meeting, we will discuss the progress of the current sprint and schedule issues for the next sprint. Please post your proposed discussion topics in the comments if you have any.

Subscribe

You can subscribe to the Google Calendar for this and future meetings via the iCal or XML feeds.

IRC Meeting Log

Posted after meeting.

Drupal 8 Initiatives

The first-ever election for two at-large Board Members of the Drupal Association was just completed with the selection of Donna Benjamin (KatteKrab) of Australia and Steve Purkiss (stevepurkiss) of the United Kingdom. The two new board members were elected by members of the Drupal Community and then ratified today by the Drupal Association board. They join the current eight Board of Directors of the non-profit Drupal Association in helping to establish policy, hire and manage an executive director, review and approve the budget and financial reports, and participate in fundraising.

read more

Only a few weeks remain until the next DrupalCon, which will be held March 19-23 in beautiful downtown Denver, Colorado. DrupalCon is the international event that brings together the people who use, develop, design, and support the Drupal platform as well as other luminaries from the open source and Web development communities. The final program schedule was recently released, and includes several sessions from members of the Palantir team:

Drupal Media
Dave Reid and Advomatic’s Aaron Winborn will discuss the past, present, and future of the Media module, which provides a unified framework and interface for managing all kinds of media assets in Drupal 7 and beyond.

Practical Responsive Development in Drupal
John Albin Wilkins goes beyond the basics in this session, which explores different implementation techniques for responsive designs using CSS (or Sass/Compass) and various Drupal themes and modules.

Flexible, Fast, Friendly: Balancing Your Architecture
Larry Garfield will talk about how to understand and think about competing priorities and trade-offs when designing software architecture.

Lessons Learned: Open Source Contributions - A Case Study of Workbench
Since its public debut at last year’s DrupalCon Chicago, the Workbench suite of modules has rapidly become the go-to solution for user access and workflow management in Drupal 7. In this session, Colleen Carroll and Robin Barre will discuss the process of developing Workbench with a focus on business strategy, sustainability, and community involvement.

Making Drupal Core Mobile-Friendly
John Albin Wilkins will join Jeff Burnz of Adaptive Themes and Capgemini’s Lewis Nyman for a panel discussion on the work of the Drupal Mobile Initiative to make Drupal 8 truly “mobile-friendly”.

In addition to these sessions, a number of Palantir team members have submitted presentations for Core Conversations, the place where people actively working on Drupal or Drupal.org can meet and plan the future of Drupal.

We will also be presenting a brief session on Mobile Design Strategy as part of a series of lightning talks on the DrupalCon exhibit hall Day Stage. While you’re in the exhibit hall, don’t forget to stop by our booth (the easy-to-remember #111) and say hello!

And finally, on Friday, March 23, after all of the regular session programming is complete, a number of us will be leading sprints to help improve various parts of Drupal. Larry Garfield will be leading the Drupal 8 Web Services Initiative sprint, Dave Reid will be leading a sprint on the Media module, documentation, and improvements to Drupal core, and Steve Persch will be leading a sprint to improve collaboration between different Drupal modules for workflow.

If you haven’t registered yet for DrupalCon Denver, don’t delay! Tickets are only $350 until February 21 and only available while supplies last. Get yours today at http://denver2012.drupal.org/

A client that has a lot of physical locations asked me how to improve search engine optimization (SEO) for those locations. They have web pages for each of their locations and were concerned about making sure all those individual location pages are getting ranked well. This doesn't seem to be a very well documented subject, but I found a number of ways to make sure that Google and other search engines know more about the physical locations that are related to a web site.

Google, in particular, has been making locative information more important than ever. If Google has any information about where I am located (and it usually does), it will push results in my location to the top of the search results list for any term I search for. For instance, if I search for 'Coffee' into a normal Google search, I get results like this, even though I didn't add anything about my location in my search terms. This makes it clear that having accurate location information in my web site must be very important.

Background: By default the taxonomy_term view is available to generate views of the terms in given taxonomies. This view may be extended just like any other view to provide a lot more information, however with this customization you may find yourself wanting a different view for different taxonomies.  In our case we have a taxonomy of electronic journals and resources that needs to look vastly different from the historical collections where pictures and such are available.

TVI let's you pick your taxonomy term view from the taxonomy page

 

Our solution: Taxonomy Views Integrator allows you to choose which view to associate with which taxonomy through a very handy and intuitive drop down menu.  Since there are already too many redirects and such on our site in my opinion this is the way to go.  We cloned our default taxonomy term view and added some new filters… voila!  Then just go to /admin/content/taxonomy and in each vocabulary you may choose which view to use… taxonomy and views… integrated.. better than chocolate caramel lobster salad…

For the videophiles here’s your two minute walkthrough…

NB: There are several tools out there to accomplish this task:

Views Term Path Override: overrides the term path – more URL’s getting flung about, however it’s certainly viable

Taxonomy Redirect: Likewise, probably works, but just doesn’t seem quite as elegant or obvious – not certain which of our admins would remember to

probably a few other ways of doing this… thanks to deeporange1 and awebb for this handy mod

Start:  2012-02-18 09:00 - 18:00 Europe/Budapest Sprint Organizers:  Gábor Hojtsy

We are holding a one day sprint for people interested in working on solutions for the Drupal 8 Multilingual Initiative. The physical sprint is in Budapest, on Saturday, Feb 18th from 9am to 6pm local time (CET). Because most of you would not be able to make it in person, we'll also hang out in #drupal-i18n so if you want to join, feel free to do so then and there. Because this is a one day sprint only and people attending the sprint will be mostly new to Drupal 8 development (experienced in Drupal development in general though), we expect to work on lower hanging fruit tasks.

If you show up and want to help with more complex issues, just ask in the #drupal-i18n channel and we'll surely find something good for you!

Drupal 8 Initiatives

Start:  2012-02-15 17:00 - 18:00 UTC Online meeting (eg. IRC meeting) Organizers:  Gábor Hojtsy

It is that time again! We'll review current top priority tasks and discuss new ones to work on. No other specific special topics planned at the moment.

The meeting is in the #drupal-i18n channel on IRC. See http://drupal.org/irc for more information. The time above is marked with UTC - check in your own timezone.

Drupal 8 Initiatives

I am incredibly honored to have been selected to speak at the upcoming DrupalCon Denver on the topic of International NGOs Leveraging Drupal for Social Change. 

As part of the amazing support in the Drupal Community, all presenters have been requested to attend (or watch recordings of) webinars on how to give good presentations, led by Emma Jane Hogbin of Design to Theme.

Below is a summary of the two hour-long videos, which I initially intended as personal notes, but later realized others might find useful as well.

read more

Last year I officially went independent, turning Logrus into a boutique consulting shop specializing in the skills and knowledge I have to offer big players in the Drupal world. So far, things have gone fantastically well and it has allowed me to branch out a little more in the things I do, and has also helped fund several awesome projects that will benefit the community. Notably the Panelizer, Fieldable Panel Panes and ERS modules are completely funded by clients, as well as improvements to Panels such as the pane locking features.

BlogDrupal · DrupalCon

Quite some time ago I wrote a post about how patching makes you feel good in which I talked about the motivations for, and benefits of submitting patches on drupal.org (d.o). I concluded by suggesting that project maintainers should be generous in recognising the efforts of those who submit patches.

Well, now that d.o has its magnificent git infrastructure, project maintainers have even better tools for giving credit to contributors who help fix or improve the code. There is still the well-established convention for commit messages which encourages that "others [who] have contributed to the change you are committing" are credited by name. e.g.

Issue #123456 by dww, Dries: Added project release tracking.

Similar messages are often added to the project's changelog too.

The new tool that perhaps not everyone knows about yet is the ability to assign the authorship of the commit to another user e.g.

git commit --author=[username]@[uid].no-reply.drupal.org

This is appropriate when committing a patch that is entirely somebody else's work. Perhaps some maintainers will be generous and attribute authorship even if they've had to make a few tweaks to the patch, but somebody else did the majority of the work to identify and fix a bug, for example.

When a user is credited as the author in this way, the commit will show up on their drupal.org profile page, which I think many people will feel is a great reward for the time they spent putting a patch together.

There are however some limitations and drawbacks to the system. The committer of the patch is not rewarded by seeing their commit count incremented, which some may find a disincentive for generosity in attributing authorship.

Where the maintainer might split the credit in a commit message for a fix where a user was helpful by giving a detailed bug report in the issue queue, but where they themselves had to actually fix the problem, for example, they're probably justified in leaving themselves as the author of the commit. Of course they can still mention the helpful user in the commit message and changelog.

There will surely also be less monochrome cases where authorship of the code being committed should be split between multiple users. As far as I'm aware, the git infrastructure on d.o doesn't cater for this situation, and messy workarounds such as breaking the commit up to split authorship have been suggested.

There are undoubtedly some limitations, and project maintainers will occasionally find themselves with tricky decisions to make. However, for the reasons I detailed in my patching makes you feel good post, I really encourage maintainers to be generous with the credit when it comes to patches which have been submitted in issue queues, and the option to set an author for a commit in git is a great way of doing so.

idesignwebsitesnet posted a photo:

Project: Forum for the Future
Agency: New Digital Partnership
Role: Designer, IA
Field: Web Design

idesignwebsitesnet posted a photo:

Project: Forum for the Future
Agency: New Digital Partnership
Role: Designer, IA
Field: Web Design

idesignwebsitesnet posted a photo:

Project: Forum for the Future
Agency: New Digital Partnership
Role: Designer, IA
Field: Web Design

idesignwebsitesnet posted a photo:

Project: Forum for the Future
Agency: New Digital Partnership
Role: Designer, IA
Field: Web Design

Drupal is a great platform, but it can’t do everything. As your site grows, you’ll likely encounter use cases that Drupal can’t or shouldn’t do. Some examples include interacting with third-party APIs while preserving good page loads, or performing repeated actions (polling, etc) that result in site updates. Fortunately, separating these kinds of problems from Drupal and moving them to specialized “sub-stacks” within or near your Drupal stack is easy to do.

Enter Node.js. If you’re unfamiliar with it, Node.js is described as follows:

[…] a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

- From nodejs.org

The relevant part of this description that I’ll be focusing on is node’s “event-driven, non-blocking” model.

Third-party API communication

It’s becoming more common to integrate Drupal sites with third-party APIs. API integration is a great way of making your site more powerful without having to build a lot of functionality yourself. The problem is that a lot of third-party APIs are slow. A normal Drupal session runs in a single thread and blocks until all code finishes executing. If you are communicating with a third party during a user session, you can end up degrading user experience through slow page loads, confusing error messages, etc.

Handling this problem with Drupal queues is becoming more popular, and for good reason. Queueing API requests takes the transport out of the user session and shouldn’t affect user experience, but it also means your requests have to tolerate some delay (until the next time the queue is processed). We’re starting to see this more frequently on large Drupal sites and the trade off between user experience and immediate data propagation isn’t always an easy one to balance with clients.

So in this example, Node.js’s “event-driven, non-blocking” model means that you don’t need to wait for the API to respond before you can respond to Drupal. Node.js accomplishes this using callbacks, which if you’ve used jQuery before you should be fairly familiar with. The program will make a call and continue working, and when a response comes back, the callback will be executed. When written correctly, you can achieve nearly parallel execution of tasks — something that’s very difficult, and often impossible, to do in Drupal.

So how about an example of doing this? Consider a case where you want to update a third-party API with user information when the user’s profile is saved. Normally you would wait for the API to respond during the page request, but if you use Node.js as an API relay, the node server will immediately respond that it received the request, allowing the page load to finish quickly. The node server will then relay the request to the API. When a response is received it will call back Drupal with the results. Conceptually, it looks like this:

Moving the API communication out of Drupal allows you to speed up page requests and split off functionality that’s not well suited to a blocking model. There are many places you can typically do this with Drupal, not solely limited to API communication.

Repetitive jobs in Node.js

Another area that’s a good candidate for a Node.js-Drupal marriage is in repetitive jobs that need to be run very frequently. Again, Drupal queues can fulfill some of this need, but if you need to repeat the job very frequently, Drupal-based solutions are not usually ideal due to their high overhead (having to bootstrap Drupal every time you need to repeat the job). It would be better to bootstrap Drupal only when there’s work that actually needs to be done.

An example of this could be polling an external API for data that needs to be added to your site. Thanks to node’s event driven model in relatively few lines of code it can perform this action without generating a lot of overhead on the server while it’s waiting to repeat:

var http = require('http'); var options = { host: 'localhost', path: '/poll' }; var interval = setInterval( function pollSomething() { http.get(options, function onGet(res) { res.on('end', function onEnd() { // Do something! }); }); }, 1000 );

This code will repeat a get request to http://localhost/poll every one second. When the response is complete you can add some logic to determine if Drupal needs to do any work, then make another call to Drupal with the payload from localhost. Any site-specific business logic still remains in Drupal, you’re just offloading the grunt work to an engine that’s more efficient at doing it.

Proof of concept

To see some real-world examples of the two use cases I’ve described here, check out the following code:

• soapq.js: a SOAP API relay
  • https://github.com/elliotttf/soapq.js
  • http://drupal.org/project/soapq
• PubHub: a PubSubHubbub implementation in Node.js
  • https://github.com/elliotttf/PubHub

The key as a developer is to remember that Drupal is great at a lot of things — just not everything. If there’s another tool that’s better suited to the job you’re trying to do, use it! Just because Drupal is usually flexible enough for you to get it to do what you want doesn’t mean that you should bend it that way.

Start:  2012-06-15 (All day) - 2012-06-17 (All day) Europe/Madrid Drupalcamp or Regional Summit Organizers:  pcambra rvilar

You can now register for the European Drupal Developer Days that take place from June 15th to 17th, 2012 at the Citilab training & research center in Barcelona.

At the Drupal Developer Days we are offering sessions, trainings, ad-hoc meetings, code sprints and practical workshops about the latest developments and techniques in the world of Drupal 8.

We are now also accepting session submissions. If you want to present in Barcelona, you should start thinking now about a good subject that will capture the attention of a crowd of mainly programmers.
The conference is targeted at Drupal developers with varying skill sets: from the beginners who just discovered Drupal to the experts that push the Certified to Rock meter into the red. The sessions should focus on technical topics.

Please have a look at the speaker's guidelines that we assembled.

If you have any questions, please use our forum, contact form or ping @drupaldaysbcn on Twitter

Keep a close eye on our website and follow the Drupal Developer Days Barcelona on Twitter @drupaldaysbcn, to stay informed on the latest details.

Drupalcamps Europe [international & english]

In 2011, Acquia hosted my very popular session From PSD to Theme as a webinar. 1800 people registered. Eighteen HUNDRED people. And in one of the best response rates I've ever seen for a free webinar, over nine HUNDRED people signed on and watched the session live. An early draft of the slide deck received over twenty nine THOUSAND views on slideshare. And now? There are FOUR. 1..2..3..4.. seats left in my DrupalCon workshop, From PSD to Drupal Theme: A step-by-step approach to creating your first Drupal theme.

This workshop takes place on March 19 in Denver, Colorado and is part of the pre-con training offered by the Drupal Association at DrupalCon Denver. It will be taught by me (Emma Jane).

I am very excited to be extending this incredibly popular one-hour presentation into a full day workshop. Unlike the one-hour presentation version of this workshop where hundreds of people can attend, seating in this one-day workshop is very limited. You will get individualized support on the day of the class, and an additional 30 days of support after DrupalCon. No more feeling frustrated that your questions weren't answered. Together, we'll work through two PSD to theme conversions. You can even bring one of your own designs to the workshop!

If you can't attend, but really wish you could, check out the themes Vert and Domicile. Attendees will also get a free copy of the step-by-step workbooks and PSD files for the designs (also available here and here). These are the designs we'll be working on during the day. What you'll be missing if you can't attend is the experience of working with me one-on-one to solve your Drupal theming obstacles. In the workshop you'll also get to meet others who've been frustrated by Drupal theming (or maybe have just been too scared to even try). It will be a fun day (promise!) and you'll come away from the workshop ready to take control and make Drupal look as good as your imagination.

Got questions before you register? Get in touch. Remember though: only FOUR seats remain for the workshop on March 19. Register now and I look forward to seeing you in class!

Our new theme has just been released!

This theme was developed with a few goals. Great HTML5 support based on the excellent Boilerplate HMTL5 template, full SASS support, and a base fixed/flexible responsive layout similar to Zen but with built in mobile support, all while keeping the code base small. Like Basic, the stripped down version of Zen, this is designed to run alone, not to run as a master theme with sub themes.

• Read more

Features, taxonomy and other beasts

An extract from the new teaching materials we are preparing for our DrupalCon Denver 2012 pre-conference training, Code-Driven Development: Use Features Effectively.

By now the advantages of a clean Code-Driven Development workflow are clear to the majority of Drupal developers; things like separation between configuration and content, packaging and deployment of new site functionalities or sharing changes in a distributed team don't look that scary anymore.

Still not everything in Drupal can be clearly classified into configuration or content, such as Taxonomy terms. Taxonomy terms are mostly used to categorize our content so, naturally, they are often used in site configuration: a context that reacts to a given taxonomy term is a fairly common scenario. Taxonomy terms can be generated by users (think about free-tagging), which makes them fall into the "Content realm". Drupal, in fact, considers them as such, assigning to each term a unique numeric identifier, and that's the problem.

Each component has its own name

One of the turning points in making configuration exportable in code was the introduction of a unique string identifier for each component: this way it's easy to share configuration and to avoid conflicts. So what happens with taxonomy terms? If they appear in our context conditions then we'd better bundle them together: no matter where we are going to deploy our feature, they will always have to have the same values. That's simply not possible: they have numeric IDs, forget about easy life here.

Various attempts have been made to export numerically identified components, such as UUID Features Integration or the handy Default Content module, but they only solve part of the problem: we want other components to know the unique name of our terms.

Hard and Soft configuration

At Nuvole we adopted the following terminology to classify the two kind of settings that we need to deal with everyday:

• Hard configuration includes the settings under the distribution developer's control (e.g., Views or Contexts); it has a machine name, it is easy to export, it gives no headache. We store it in Features.
• Soft configuration includes the settings that are meant to be overridden by the site administrator (e.g., the default theme, or the initial terms of a vocabulary); it often gets a unique numeric ID from Drupal, it is impossible to export safely, it is painful to handle. We store it in the Installation profile.

This distinction becomes fundamental when the configuration is altered or (if you are dealing with a distribution) when the underlying distribution is upgraded. In the case of Hard configuration, altering it results in an overridden feature, which is upgrade-unsafe. In the case of Soft configuration, altering it does not change the Features state, since the corresponding settings are stored in the Installation profile, and changes are upgrade-safe.

Not only taxonomy terms

The distinction between Hard and Soft configuration goes beyond how to conveniently export taxonomy terms: it is more a design decision, especially important when dealing with distributions. We consider everything that the site builder might be entitled to change as Soft configuration. The place where to usually store Soft configuration is your hook_install(); this guarantees a safe upgrade path to the next version of the distribution. An example could be the default theme: you may ship your distribution with a specific theme but the site owner might want to change it and subsequent updates shouldn't alter it.

Here is how our profile hook_install() might look like in a Drupal 7 distribution:

<?php

/**

* Implements hook_install()
*/
function example_install() {
 
   $terms = array();  
 
   $vocabulary = taxonomy_vocabulary_machine_name_load('category');

 
   $terms[] = 'Solution';
 
   $terms[] = 'Client';
 
   $terms[] = 'Use case';

 
   foreach ($terms as $name) {
     $term = new stdClass();
     $term->vid = $vocabulary->vid;
     $term->name = $name;
     taxonomy_term_save($term);
   }
  
  // Enable custom theme
 
  theme_enable(array('example_theme'));
  variable_set('theme_default', 'example_theme');  
}

?> Reference for site builders

If you are customizing a distribution and you need to override some of its default Hard configuration you might want to have a look at the Features Override module and at these two related articles from Phase2 Technology:

• A new paradigm for overriding Drupal Features
• Features and Overrides - Part Deux