Drupal News

Syndicate content
Drupal related news with the junky stuff filtered out
Updated: 6 hours 20 min ago

Palantir: Explaining Panels: Why I use Panels

January 29, 2015 - 1:00pm

In my last blog post I explained what the Panels Suite is and does. I explained how Panels itself is a User Interface on top of hook_theme() and theme(). That technical explanation of Panels underlines what I think is its main conceptual virtue:

Panels encourages a mental model of pulling data into a specific design component

At Palantir we're working with Design Components that are created in static prototypes. Design Components are the reusable pieces of front-end code that compose a design system. Design Components should not know about Drupal's internal implementation details. We're not alone in this thinking. (Inside the Drupal community, and outside of it).

The task of "theming a node" is now "print this node so that it renders as this design component." Unfortunately Drupal core does not have <code>hook_design_component()</code>. It has <code>hook_theme()</code>. Some of the entries in <code>hook_theme()</code> from core are essentially design components.

Entries like <code>‘item_list'</code> and <code>'table'</code> are design components. They are conceptually based around their HTML rendering. They make sense independent of Drupal. To use them as a Drupal Developer you need to get your data organized before you call <code>theme()</code> (directly or otherwise).

On the other hand, much of the Drupal core usage of <code>hook_theme()</code> is not at all design component minded. <code>'node'</code>, <code>'user'</code>, <code>'comment'</code> all have entries in <code>hook_theme()<code>. In these elements you don't have to organize your data before calling <code>theme()</code>. You can give <code>theme()</code> a node object and after that <code>template_preprocesss_node()</code> has to do a ton of work before hitting the template.

It's no coincidence that the design component-ish <code>hook_theme()</code> entries have minimal preprocessing or no preprocessing whatsoever. The design component-ish entries like </code>‘item_list'<code> know what the HTML will look like but have no idea what your data is other than you were able to get it into a list. The non-design component entries like node know exactly what the Drupal-meaning of the data is but know very little about the markup they will produce on most production sites.

Panels unites the two mindsets. It knows what the incoming data is (A node context, a user context, etc) and it knows what design component it will print as (the layout plugins.) If you put a debug statement inside of </code>panels_theme()</code> you will see the names of layouts and style plugins. These </code>hook_theme()</code> entries are more of the design components-ish <code>hook_theme()</code> entries. They know what their markup will be. And the part of Panels most people pay attention to, the drag-and-drop interface, is where you control how the data of a node is going to prepare itself for the design component.

And here is where the admin UI of Panels might set up a confusing mental model.

How it looks in the Panels admin UI

But at execution time it is

Or the way I think of it

Drupal Data → transforming Drupal data into printable variables → design components for those variables to print in

The next time I get into a discussion about Panels at a meetup, DrupalCamp, or DrupalCon, think I'll first ask, "Does Panels let you think about building websites the way you want to think about building websites?" I like to think about passing variables into encapsulated configuration associated with a specific design component. I prefer that mental model to the "show and hide based on globals" mental model of Core's Blocks or the "just call theme() on a node and figure out the overrides later" mental model encouraged by node--[content-type].tpl.php. As the Drupal community asks itself again how it wants to do rendering, let's also ask "how do we want to think about rendering?"

The rise of design component thinking in the wider Wweb development world is not turning back. Web Components and modern front end MVC frameworks encapsulate design components. They do not care about every single implementation detail and layer of a node object. They care about getting variables ready for printing and updating. Panels module may fall out of the picture once Web Components fully mature. Until then, Panels allows for us to think in ways we will need to think for Web Components to work with Drupal.

Drupal Watchdog: Touring Drupal

January 29, 2015 - 9:51am
Article

Drupal 8 has been all about pushing the boundaries, so why should help content be any different?

With the release of Drupal 8, we will also ship with tools to complement hook_help() entries: if you, the developer, are providing a documentation page for your module, why not also provide an interactive step by step guide on how your module works as well?

The idea of Tour isn’t a new one; it has been maturing over the past two years. It all began after the release of Drupal 7 when we decided to move the help passage from the front page to the help page. This meant that users new to Drupal would not see this text, and would have to struggle through with no guidance.

In light of that issue, the below was suggested;

How about creating a “Welcome” message that pops up in an overlay with that same information that continues to appear until either the user checks a box on the overlay saying to dismiss it or the user creates a piece of content on the site?
- Vegantriathlete, August 10, 2011

With tour.module committed to Drupal 8 core, we now have context-sensitive guided tours for Drupal’s complex interfaces, and developers have a new way to communicate with the user. It doesn’t stop at core either: contrib modules can ship with tours to describe how users can take full advantage of their modules. Distributions can also ship with tours on how to get started. Imagine a tour in the Commerce distribution that took the user through setting up products: That would be amazing! It would enable users to discover the pages they are looking for and take the guesswork out of finding pages.

OpenLucius: Why the Bootstrap HTML framework in Drupal & OpenLucius

January 29, 2015 - 8:58am

The Bootstrap HTML framework in Drupal, we love it. That's why we build the front-end of Drupal distribution OpenLucius with it. So we love it, but why is that?

There are alternatives to integrate in Drupal websites. Below we will give you a few reasons why we currently prefer the Bootstrap framework.

Why a HTML framework

First of all, why should you use a HTML framework? These possibilities also exist:

InternetDevels: Drupal tourists in Ternopil

January 29, 2015 - 2:31am

Nothing keeps Drupal tourists from spreading the word! We are passionate for Drupal and IT, so enjoy meeting like-minded people very much! Despite the cold winter weather, Ternopil welcomed us with warmth and friendliness. How was it? Our blog post will tell.

We were getting ourselves ready for the ride for almost a month. Our brandy Drupal van wanted to make nice impression too, that’s why the journey hit off from the car wash :)

Read more

Mediacurrent: SprintWeekend2015: A review of Mediacurrent&#039;s participation

January 28, 2015 - 3:24pm

While we at Mediacurrent have been trying to bring internal focus and organization to our contributions, the rest of the Drupal community was planning a “Sprint Weekend” for January 17th and 18th.

Web Wash: How to Use Display Suite Field Templates in Drupal 7

January 28, 2015 - 1:36pm

Display Suite is one of the essential modules which I use on every project. It allows you to change the look and feel of entity bundles, i.e., content types, vocabularies, users and much more. Building custom layouts and adding fields is a breeze, but there's another feature you may not be aware of and that's custom field templates. Display Suite allows you to change the markup which is used to render individual fields.

The functionality to change field templates is off by default. To turn it on, you'll need to enable the "Display Suite Extras" sub-module and check the "Field Templates" on the Extras page.

In this tutorial, you'll learn how to enable "Field Templates" and how to use them.

Phase2: Finding (and Retaining) the Best of the Best

January 28, 2015 - 1:13pm

Yesterday, Phase2’s own Chris Bloom was featured on the Drupal Association’s podcast on how to hire great Drupal talent. It’s a pertinent conversation to have at the moment, when 92% of hiring managers surveyed by the Drupal Association reported that there is insufficient Drupal talent in the market to meet their needs.

Over the course of an hour, Chris, Randi King, and Mike Lamb shared many insights on not only attracting talent, but keeping it around. I highly recommend giving the podcast a listen once the recording is available on the Association’s website. In the meantime, as Phase2’s Talent Manager, I wanted to elaborate on some of our company’s methods for finding, hiring, and retaining the best of the best in Drupal and beyond.

Finding Talent: Emphasizing Relationships

Because we operate in an industry of web professionals, it may be a little surprising that the majority of Phase2’s recruiting happens organically, not digitally. True, online advertising plays a role, and we share open positions on our website, LinkedIn page, and Twitter. However, many of our new hires are discovered by employee referrals and face-to-face introductions at community events and job fairs. This is no coincidence: we respect our team members’ judgements and encourage them to bring new people into the fold – and we really like talking to new people!

The emphasis is really on building relationships, as opposed to checking off a list of desired skills. Organic connection is, therefore, an enormous help in determining whether a candidate will be a good fit at Phase2, whether the connection derives from an awesome conversation, internal introduction, or past collaboration with contractors. We initially look to have an open dialogue in order to gage attitude, passion, and motivations – it is these intangibles that really get us interested in a candidate. A recommendation from one of our employees speaks volumes in this respect.

The Interview Process: exploring skill & creativity

An interview is obviously an evaluation of a candidate, but it should be less a trial than an open discussion. As I mentioned earlier, it’s important to pay attention to the undefinable character traits that will help the candidate succeed at your company. At Phase2, this means being aligned with our six values: dedicated, collaborative, smart, adaptive, authentic, and fun. Even the best developer in the country might not be the right choice if he or she is not a cultural match.

To judge technical abilities, we take code contributions and technology tests into consideration, but another big portion is evaluating thought process and decision-making skills. We ask candidates to talk us through how they would go about tackling certain challenges, getting to the heart of their understanding of the technology and proper processes. This method also offers the advantage of revealing people’s true creativity. Most technologists have an inner flair for creating, and it is always exciting to figure out where their passion comes from, and the unique ways it plays out when solving technical problems.

offering flexibility

According to a Drupal Association survey, 44% of job seekers emphasize location as an important factor in accepting a new job, specifically not having to relocate. Accommodating these candidates means walking the fine line between attracting top talent and maintaining a healthy, engaged team. Requiring all employees to work from a physical office encourages bonding but may scare off truly talented people that consider working from home to be a deal-breaker. At the same time, managing a remote team presents a myriad of logistical challenges in day-to-day communications, in addition to the difficulties of fostering a close-knit team.

At Phase2, our strategy is to offer ultimate flexibility for our employees. Our four offices in DC, New York City, San Francisco, and Portland give our social butterflies the chance to bask in our rich office culture. At the same time, about 30% of our team work remotely across the country. Day-to-day collaboration is achieved through diligent digital communication, video meetings on Google Hangout, and a water-cooler-like chat system which allows us all to bond at a distance. Maintaining an inclusive organization requires a concerted effort (such as our annual all-company gathering at headquarters) but it is well worth it to offer our employees the flexibility to live and work where they prefer to.

Retaining Talent: Letting your People Blossom

Phase2 has been very successful in retaining talent, and a large part of that is offering employees the chance to work on interesting and important projects. In a poll conducted with the podcast’s attendees, 70% believed that the most important factor in keeping staff happy and engaged was interesting work – much higher than compensation (10%), or even culture (20%).

Beyond interesting work, we at Phase2 believe career development is crucial to letting our people blossom. Encouraging long-term growth is key to ensuring your team feels appreciated and valued – it is basically an indication that your company is invested in their future. We manage this by instituting weekly check-ins with managers to discuss progress and goals. In addition, we’ve established well-mapped career trajectories. We feel that it is important to provide concrete steps for individuals to move forward in their own careers, pursuing specialties they themselves have shown an interest in.

How does your team find, hire, and retain top talent? We’d love to hear your thoughts in the comments!

Drupal Easy: DrupalEasy Podcast 143: Scheming (Schema.org integration in D8 - Stéphane Corlosquet)

January 28, 2015 - 12:16pm
Download Podcast 143

Stéphane Corlosquet, Sachni Herath, Kevin Oleary, and Kay VanValkenberg join Mike, Ted, and Ryan for a look into Drupal 8's impressive integration with Schema.org. The RDF UI module is really the star of the show, it promises to provide a super-easy way to create a content type based on an existing schema. We also talk about Dries' 2014 Drupal retrospective, Twig syntax vs. tokens, and Mike's bad internet connection causes hijinx. Picks of the week include a font for demos, a lightweight alternative to a popular Drupal module, and Views changes in D8.

read more

Drupal Association News: Drupal Association Board Meeting: 21 January 2015

January 28, 2015 - 12:02pm

In the first board meeting of 2015, we hit the pause button and looked back on 2014. With all the numbers in and so many projects completed, we wanted to evaluate our success (and our misses) with the board and with you. We feel really good about what we accomplished with the rest of the community. To me, it's doubly impressive because the Association spent so much of last year growing like crazy. We started the year with just about 13 staff and ended the year with 27. We're still small, but doubling your staff is never an easy endeavor. So to go through that kind of change, and to also get some much other good stuff done seems pretty remarkable to me. As always, you can check out the notes, the materials, and the recording, or peruse my summary of the meeting here.


Operational update


I think I can safely say that the theme of 2014 was “Let’s see what we learn from this!” We started the year with a Leadership Plan that outlined some important goals and strategies. We also defined key metrics we would track to help us understand if we were making progress on those goals. This was the first time the organization had this kind of framework to not only get a lot of stuff done, but to understand if that stuff was fulfilling its purpose.

The plan helped us identify lots of things to experiment with, and throughout the year we learned a lot about our plan itself. Metrics didn’t always point to the outcomes we thought they did. Some goals that we set were impossible to meet because of outside influences. But having the plan - that was important. It forced us to think about our work before, during, and after every project. So where did all our experiments take us? A lot of places. Here is a short, incomplete, and grossly over-simplified list of what we accomplished in 2014:

  • We set the proper frame. We developed a vision statement, revamped the mission statement, and created a values statement for the Association.
  • We rebranded, developing new logos for the Association and our programs that reflect our maturity as an organization.
  • We diversified our revenue, by a lot. Introducing new programs and services we were able to make a dent in the ration of Con related revenue to non-Con revenue. This is important for the financial health of the Association, but also because if Cons are our primary source of revenue, we can’t innovate and evolve them with as much courage for fear of undermining our total revenue.
  • Speaking of DrupalCons, we held two really big ones. Lots of things went right - they are well run, with great speakers and great community. We also collected a lot of data about the Cons and identified lots of places to work on for 2015 and beyond. (We promise we heard you about the food in Amsterdam!)
  • The marketing team is creating lots of technical marketing and other branded content that is starting to get great traction in the field. Resources like “Managing Media in Drupal” allow us to showcase the best that Drupal has to offer, regardless of version.
  • The launch of Drupal Jobs was a big milestone for us. We had not launched a product before, and were thrilled to get something out there that the community has repeatedly asked for. It’s still new, and we’re still learning, but we are overall very excited about the steady growth that we have seen.
  • Testbots is an area I have heard about on a weekly basis since I started at the Association. In 2014 we were able to forge a great partnership with the testbed volunteers. The Association is now managing the ongoing operation of the existing testbed infrastructure while the volunteers get to work on the next generation. We’ve seen massive improvements in performance as a result - wait times have dropped from almost 120 minutes to about 20 minutes on average. During the recent Global Sprint Weekend, we went from our usual 4 AWS instances to 20!
  • Drupal.org profiles have also seen a tremendous change in 2014. Again, thanks to the work of some amazing volunteers, we were able to introduce small targeted changes frequently, beginning with profile pictures. The work is not done and there are more changes to come, but profiles are becoming better and better online resumes and community connectors for the community.
  • We managed to be our projected deficit spend for the year. This sets us up well for 2015

I would like to point out that I am extremely proud of the Association staff who endured a lot of growing pains while churning out really good, quality work. In addition to being awesome at what they do, they are hilarious and smart. I owe the a huge debt of gratitude. HOWEVER, all of the bullet points above represent a significant contribution from the volunteers in the community as well. We don’t do our work alone, and we are so grateful to the hundreds of you who have prototyped, tested, coded, documented, trained, mentored, and made puns. Your leadership in the community is noticed and appreciated. Our greatest hope is that we are making your Drupal life a little better.

Marketing Team 2015 Update

The marketing team built a very solid base in 2014 and is prepared to declare 2015 the year of content. Here are a few key initiatives that you can expect this year:

  • More branded content, better presentation. We’re going to turn Drupal.org into the best site out there to discover all you can do with Drupal. We’re currently developing a content strategy that will help us discover all the great content that already exists, but gets lost in the one million+ nodes on the site. Then we can combine that with the great technical content we are also crafting to create more resource centers covering everything from media to search in Drupal.
  • A Drupal.org blog. We are in the middle of a content strategy process led by staff with the Content Working Group and Forum One Communications. It’s clear that we need a better channel to expose the folks who want Drupal news, but who aren’t ready to drink from the firehose that is Drupal Planet. The blog will allow us to reach those folks, and we hope we can use it to highlight the best writing about Drupal that is already being produced.
  • Drupal newsletter. In 2008, we stopped sending a regular Drupal newsletter to the tens of thousands of subscribers on Drupal.org. We’re bringing that back in 2015, with a model similar to that of the blog - the best community content. This newsletter will differ from the Association newsletter in that all the content will be focused on Drupal itself.
  • A challenge will be localization - translating content for our global audience. With the release of Drupal 8 nearing, and its emphasis on localization, we want to meet this need. We’ll be working on strategies to make translation happen on key content.

Of course, there is more to the update than this summary, so I encourage you to check out the presentation.

And then we ran out of time

We were also scheduled to vote on a slate of candidates for the newly formed Licensing Working Group. Unfortunately, we ran out of time. The Executive Committee of the board will be discussing next week to see if we can vote electronically on this topic.

Thanks for a great 2014. Here’s to an even better 2015

Again, thank you for the support, the work, the encouragement, the ideas, and even the complaints. All of it makes us better as an organization, and we hope that when we’re better, Drupal is better. 


 

Flickr Photo: DianaConnolly101

Drupal Association News: Drupal Association Board Meeting: 21 January 2015

January 28, 2015 - 12:02pm

In the first board meeting of 2015, we hit the pause button and looked back on 2014. With all the numbers in and so many projects completed, we wanted to evaluate our success (and our misses) with the board and with you. We feel really good about what we accomplished with the rest of the community. To me, it's doubly impressive because the Association spent so much of last year growing like crazy. We started the year with just about 13 staff and ended the year with 27. We're still small, but doubling your staff is never an easy endeavor. So to go through that kind of change, and to also get some much other good stuff done seems pretty remarkable to me. As always, you can check out the notes, the materials, and the recording, or peruse my summary of the meeting here.


Operational update


I think I can safely say that the theme of 2014 was “Let’s see what we learn from this!” We started the year with a Leadership Plan that outlined some important goals and strategies. We also defined key metrics we would track to help us understand if we were making progress on those goals. This was the first time the organization had this kind of framework to not only get a lot of stuff done, but to understand if that stuff was fulfilling its purpose.

The plan helped us identify lots of things to experiment with, and throughout the year we learned a lot about our plan itself. Metrics didn’t always point to the outcomes we thought they did. Some goals that we set were impossible to meet because of outside influences. But having the plan - that was important. It forced us to think about our work before, during, and after every project. So where did all our experiments take us? A lot of places. Here is a short, incomplete, and grossly over-simplified list of what we accomplished in 2014:

  • We set the proper frame. We developed a vision statement, revamped the mission statement, and created a values statement for the Association.
  • We rebranded, developing new logos for the Association and our programs that reflect our maturity as an organization.
  • We diversified our revenue, by a lot. Introducing new programs and services we were able to make a dent in the ration of Con related revenue to non-Con revenue. This is important for the financial health of the Association, but also because if Cons are our primary source of revenue, we can’t innovate and evolve them with as much courage for fear of undermining our total revenue.
  • Speaking of DrupalCons, we held two really big ones. Lots of things went right - they are well run, with great speakers and great community. We also collected a lot of data about the Cons and identified lots of places to work on for 2015 and beyond. (We promise we heard you about the food in Amsterdam!)
  • The marketing team is creating lots of technical marketing and other branded content that is starting to get great traction in the field. Resources like “Managing Media in Drupal” allow us to showcase the best that Drupal has to offer, regardless of version.
  • The launch of Drupal Jobs was a big milestone for us. We had not launched a product before, and were thrilled to get something out there that the community has repeatedly asked for. It’s still new, and we’re still learning, but we are overall very excited about the steady growth that we have seen.
  • Testbots is an area I have heard about on a weekly basis since I started at the Association. In 2014 we were able to forge a great partnership with the testbed volunteers. The Association is now managing the ongoing operation of the existing testbed infrastructure while the volunteers get to work on the next generation. We’ve seen massive improvements in performance as a result - wait times have dropped from almost 120 minutes to about 20 minutes on average. During the recent Global Sprint Weekend, we went from our usual 4 AWS instances to 20!
  • Drupal.org profiles have also seen a tremendous change in 2014. Again, thanks to the work of some amazing volunteers, we were able to introduce small targeted changes frequently, beginning with profile pictures. The work is not done and there are more changes to come, but profiles are becoming better and better online resumes and community connectors for the community.
  • We managed to be our projected deficit spend for the year. This sets us up well for 2015

I would like to point out that I am extremely proud of the Association staff who endured a lot of growing pains while churning out really good, quality work. In addition to being awesome at what they do, they are hilarious and smart. I owe the a huge debt of gratitude. HOWEVER, all of the bullet points above represent a significant contribution from the volunteers in the community as well. We don’t do our work alone, and we are so grateful to the hundreds of you who have prototyped, tested, coded, documented, trained, mentored, and made puns. Your leadership in the community is noticed and appreciated. Our greatest hope is that we are making your Drupal life a little better.

Marketing Team 2015 Update

The marketing team built a very solid base in 2014 and is prepared to declare 2015 the year of content. Here are a few key initiatives that you can expect this year:

  • More branded content, better presentation. We’re going to turn Drupal.org into the best site out there to discover all you can do with Drupal. We’re currently developing a content strategy that will help us discover all the great content that already exists, but gets lost in the one million+ nodes on the site. Then we can combine that with the great technical content we are also crafting to create more resource centers covering everything from media to search in Drupal.
  • A Drupal.org blog. We are in the middle of a content strategy process led by staff with the Content Working Group and Forum One Communications. It’s clear that we need a better channel to expose the folks who want Drupal news, but who aren’t ready to drink from the firehose that is Drupal Planet. The blog will allow us to reach those folks, and we hope we can use it to highlight the best writing about Drupal that is already being produced.
  • Drupal newsletter. In 2008, we stopped sending a regular Drupal newsletter to the tens of thousands of subscribers on Drupal.org. We’re bringing that back in 2015, with a model similar to that of the blog - the best community content. This newsletter will differ from the Association newsletter in that all the content will be focused on Drupal itself.
  • A challenge will be localization - translating content for our global audience. With the release of Drupal 8 nearing, and its emphasis on localization, we want to meet this need. We’ll be working on strategies to make translation happen on key content.

Of course, there is more to the update than this summary, so I encourage you to check out the presentation.

And then we ran out of time

We were also scheduled to vote on a slate of candidates for the newly formed Licensing Working Group. Unfortunately, we ran out of time. The Executive Committee of the board will be discussing next week to see if we can vote electronically on this topic.

Thanks for a great 2014. Here’s to an even better 2015

Again, thank you for the support, the work, the encouragement, the ideas, and even the complaints. All of it makes us better as an organization, and we hope that when we’re better, Drupal is better. 


 

Flickr Photo: DianaConnolly101

Shomeya: 7 Things for Troubleshooting Drupal 7 Theming

January 28, 2015 - 11:05am

When I worked in Reality TV Post Production I always had a troubleshooting guide. Most of the time I was working the night shift, and trust me no matter how many times you've done something sometimes your brain just breaks at 2am.

In case you haven't done this before a troubleshooting guide is basically just a list of the steps you take when things break, it helps you avoid that moment of exasperation 3 hours later when you realize how simple the solution really was.

Read more

CivicActions: Dockerizing Drupal for Project Development and Testing

January 28, 2015 - 8:05am

Docker has quickly become the favorite virtualization tool for many people including myself. A few months ago we were discussing various technical goals across our project and things started to come together pointing to a basic docker framework to facilitate our development processes. This basically sums up our wish list:

Our Goals
  • Faster developer sandbox set up to get started on projects sooner.
  • Consistent software stack across developers, testing infrastructure, and production.
  • Ideally, a basic tool set that would work for both our new projects as well as our maintenance sites.
  • Start using the cool new trendy docker.
Container configuration with fig

One challenge is to have portable configuration for the building, starting, and stopping of a project's containers. The fig project provides an elegant solution and the configuration is in YAML files, which we in the Drupal community should be getting used to now with Drupal 8. The fig.yml defines your containers, ports, mount point, and how they link together. Maintaining a fig.yml file in our project repositories allows us to do things like add an Apache Solr container with ease.

I was working on a collection of bash scripts and docker files and a fig.yml for one project and at some point it became stable enough to extract for general use. I brought these files together and made them available on github.

Introducing Bowline

Following the nautical and shipping metaphor, I chose the name bowline because it's a simple and basic knot with multiple uses. The idea is that Bowline ties it all together. Plus it reminds me of my sailing days when I could tie a bowline in less than 3 seconds, which is slightly faster than it takes to start the docker containers.

Code and instructions found at the git repo: https://github.com/davenuman/bowline

I have now had success with Bowline on both new project and on existing Drupal 6 and 7 projects. Just last week I also tried it out with Drupal 8 and I'm happy to report that it works just fine on Bowline as well.

Dockerfile flexibility

Out of the box, Bowline ships with two containers. One for mysql 5.5 which is simply the default image from Docker Hub. The second is the web container providing apache, php 5.4, and related software. The web container is defined within the .docker/web-5.4 directory and the Dockerfile with supporting config files are based on the awesome work of the new Drupal testbot project.

Automation, running tests

Imagine your developers getting their local sandboxes up and running in a matter of minutes. This is now possible, facilitated by a few simple bash scripts. Bowline provides a template document intended for instructing your team on how to get set up: https://github.com/davenuman/bowline/blob/master/sandbox.md

Basically, they run build sync-db to get a copy of the database, build sync-files to get the site's uploaded files, then build import which does all the work of building the docker containers and importing the database. There is also a backup script which will save a snapshot of your database named after your current git branch which is handy for switching to another task while preserving your work. The run command is intended for running your automated tests. It assumes behat but you can modify it to run whatever testing software you use. The nice thing is that our developers are all running local behat tests on the exact same software stack as each other and as the test server. We have a Jenkins server with docker and have jobs configured to execute the build and run commands just like we do on our own machines.

Slaying File Permission Dragons Anyone who has worked with a LAMP stack has bumped into file permission issues with uploaded files. Add a docker container to the mix which is mounting your project files and serving them up as the apache user withing the container and there is lots of ways to mess things up. This dragon gave us some grief early on when starting to use docker in this way. We won the day by setting the apapache user to run with the same uid as the docker host user. This way each developer will have ownership to their own file uploads on their system. Here's the simple bash code that makes it possible: # Set the apache user and group to match the host user. OWNER=$(stat -c '%u' /var/www) GROUP=$(stat -c '%g' /var/www) usermod -o -u $OWNER www-data groupmod -o -g $GROUP www-data (source) Room for improvement

One tricky thing we found using docker containers is using drush in a complete way, particularly using drush site aliases. For now we have "crush" which is a temporary work around but not too bad of a work around actually. Crush is a simple bash function that calls drush as a command on the docker web container. We use crush to clear cache manage features and such, and it is working well. However it's not ideal and I'd like to add ssh server to the stack to allow for proper drush site alias usage.

There's always room for improvement. I'd like to find an elegant way to incorporate more developer tools such as sass, compass and debugging tools. Every project is different but it would be nice for Bowline to have some basic Behat smoke tests build in. These things will hopefully be added to the Bowline project as we use it and add things to our drupal project. And yes, pull requests are welcome.

Topics

Amazee Labs: Amazee Labs launches first customer website on Drupal 8

January 28, 2015 - 7:41am
Amazee Labs launches first customer website on Drupal 8

We just completed our third Drupal 8 project: SGG - Schweizer Gemeinnützige Gesellschaft after relaunching our own website, helping out with Drupal.com we are now excited to launch our first client website fully on the upcoming major release of our favorite open source CMS.

Having built the community site Intergeneration and voting platform CHymne using Drupal 7, we now chose Drupal 8 for the relaunch of the presentation website of SGG. The compact feature of the site allowed us to apply today's strenghts Drupal 8 and so we recreated the associations website relying entirely on Drupal 8 core functionality.

Building the SGG relaunch was a team effort, read on to find about the findings of each of us for building the relaunch on the latest beta release of Drupal 8.

Boris was involved with site building, these are his thoughts:

Drupal 8 in terms of sitebuilding is awesome. After a short time you are able to build almost everything out of the box. Sometimes you have to think around the corner to get your result. And sometimes you get stuck because of some nasty bugs.

But with a great Backend-Developer on Hand (Alex) we could also solve some issues during creation of our project.

  • Building content types is much more powerful with Drupal 8 core: you can define view modes, form modes and many field types like e-mail, entity reference etc have been integrated
  • Full translation capabilities: thanks to #d8mi no dozen of i18n modules are required but Drupal 8 core ships with configuration, content & interface translation
  • WYSIWYG editing functionality is part of core and just works
  • Views in Core: we can create dynamic listings  
  • Enhanced block system: we can even reference blocks using entity reference now

Alex did backend development for the SGG relaunch, his feedback on the project:

  1. A lot of things in D8 are plugins and the new plugin system is really cool: to extend a plugin, all you need is to extend its class and place your new class in the proper namespace.
  2. Even if core still uses some PHP magic, everything is documented well with PHPDoc, and the IDEs help a lot to write code.
  3. Tip: while Drupal 8 is in the beta stage, use core dev releases only for core development. I tried dev releases two times, in both cases a lot of functionality was broken. If you need D8 in production: use beta releases, they are much more stable.
  4. Every piece of PHP code is covered with tests. That's super cool: if you want to understand how the thing works or what its purpose: read its tests, you will learn a lot from there.
  5. Sad: there is no core stuff for testing JavaScript code. There are some contrib modules for that, but, anyway, it's not in the core, so JavaScript tests are not mandatory.
  6. Sad: beta-to-beta updates are not ready. That makes core updates really hard. The good thing is that it's the target number one.
  7. The translation system is really good. All translation cases are handled right in the core.

Overall, I have really really good feeling about D8. Previously we said "Drupal way" about many coding stuff. Now it's the "right way"! Drupal core now uses bleeding edge technologies, and that makes work really interesting.

Kathryn did front-end development, this is what she would like to share:

Building a custom theme for Drupal 8 is almost an entirely different process than building one for Drupal 7. I think this is especially true for Amazee Labs since historically, we are "Panels people." Because the Panels module isn’t ready for Drupal 8, we're forced to make heavy use of template files. 

In my experience with Drupal 8 (and on this project in particular), working with Twig templates is much more concise and straightforward to code than a D7 .tpl file. As a developer with only basic PHP skills, the Twig syntax is easier to grasp. 

For the SGG theme, there are over ten custom Twig templates, most of which extend upon another.

Even though the design of the SGG theme appears simple, there were many instances where the content display required use of the Twig {{ dump() }} function to drill into variables. 

One thing I found frustrating during this process was sifting through the output of the dump’s results. Krumo formatting in D7 is so nice and tidy, while the D8 output is a jumbled mess, even after wrapping it in a <pre> tag. 

To work around this, Kint is your new best friend. You’ll need to download the 8.x version of the Devel module, enable it, along with Devel Kint. Include {{ kint() }} in your template file and voilà - nested arrays that won’t make your head spin around. 

I could go on, but the gist of it is: mastering Twig continues to be my number one priority for Drupal 8. The SGG Drupal 8 project was no exception.

And this is the result: http://sgg-ssup.ch

Creating web sites with Drupal 8 is possible today. You certainly have to be aware of constraints regarding not-yet-upgraded modules and account for some core bugs along the way. On the other hand, working with Drupal 8 just feels right: best practices from back-end to front-end development have been incorporated and the site building experience is really solid.

Step by step we will approach bigger client projects with Drupal 8. Interested in a future proof website? - let's start a project together.

Annertech: Check out my website - it's responsive! Yawn!

January 28, 2015 - 6:00am
Check out my website - it's responsive! Yawn! "OMG! You've got a responsive website!"

Once something to brag about, this is now old news.

ThinkShout: Reimagined Sprints and Introducing RedHen Raiser

January 27, 2015 - 4:00pm

We’ve been experimenting with monthly team sprints at ThinkShout over the last year with varied levels of structure and outcomes. This month, we decided to take a step back, reevaluate our goals, and reimagine our sprint process. And, we moved it to a Thursday. A bow-tie Thursday.

Previously, these sprints were loosely structured around a topic or technology, such as Twig in Drupal 8. Suffice it to say, they were a lot of fun and very exploratory, but they weren’t the most engaging for everyone on the team. This time around, we decided to collaborate on a single initiative - in this instance, a product - that would benefit from the skills and perspectives of everyone in the company. Consequently, we decided to rally around RedHen Raiser, our new peer-to-peer fundraising distribution for Drupal.

Introducing RedHen Raiser

RedHen Raiser is designed for building peer-to-peer fundraising websites, like the sites you see for marathons and walks, where a fundraising campaign is made up of myriad individual and team pages, and can be customized by the participants for fundraising amongst their respective communities, while remaining connected to the larger campaign.

As the name suggests, RedHen Raiser is built on top of RedHen CRM, including the RedHen Donation and RedHen Campaign modules, and it’s chock full of awesome:

  • Easy Campaign creation so site visitors can join right away by creating their own Team or Individual fundraisers.

  • A beautiful, consistent fundraising experience that is based on inherited display values from the larger Campaign.

  • Goal progress widgets including thermometers, leaderboards, etc.

  • Mini-blogs for Campaigns and Fundraisers via Update content type.

  • Ability to create and maintain different pages for different fundraisers with a single account.

  • Automated start and end dates.

  • Commerce-readiness - just add your payment method and go!

  • Single-page donation forms via RedHen Donation.

  • Built using established modules with simple UI (Views, RedHen, Context, etc) for easy customization.

It’s ThinkShout’s latest offering in a suite of nonprofit engagement building blocks that we’ve been developing, and was initially developed for the Capital Area Food Bank of Washington, DC. RedHen Raiser competes feature for feature with top software as a service (SaaS) peer-to-peer fundraising platforms, such as TeamRaiser, CauseVox and Razoo.

As a result of our work with this client, we were able to release a very rudimentary version of RedHen Raiser on Drupal.org that would provide a basic starting point to other developers interested in building a peer-to-peer fundraising tool. The product is also a huge win for CAFB of DC, simply because they were able to reap a huge dividend on their initial investment by getting these improvements for free.

Involving the Full Team in One Sprint

As an open source product, RedHen Raiser presented us with some interesting opportunities to engage more than just our engineers in the sprint process, and it certainly needed a lot of love on a lot of fronts. Leveraging the different interests and expertise of our 18-person company, we split into five teams:

  • Dev Ops - this team focused on deployment infrastructure, build processes, and automated testing;

  • Bug Fix & Feature Dev - team members spent the sprint day working on the development backlog;

  • UX - the User Experience team worked ahead of the feature development team to identify and sketch out new features and enhancements;

  • QA - the Quality Assurance team was made up of our project managers acting as "product owners;"

  • Community Engagement - this team, consisting of our sales, marketing, and operations staff, was tasked with documenting the sprint and sharing our contributions with the wider Drupal and nonprofit technology communities.

It’s worth noting that the quality assurance team and the community engagement team came together for the first half of the sprint for an in-depth training on the Drupal contributed modules and components underlying RedHen Raiser. Ironically, we often get so busy building these sorts of tools for our clients that we don’t stop to educate our own "non-developer" team members on how stuff works. By taking this time to dive into the nitty gritty with our project managers, marketing and operations folks, we create better advocates for these solutions and help ensure that everyone in the company feels like contributor to our success.

Planning for the Sprint

As ThinkShout has grown, the need for sprint planning has grown with it. Back when we first started these sprints, we could fit our entire team around a single table (covered in pizza boxes and beer) and call out with development tickets we each needed help with.

Now, with a team of 18 working together from 11am to 5pm, these sprints take a bit more planning - to say nothing of balancing the opportunity cost of investing a collective 108 hours of non-client work into a single week. To keep things running smoothly, we’ve taken a more project-planning-esque approach to our sprint days:

  • Scheduling in advance: The date and time of the sprint is scheduled a month in advance. We used to just stick with the last Friday of the month, but found that this sometimes excluded certain team members on deadlines or vacation. Now, we coordinate a bit more tightly to help ensure participation of as many team members as possible.

  • Laser focus: the focus of the sprint is announced to the team three weeks in advance. This gives the team time to think about stuff they want to work on, and add to the feature backlog in the weeks coming up to the sprint.

  • Pre-sprint planning meetings: The department leads meet a week before the sprint to form teams and structure the sprint agenda, and prioritize the development/feature backlog two days in advance of the sprint.

  • Pre-sprint presentations: The week before the sprint, we do a short, company-wide presentation on the sprint topic at our weekly staff lunch. This helps energize the team and sparks knowledge sharing in the lead up to the sprint day.

  • Formally "opening" and “closing” the sprint day: As our sprint commences, we kick things off with a quick, all-staff scrum. More importantly, we pull the team back together at the end of the day for each sprint team to present (and celebrate!) what they’ve completed.

Outcomes of Our RedHen Raiser Sprint

So what does it all mean? This new approach to our team sprints resulted in just shy of 100 commits on RedHen Raiser and the underlying modules that power the distribution. We published a new release of RedHen Raiser, RedHen Donation and the RedHen Campaign modules - as well as a release of our base RedHen CRM suite.

One of the biggest wins to come out of the sprint are automated tests powered by Behat. Tests are triggered with every commit to GitHub and run on Travis CI. At this point, test coverage is a bit limited, but the foundation has been laid for complete test coverage for RedHen Raiser, a critical factor when organizations are evaluating which software to use.

To top it off, we cleaned up a few RedHen project pages on Drupal.org and began working on a RedHen-specfic QA testing plan. We also reached out to the RedHen open source community to let them know what we were up to and how folks can continue to get involved. Most of all, we are proud to say that this effort is a huge contribution to the nonprofit tech community, in that it provides major improvements to a powerful tool that can be leveraged for free - and has the documentation to support it!

All in all, the ThinkShout team came together in a big way, and accomplished much more than we could have if we had remained siloed in our approach. We had a lot of fun, drank some beer, ate some good food, and got to collaborate as a whole team on something really cool. We’re really looking forward to the next one!

Drupal Commerce: Shipping the Future

January 27, 2015 - 10:57am
Shipping Requirements Have Changed

Heretofore, shipping has focused on exposing a simple yet effective API for connecting rating and shipping companies to the checkout process. Many stores eschew real-time rating and instead opt to offer flat-rate shipping or free shipping on orders. This entirely removes the need for rating. For those who do use real-time rating, the existing process offers a simple set of tools that are only adequate for simple shipping needs.

DrupalCon News: Calling UX Designers

January 27, 2015 - 10:13am

Welcome UX Design experts. We want to hear your latest thoughts, ideas, techniques and analysis on the latest state of the web. If you’ve got a burning idea you want to share about how to do things better, we want to hear about it.

We’re looking for talks on:

Cheeky Monkey Media: How to automatically send your content to social networks

January 27, 2015 - 9:00am

A few months ago I was asked to help manage our company blog. As a busy drupal developer, I had little time to post all of our new blog content on every social media site. So I decided to automate this so I could spend more time on client projects.

My first step was to look around and see what was currently available. Although there was some options, I found them to be a bit heavy for my application.

One of the things I was looking for was to be able to choose what social networks our content would be posted to. For example, I wanted to be able to choose to post this page to...Read More