Planet Drupal

The Community Plugin Toolkit has been released for Open Atrium 2.0 providing the documentation needed to start building Plugins. Access to the Open Atrium 2 code base is coming soon!

We often have clients request that people register on the site before they are able to download files. This is often in order to use the files as lead nurturing. Luckily Drupal has all the pieces to make this happen even though they are a bit spread out. This is how we do it.

Modules you will need:
r4032login
luxe (or logintoboggan)
private_files_download_permission... Read more

by Aaron Froehlich

Drupal has emerged in recent years as an extremely flexible and powerful resource for creating web applications. It's done that by creating an infrastructure that simplifies the process of building new functionality and an ecosystem that encourages developers to share this custom functionality. This has been a winning approach because it appeals both to highly-skilled developers who want to contribute to the open source community, as well as relative beginners who want to build rich applications without needing to write or even grasp fundamental programming concepts. The result is an ecosystem that has really thrived, with thousands of modules and a world of possibility.

However, Drupal's strength has also created a number of real problems for developers, particularly related to the long-term maintenance of those sites. The ability to piece modules together has created what some are referring to as the "open buffet syndrome", the alluring tendency for companies to incorporate large numbers of modules to meet the needs of a given project. This approach has a major impact to the total cost of ownership (TCO) of Drupal sites. It not only complicates development tasks like maintenance, updates and upgrades, but it also complicates the administrative interface and site management. Furthermore, the open buffet approach often leads to frustration for developers, who typically prefer writing code to configuring modules, leading to what some refer to as Drupal's Golden Handcuffs. 

We believe that there is a better way to develop for Drupal, which we've been referring to as "Minimalist Drupal Development". We first began thinking about MDD after reading the Treehouse Agency's article about building the energy.gov site without Views, and it just made sense. Our years of Drupal development have proven to us just how essential module selection and implementation is for a project, and how costly poor choices become over time. MDD relies on limiting the use of contributed modules, as well as leveraging Drupal core and its APIs. This creates a more performant system with fewer bugs and fewer patches to maintain, therefore lowering the TCO of your projects. It also requires that you spend more of your time writing code than configuring modules, one of the keys to developing for Drupal and loving it.

When Cornell University's College of Agriculture and Life Sciences (CALS) came to us last year, we saw an opportunity to fully embrace MDD. CALS needed a Drupal install profile that they could use to launch up to a hundred different sites, which prioritized a simplified user interface, a robust permissions and workflow system, and a range of reusable content blocks that integrate into their page workflow. So, how did we do it?

To start with, like energy.gov, the CALS platform is built without the Views module. To achieve the client's goals, we made extensive use of the Bean module, and combined that with the Block reference module. Each page on the site includes three block reference fields that allow our custom beans to appear in the first or second sidebar, as well as in the main content area. To get them there, we simply leverage hook_page_alter() to pluck them from the render array and add them to the appropriate region on the page. This has the added (and in this case, required) benefit that all of the relevant content on the page, including the blocks placed in the sidebars, gets added to the revisioning workflow and can be reverted.

There are additional advantages to using Bean that reduce the overhead on the site. For example, CALS events are managed through a 3rd party API. The traditional approach would likely include using the Feeds module to import the data into an event content type. However, that approach introduces all the associated complexities of managing duplicated data, such as how to handle edited data in one of the systems, setting up cron to keep data current, etc. Using our minimalist approach, Bean made it trivial to grab the json feed of events, cache the results, and display the block (bean) of json nodes to the user without even needing an event content type. There's no duplicate data to unify, and it takes all of 30 seconds to provide the necessary keyword(s) to include in a new block of events and get them onto a page.

Bean is just one key strategy we employed in the service of our MDD philosophy on CALS. In the future, we look forward to blogging about other strategies, including the types of choices that allow you to leverage Drupal core, and how to judiciously choose and even borrow from modules without going for a new plate at the buffet. Stay tuned as well for more about the automated test suite we wrote using Behat and Mink, which provides a full-coverage test suite for all the key functionality of the platform and provides an insurance policy that will allow them to run security and module updates with confidence. And perhaps the most important argument for MDD, from one code loving developer to another, is that we were able to build the site while spending 95%+ of our time in a text editor rather than a browser. 

So what strategies are you using to support Minimalist Drupal Development? 

Are you a Drupal developer interested in MDD? Singlebrook is hiring!

Following from last week, this article is intended to be a resource for web developers to get curre

Neverland can't be far away when you hear things like "One click install" and "Zero touch deployment". Doesn't it? The real world is tougher. Many webdevelopers spend much more time to deploy their websites. "Should I care? I have bigger problems!" Well, it depends. Perhaps it takes only two minutes to setup your server for a new Drupal-install, only half an hour to deploy a new site. But what about two hours downtime to revert a site it because it failed to deploy?

I recently investigated two popular tools which can be used for Drupal deployment: Maven and Phing.

My journey started a few month ago when I got introduced to Jenkins. Jenkins is a widely used package for continuous integration. Deployment is a part of this, but it can also be used for automatic tests, making backups, etc. It is triggered either manually, by cron or upon commit into a version control system. To me Jenkins is, beyond doubt, very suitable for Drupal deployment.

Tags:  deployment jenkins phing maven

Google (or Bing if you prefer) the phrase the "Drupal Way".

When the Drupal Gardens project first switched from Subversion to Git, we adopted the popular git-flow branching model. While this model clearly works for a great many projects, it does not suit every workflow, and not long after we adopted it we decided it didn't suit ours. The branching strategy we ended up switching to is the Branch Per Feature (BPF) model described in this post by its originator, Adam Dymitruk.

In my role as development team leader, I am responsible for the application architecture that allows other team members to focus on building functionality with minimum friction and rework. As such, one of my biggest tasks is to ensure that new features and configurations can be reliably deployed to the various stages: development, testing and production.

My current project is an Arabic/English application built on Drupal 7, that is deployed in multisite fashion to several partners.

read more

The Static 404 module is a very basic module. It allows you to generate and store a static version of a 404 page by clicking on the "Generate static 404 page" button in the "Site information" page or via a Drush command. For this module to work you need to define a node as your 404 page.

In this tutorial, I'll show you how to setup the Static 404 module.

We are passionate about code quality. We want to make sure our code is well tested and confirms to standards at all times. If there is a bug, we want to know as soon as possible, so we can fix it and keep our code stable, well tested and bug free, even in early development versions.

Typical workflows use a git topic branch for development of each feature, and require code to be merged into a development branch before automated tests are run. The problem with this approach is it tests code after it has been reviewed and merged.

Using Jenkins for automated testing of Github pull requests, we can get one step closer to code quality nirvana.

The Departure

A small portion of my world was shaken by The Drupal Association's announcement about Neil and Marta today. Neil had some rocky times with the community, but Drupalcon Denver really changed all of that. As he came to understand the community and how passionate we all are about what we do and how tight a community we all are he became one of us. I would hazard to say there are a significant number of us that don't just think of him as the con's organizer but also a close friend. I got to know Neil well during Drupalcon Denver and can honestly say that his grounded down-to-earth nature, his skills as an organizer, and his willingness to listen and adapt to how we do things was a real boon to the community. You will be missed.

I don't know Marta as well as Neil, but I've very much enjoyed my visits with her.

drupaldrupalcondrupal associationStaff Changes

Growing Drupal around the world was the big theme of the Drupal Board of Directors Retreat in Boston on Thursday February 28 and Friday March 1.

Start:  2013-03-06 (All day) America/New_York Sprint Organizers:  David_Rothstein

The monthly Drupal core bug fix release window is scheduled for this Wednesday. However, there will be not be a standard bug fix release of Drupal 7 on that date. Instead, there might be a limited release focusing only on fixing problems introduced in Drupal 7.20. Stay tuned for more details on that.

For those who haven't been following, Drupal 7.20 (the most recent security release from two weeks ago) fixed a security issue that was related to fundamental functionality in the Drupal core Image module. It therefore necessitated significant changes to Drupal's handling of image styles (a.k.a. image derivatives), and as a result several contributed modules are still catching up to the changes in order to work correctly with Drupal 7.20. For this reason, a number of Drupal sites have not been able to upgrade yet.

Rather than releasing a whole bunch of new changes in Drupal 7.21 while that is still going on, I think it would be preferable to focus on making sure Drupal core does everything possible to get the image style situation sorted out (and to allow all sites to upgrade to a secure version of Drupal as quickly as possible). Also, I have been focusing my own time on that issue, time which I would otherwise have spent committing patches before the release. Therefore, if we are able to get together a release of Drupal 7.21 this week, it will only contain small changes (related to image styles) on top of Drupal 7.20, rather than the full set of changes in the 7.x-dev development version.

Upcoming release windows after this week include:

• Wednesday, March 20 (security release window)
• Wednesday, April 3 (bug fix release window)

However, since the last bug fix release was a while ago (Drupal 7.17, released in November), we might not wait all the way until April 3 for the next one. If the image style issues can be sorted out soon, then it's possible a new bug fix release could come out after that, but before April 3 (and therefore outside the normal release window). I will play it by ear depending on how things go over the next couple of weeks.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

The only thing that stays the same is that nothing stays the same. That's definitely true for the Drupal Association, and today we had to do a hard thing and say goodbye to two team members, Neil Kent and Marta Betts.

DrupalCon Portland is moving right along and getting ready for the 5-day extravaganza taking over Portland May 20-24, 2013 and today's announcement is no exception; we've got the official sessions listing ready to go!

Omega theme has some cool features that have rightly been given a lot of attention, but one companion module that doesn't get discussed as much is Omega Tools. It's a very useful module and one of its features is the ability to export theme settings, something that may come in handy on your next project.

So a little background on how Omega theme is set up before we do the walkthrough. The default theme settings for Omega are stored in the theme .INFO file. One of the really cool things about Omega is the ability to change these settings in the browser. When we make changes, Omega stores them in the database, overriding what is in the .INFO file.

But what if you wanted to port your theme settings to a new project? You could hack away at the .INFO file in a text editor trying to replicate what you've done - a mind numbing experience for sure. But that won't be necessary because exporting these settings is one of the main functions of Omega Tools.

Let's see how it works. What we're starting with in the example below is the Friendly Machine installation profile for Omega. This is what you have right after installation:

You'll notice that we have the default three column layout with each sidebar spanning three columns, something easily seen in this image with the column overlay enabled. This default configuration was set in the theme's .INFO file and right now we don't have any changes to these settings being stored in the database.

He's a look at the section of the .INFO file that we're going to be working with in this example. You can see that manually editing this file (which is quite long) could be a bit of a pain and somewhat error prone.

If the above image looks like gobbledygook to you, don't worry. The thing to take note of is the weight of the various regions which have been highlighted with the red arrows. Sidebar First has a weight of "1" which places it to the left, the main content area has a weight of "2" and Sidebar Second is set to "3". We're going to change this up so that both sidebars are on the right on the main content region.

We'll just switch the weights of the Sidebar First and Content regions in the browser. You can do this at Appearance > Settings and then look under the "Zone and region configuration" tab.

 

What we'll have after saving our changes is both sidebars to the right of the main content like so:

Now we want to export these changes so we can use them in future projects without having to  manually make this change every time. All we have to do is head back to Appearance > Settings and if you have Omega Tools installed, simply click the "Export theme settings" button at the bottom of the page.

On the next screen you'll see the output of the generated .INFO file so that you can make any manual adjustments you might want. There is also a "Revert theme settings" checkbox that will clear the changes from the database. If that's not what you're going for, uncheck the box and you'll keep the settings stored in the database, but the current .INFO file will still be updated with your changes.

 

Now all you have to do to grab a copy of the updated theme for a new project is click the "Download this theme" button at the bottom of the theme settings page. This is a pretty nice time saver and yet another reason why I love working with Omega theme. 

If you're interested in learning more about Omega, I've written a number of other posts you might find useful. I also encourage you to try our installation profile. It might save you some time getting started with the mighty Omega theme.

Our use case seemed pretty straightforward.  When users register on the site they select terms from a taxonomy list based on a field in their profile2 profile.  As content is added to the site the same taxonomy is used to categorize content.  We wanted a view that would let users see any content that matched any of their taxonomy term selections.

I’m on the drupal4lib mailing list and want to thank all those who responded, specifically Kelly Lucas aka krlucas who is quoted below

Start with a base View that shows Users (not Content).
1) Set a Contextual Filter for User ID, provide a default value and set it the
logged-in User’s ID
2) Create a relationship from the user to the user’s profile
3) Create a relationship from the field containing the select terms on the
user/user profile to the taxonomy terms
4) Create a relationship from the taxonomy terms to the nodes that have that
taxonomy term.

You should now be able to add the relevant node fields to the View.

walkthrough of a view

using the query settings "distinct" to limit the values instead of one per term

whatcha get from all these relationships

What didn’t work: So while this seemed incredibly straightforward getting this many-to-many relationship to work caused me endless grief.  I tried views global filter thinking that might be a good solution – according to their documentation any fields pulled from the profile are used to override the values.  Using the multiselect widget this simply failed all over the place – values didn’t save at all, weirdness reigned, and general misery ensued.

Also in the “fail” category – making a view based on the content table and the taxonomy table.  Either of these might have worked with a few more relationships, however at this point I think we’re stocked up.

Thanks to all involved who helped on this – Cary Gordon, Brazos*, and of course Kelly Lucas

*Brazos added another interesting option of using page manager to override the user page and pass variables along that way – I’m not experienced in this line of development to implement, but it seems interesting.

 

Content strategy is on enough lips nowadays that most people can call out ideas to sketch out the general borders of this area of discipline. User focus! Clarity! Reusability! Curated content! But where exactly is the heart of content strategy?

The Heart of Content Strategy

Content strategy's ultimately about aligning your organization's content (whether print or digital, written or shot) with its overarching business goals and objectives. Successful content strategies manifest themselves in several key ways: you see

clear communication that makes your customers' lives (and your lives) easier

a compelling and relevant body of content that helps customers learn and do what they want

repeatable cycles for evaluating, creating and maintaining your content and keeping it directed toward your goals

It's a discipline that doesn't just add to but amplifies the value of all your organization's efforts.

The Practice of Content Strategy

Think about the three outgrowths of a successful content strategy and the questions you'd need to answer to achieve this for your organization. What are your organization's ultimate business goals? Who are your customers; what defines them; what are their goals? Are you helping your customers do what they want? What content and processes do you have in place now, and how well is it working for you? How do you ensure your evolving organization keeps pulling toward its shared but also evolving set of goals?

The tactical practices of content strategy answer these questions with tools and exercises such as

brand personas

taxonomy frameworks

page tables

search strategy

content inventory and audits

user interaction and user experience analyses

content creation style guides

content governance plans and editorial calendars
Why Is Content Strategy Important?

If those practices above sound familiar, it's because they're often in the toolkits of neighboring disciplines. Marketers do user research and craft brand identities. An SEO specialist might have a detailed inventory of your website. Content marketers use editorial calendars to unleash tons of content into the social media universe every day.

So why is content strategy so important?

First, its goals are different, even if some of its practices overlap. Good content strategy brings your company's service-centered identity beyond a round-the-clock customer service hotline, even getting customers what they want from other retailers if you're out of stock. It goes beyond your website blog and carousel slides, anticipating what might break and how to respond to your particular audience.

Blizzard's 404 Error page uses the written and visual language of its target demographic, and points users back on track with an irreverently "broken" reproduction of its site menu.

Second, it's holistic, a comprehensive, integrated plan for all these disparate efforts. Where does your organization have product information? Brochures? Excel sheets? Website? Facebook Page? Ads? Emails? A deliberate, unified strategy prevents scattershot investment of resources and content silos.

Third, it evaluates and accommodates the ways your audience seeks and consumes content. It goes beyond the purchase of a snappy billboard ad for a New Gizmo — even one reused on the company website, blog or Twitter feed to "go digital". A content strategist evaluates the nuances of the different channels and plans for appropriate content: on Twitter, this might mean animated GIFs of people using New Gizmos in unconventional ways.

Who Cares About Content Strategy?

Your customers, your content creators, your project managers and more. Stay tuned for part two of this two-part effort to bring content strategy beyond the buzzword.

A week ago I've announced a project which I created in order to fullfill my own need of storing Drupal snippets - Dropbucket.org. I've announced this project here on my blog and it turned out to be a huge success attracting lots of eyes, positive responses, thanks, clicks, tweets and registrations. I'm really amazed by reactions I received and today I decided to sum up the first week of life of the Dropbucket.org.

Read on about Dropbucket.org - The First Week Of Life

Hosting the Content Strategy Conversation in a Brand New Breakout Room

Content matters! Bold, boisterous content matters; shy bits of micro-content matter; even the nuances of your error messages deserve careful attention! Lullabot’s Insert Content Here podcast is all about content, and every episode features a new conversation with content strategy experts from a variety of industries and disciplines. On June 3-5, Lullabot will also be sponsoring the third annual Confab, a fabulous conference that's dedicated to content strategy! Every year in friendly Minneapolis, Minnesota, Confab brings together a host of experts to discuss the big issues and tiny details of content strategy.

Why Attend Confab?