Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 53 min 14 sec ago

Phase2: Getting Started with Grunt Drupal Tasks

Wed, 05/11/2014 - 16:55

In September, Phase2 released a Grunt-based tool for building and testing Drupal sites. We have been working on the tool since January, and after adopting it as part of our standard approach for new Drupal sites, we wanted to contribute it back to the community. We are happy invite you to get started with Grunt Drupal Tasks.

Grunt is a popular JavaScript-based task runner, meaning it’s a framework for automating tasks. It’s gained traction for automating common development tasks, like compiling CSS from Sass, minifying JavaScript, generating sprites, checking code standards, and more. There are thousands of plugins available that can be implemented out-of-the-box to do these common tasks or integrate with other supporting tools. (I mentioned that this is all free and open source software, right?)

Grunt Drupal Tasks is a Grunt plugin that defines processes that we have identified as best practices for building and testing Drupal sites.

Building Drupal

The cornerstone of Grunt Drupal Tasks is the “build” process, which assembles a runnable Drupal site docroot from a Drush make file and custom code and configuration.

The make file defines the version of Drupal core to use, the contrib modules, themes, and libraries to download, and even patches to apply to any of these components. The make file can include components released on Drupal.org or stored in public or private repositories. For patches, our best practice is to reference patches hosted on Drupal.org and associated with an issue. With these options, the entire set of components for a Drupal site can be declared in a make file and consistently retrieved using Drush.

After the Drush make process assembles all external dependencies for the project, the Grunt Drupal Tasks build process adds custom code and configuration. This includes custom installation profiles, modules, and themes, as well as “sites” directory files, like sites.php and settings.php for one or many subsites, and other “static” files to override, like .htaccess and robots.txt. These custom components are added to the built docroot by symlink, so it is not necessary to rebuild for every update to custom source code.

These steps results in a Drupal docroot assembled from custom source in the following structure:

src/   modules/     <custom modules>  profiles/     <custom installation profiles>   sites/     default/       settings.php     <optionally, other subsites or sites.php>   static/     <optionally, overrides for .htaccess or other files>   themes/     <custom themes>   project.make

Grunt Drupal Tasks includes other optional build steps, which can be enabled as needed for projects. One such task is the “compile theme” step will compile Sass files into CSS.

This build process gives us a reliable way for assembling Drupal core and contrib components, for adding our custom code, and integrating development tools like Sass. By using Grunt to automate this procedure, it becomes a portable script that can be shared among the project’s developers and used in deployment environments.

Testing Drupal

In order to help make best practices the default, Grunt Drupal Tasks includes support for a number of code quality and testing tools.

A “validate” task is provided that includes checking basic PHP syntax and Drupal coding standards using PHPLint and PHP Code Sniffer. We highly recommended that developers use this command while coding, and have included it as part of the default build process.

An “analyze” task is also provided, which adds support for the PHP Mess Detector. This task may be longer-running, so it is better suited to run as part of a continuous integration system, like Jenkins.

Finally, a “behat” task is provided for running test scenarios with Behat and the Drupal Extension. This encourages writing Behat tests for the project and committing them with the project code and build tools, so the tests can be run by other developers and in the integration environment by a continuous integration system.

Scaffolding for Drupal Projects

The old starting point for Drupal projects was a vanilla copy of Drupal core. Grunt Drupal Tasks offers scaffolding for Drupal projects that starts with Drush make, integrates custom code and overrides, and provides consistent support for a variety of developer tools.

This scaffolding is provided through the example included with Grunt Drupal Tasks, which is the recommended starting point for new projects. The scaffold structure adds a layer above the aforementioned “src” directory; this layer includes code and configuration related to Grunt Drupal Tasks (Gruntconfig.json and Gruntfile.js), dependencies for the supporting tools (composer.json), and other resources for the tools (features/, behat.yml, and phpmd.xml).

The example includes the following:

features/ src/ .gitignore Gruntconfig.json Gruntfile.js behat.yml composer.json package.json phpmd.xml

For full documentation on starting a new project with Grunt Drupal Tasks, see CONFIG.md.

Learning More

Watch the Phase2 blog for more information about Grunt Drupal Tasks. If you are attending the Bay Area Drupal Camp this week, please check out my session on Using Grunt to Manage Drupal Build and Testing Tools.

Categories: Elsewhere

InternetDevels: Facebook + Drupal — sending invitations to friends

Wed, 05/11/2014 - 15:45

We have already spoken about publications on Facebook public pages. Now we want to tell you how to send invitations to friends using Facebook SDK for JavaScript.

Read more
Categories: Elsewhere

Acquia: Meet Drupal core contributor & mentor, Kalpana Goel

Wed, 05/11/2014 - 15:32
Language Undefined

Kalpana Goel - web developer with Forum One - and I sat down to chat at DrupalCon Amsterdam. We discussed the topic of Dries Buytaert's Amsterdam keynote: the potential benefits of "gamifying" and rewarding companies for supporting contributions, especially to Drupal core; Kalpana's discovery of Drupal; her contribution to the Drupal 8 web services initiative and Drupal's culture of sharing, and some of the benefits that are coming with Drupal 8.

Categories: Elsewhere

Dries Buytaert: The job of Drupal initiative lead

Wed, 05/11/2014 - 15:18
Topic: DrupalLeadership

Drupal 8 is the first time we introduced the concept of formal initiatives and initiative leads. Over the course of these Drupal 8 initiatives we learned a lot and people are floating several ideas to increase the initiatives' success and provide Drupal initiative leads with more support. As we grow, it is crucial that we evolve our tools, our processes, and our organizational design based on these learnings. We've done so in the past and we'll continue to do so going forward.

But let's be honest, no matter how much support we provide, leading a Drupal initiative will unquestionably remain difficult and overwhelming. As a Drupal initiative lead, you are asked to push forward some of the most difficult and important parts of Drupal.

You will only succeed if you are able to build a strong team of volunteers that is willing to be led by you. You have to learn how to inspire and motivate by articulating a vision. You establish credibility by setting clear objectives and roadmaps in partnership with others. You have to motivate, guide and empower people to participate. You have to plan and over-communicate.

Not only do you have to worry about building and leading a team, you also have to make sure the rest of the community has shared goals and that everyone impacted has a shared understanding of why those decisions are being made. You use data, ideas and feedback from different sources to inform and convince people of your direction. Your "soft skills" are more important than your "hard skills". Regardless, you will lose many battles. You only "win" when you remain open to feedback and value change and collaboration. To lead a community, you need both a thick skin and a big heart.

Success is never a coincidence. You put in long hours to try and keep your initiative on track. You need relentless focus on doing whatever is necessary to succeed; to be the person who fills all the gaps and helps others to be successful. Instead of just doing the things you love doing most, you find yourself doing mundane tasks like updating spreadsheets or planning a code sprint to help others be successful. In fact, you might need to raise money for your code sprint. And if you succeed, you still don't have enough money to achieve what is possible and you feel the need to raise even more. You'll be brushing aside or knocking down obstacles in your path, and taking on jobs and responsibilities you have never experienced before.

Your objectives will constantly shift as Drupal itself iterates and evolves. You will want to go faster and you will struggle with the community processes. Imagine working on something for a month and then having to throw it out completely because you realize it doesn't pass. Frustration levels will be off the charts. Your overall goal of achieving the perfect implementation might never be achieved and that feeling haunts you for weeks or months. You will feel the need to vent publicly, and you probably will. At the worst moments, you'll think about stepping down. In better times, you realize that if most of your initiative succeeds it could take years of follow-up work. You will learn a lot about yourself; you learn that you are bad at many things and really good at other things.

Leading is incredibly hard and yet, it will be one of the best thing you ever did. You work with some of the finest, brightest, and most passionate people in the world. You will see tangible results of your hard work and you will impact and help hundreds of thousands of people for the next decade. There is no better feeling than when you inspire or when you help others succeed. Leading is hard, but many of you will look back at your time and say this was the most gratifying thing you ever did. You will be incredibly proud of yourself, and the community will be incredibly proud of you. You will become a better leader, and that will serve you for the rest of your life.

Categories: Elsewhere

KnackForge: Drupal Views exposed filter as Links

Wed, 05/11/2014 - 13:41

In Drupal views, we have the option of exposing the filters to users. By default, the exposed filters are displayed as Select boxes. Recently in a multilingual project, there was a requirement to display Courses based on Language. And the Languages had to be shown as links. In order to achieve this functionality, the Views exposed filter had to be customized.

To start with the customization, we need to alter "views_exposed_form" using hook_form_alter

function module_name_form_alter(&$form, &$form_state, $form_id) { global $language; if ($form['#id'] == 'views-exposed-form-course-listing-page') { $links = $form['language']['#options']; $vars = array(); foreach ($links as $tid => $term_name) { if ($language->language != $tid && $tid != 'All')  { $options = array( 'attributes' => array( 'class' => array( 'course-filter-tab' . $tid), 'id' => $tid, ), 'html' => TRUE, ), $language_list = language_list(); $language_title = $language_list[$tid]->name; $vars['items'][] = l($language_title, "course", $options); } } $vars['type'] = 'ul'; $vars['attributes']['class'] = array('course-tabbed-filter'); $prefix = theme('item_list', $vars); $form['links'] = array( '#markup' => $prefix, ); } }

The above code will help us render the select box as link, but to make the links functional we need some jQuery code.

Categories: Elsewhere

Blair Wadman: Rolling back a Drupal site following Drupalgeddon

Wed, 05/11/2014 - 10:51

There is a lot of talk in the Drupal community and media about the Drupal security vulnerability that was fixed in the Oct 15th update (7.32). If you have missed the details, here is a summary:

A highly critical security vulnerability was found in Drupal's database abstraction API. This was fixed with the release of 7.32 on Oct 15th. If you did not upgrade to Drupal 7.32, or apply the patch, by 11pm UTC on Oct 15th, your site may be compromised. Applying the patch after this will not remove any backdoors that may have already been added to your site or server.

So, if you upgraded or applied the patch immediately, or within 7 hours, you are safe (or as safe as you can be). But if you didn't, it is time to take precautionary measures. The best and most effective measure to take is to roll back everything to a state before Oct 15th 2014. And when I say everything, that includes the server not just the web files and database because backdoors could have been added anywhere.

I upgraded my clients site within 1 hour of the 7.32 release, so they are safe. But I had a couple of personal sites where I missed the 7 hour window by a few hours. Despite not seeing evidence of any hacking, I performed the rollback as a precautionary measure. What follows are my notes on how I did this.

Tags: DrupalPlanet Drupal
Categories: Elsewhere

Modules Unraveled: 125 Deploying Drupal Code Using Deployotron with Thomas Fini Hansen and Thomas Gielfeldt - Modules Unraveled Podcast

Wed, 05/11/2014 - 10:25
Published: Wed, 11/05/14Download this episodeDeployotron
  • What is Deployotron?
    It’s a deployment tool.
    A low-key approach to easy and safe deployment.
  • When did you start developing it?
    Dec. 2013
  • Why did you feel it was necessary to add another layer on top of Drush?
    Needed simple, safe, easy to grok deployment process. Not a Swiss army knife. Other solutions proved to be either too complex/feature-rich or require 3rd party software beyond a simple drush command.
  • How does it work?
    Deployotron is implemented as a drush command.
    When deploying it runs a set of “actions” that does the different steps of deploying.
  • What kinds of actions can you perform with Deployotron?
  • Is this extendable? Can other developers add their own commands to be performed during deployment?
  • Is there a way to configure deployment per environment? So that certain commands are always performed on Staging but not on Live.
  • What needs to be setup before you can use Deployotron?
    Deployotron requires drush and the appropriate ssh public keys on the target servers.
    And Git.
  • How does it improve the deployment workflow?
    Easy and fast deployment to other enviroments from the command line.
    Quick to set up for a new project.
  • What if you mess up? Is there a rollback feature?
    There’s an OMG command which will import a dump and reset the codebase to the one that was deployed at the time.
  • How does this integrate with other tools like Capistrano, Aegir, etc.
    It doesn’t. Deployotron was meant to be more of an alternative; a simpler one.
  • So, is this aimed at people hosting on shared hosts? Or do you need a VPS at minimum?
    Not aimed at shared hosts, as such, but it does support it, given that you have ssh access and drush availability of course.
Use Cases
  • How are you guys using it at Reload?
    Very carefully :-)
    With careless abandon.
  • Do you know of anyone else using it?
    No, not specificly, but there was some interest at the DrupalHagen DrupalCamp.
Episode Links: DeployotronGielfeldt on drupal.orgFini on drupal.orgFini on TwitterGielfeldt on TwitterVisual Testing with Applitools Eyes Reload.dkTags: DeploymentDevelopment WorkflowDrushplanet-drupal
Categories: Elsewhere

Amazee Labs: Be a part of the community

Wed, 05/11/2014 - 10:02
Be a part of the community

You are into Drupal. That's great! But have you really been into Drupal? I mean, have you seen what Drupal is all about?

Drupal is not only a content management framework to build awesome websites! It is way more than that. Behind the technical part of Drupal are the most creative, savvy and kind people I have ever met. Those people-from all over the world-form one of the most active and powerful open source communities around the web.

To fully experience the community it is not enough to participate in the issue queue, commit patches and help others out. Have you ever wondered who is behind "The mother ship" or who created your favourite module? If you want to find out, you have to get active and visit one of the many Drupal Camps or Cons which are being organised around the world.

You might run into Angie Byron (aka webchick), Jeffrey A. McGuire (aka "jam" or as I call him Mr. Moustache), Morten Birch (aka the King of the North, creator of the mother ship), Sebastian Siemmsen (aka fubhy, maintainer of the Omega theme and creator of the widely loved Omega 4 theme) and you might even have an encounter with Dries Buytaert.

At Camps and Cons you have plenty of opportunities to engage and connect with others, share know-how, present your module or contribute to core in many different ways. Even summarising an issue in the queue helps a lot.

Drupal is more than just a content management framework. It is also the people behind the scenes. It's about (new) friends and friendship. It's about taking part in a great community. So go on and save the date for the next Drupal Camp or the DrupalCon 2015 in Los Angeles.

Categories: Elsewhere

Drupal core announcements: Drupal 7 core release on Thursday, November 6 (or Friday, November 7)

Wed, 05/11/2014 - 08:38
Start:  2014-11-06 (All day) - 2014-11-07 (All day) America/New_York Sprint Organizers:  David_Rothstein

The monthly Drupal core bug fix release window is this week, and since it has been a while since the last one, I plan to release Drupal 7.33 during this window. Normally, the release would be on a Wednesday, but this time it will be on either Thursday or Friday in order to give people a bit more time to test the latest code. Per our release policy, this will be a bug fix release only (no security fixes).

The final patches for 7.33 have been committed and the code is frozen (excluding documentation fixes and fixes for any regressions that may be found in the next couple days). So, now is a wonderful time to update your development/staging servers to the latest 7.x code and help us catch any regressions in advance.

There is one relevant change record for Drupal 7.33 which is listed below, as well as a new feature that is particularly worth highlighting. This is not the full list of changes, rather only a list of notable API additions and data structure changes that might affect a number of other modules, so it's a good place to start looking for any problems:

You might also be interested in the tentative CHANGELOG.txt for Drupal 7.33 and the corresponding list of important issues that will be highlighted in the Drupal 7.33 release notes.

If you do find any regressions, please report them in the issue queue. Thanks!

Upcoming release windows after this week include:

  • Wednesday, November 19 (security release window)
  • Wednesday, December 3 (bug fix release window)

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.

Categories: Elsewhere

Chapter Three: Chapter Three at BADCamp 2014

Wed, 05/11/2014 - 00:48



BADCamp is the largest free Drupal event on the planet and it is happening this week, right here in our back yard, at the Palace of Fine Arts.



Chapter Three Trainings

The event kicks off on Thursday with summits and trainings around specific interest areas.

Categories: Elsewhere

Aten Design Group: BADCamp 2014: Supporting Websites After Launch

Tue, 04/11/2014 - 21:48

If Magellan hired shipwrights instead of sailors, we would remember him for having the most seaworthy ships lost at sea. If you tried to get your oil changed at an assembly line instead of an auto body shop, the factory would turn you down, or worse do a slipshod job to get you out of the way and get back to building cars.

Similarly, most web development shops create their process around building websites, not supporting them. Aten built a dedicated Support Team out of recognition that maintaining and extending websites requires its own skill set and organizational structure.

At BADCamp 2014, Sandra and I, both Technical Account Managers and developers on Aten’s Support Team, will present “Old dogs, new tricks: Supporting websites after launch”, Saturday, November 8, 2014 at 1:30pm.

We’ll discuss why it’s important for clients to work with a development team specifically designed to support existing sites, and how Aten’s support approach:

  • keeps aging sites relevant with new features;
  • keeps sites running longer with less technical debt;
  • gives us enormous insight throughout a project’s lifecycle so we can consult on a client’s high level objectives and real world challenges;
  • and makes us a flexible partner who can puts clients’ minds at ease, with both a rapid response team for hot fixes, and a technical and strategic resource at the ready for larger blocks of work.

We will also discuss how viewing support and maintenance as an opportunity — not an opportunity cost — benefits Aten as well as our clients, and why we think our approach incentivizes great work from developers while building enduring client relationships.

See you at BADCamp!

Categories: Elsewhere

Phase2: Introducing the Behat Drupal Extension 3.0

Tue, 04/11/2014 - 15:36

I am proud to announce the release of the Behat Drupal Extension 3.0! Since 2012, the Drupal Extension has been used for Behaviour Driven Development of thousands of Drupal sites all over the world. The project began as part of the Drupal.org upgrade, and was quickly generalized to enable the testing of any Drupal site.

Version 3 has many exciting new features, and is compatible with Behat 3. Note version 2 does not exist, wanting to avoid version soup.

Behavior Driven Development at BADCamp

Before I dive into the new features, it is important to clarify the difference between testing an application, and Behavior Driven Development (BDD).

As everzet pointed out at Drupalcon no business-critical feature starts with

When browsing an article User Should be able to see related articles

rather, it starts with a conversation

In order to read more interesting articles As a reader I need to see related articles to the one I'm reading

While both are testing something, only the latter is truly describing a behavior that matters to a stakeholder. This is the subject of a blog post, or series of posts, in and of itself, so more on this subject later.

What’s new Documentation

Documentation for this project has been integrated into the repository, and is automatically building on readthedocs.org. Thanks to Melissa Anderson for this awesome work!

A starter context

A starter Drupal context that makes no assumptions around the language used for each test, but still provides all the previous functionality to interact directly with Drupal.

Users are encouraged to start tests from this context which will allow them to use truly ubiquitous language that is specific to each project.

Drupal Drivers

The Drupal Drivers now exist in a separate project, allowing for non-Behat applications to interact with Drupal (e.g., calling directly from Mink, or Codeception).

Note that the Drupal 6 driver has been removed, but since drivers are now separate projects, it will be easy to port that over to the Drupal Extension 3, should somebody want.

It should also be noted that Drupal 8 support will require ongoing work as the code base there evolves towards release.

More granular pre-defined step-definitions

Existing step definitions have been split into 4 indepentent contexts:

  • DrupalContext – This contains steps for working with content, users, and taxonomies.
  • MinkContext – This is an extension to the Mink Extension, providing additional steps for working with regions and forms.
  • MessageContext – Provides steps for working with Drupal success/warning/error messages.
  • DrushContext – Provides steps for calling drush commands directly from scenarios

This allows for the use of some pre-definied step-definitions, rather than the previous all-or-none approach.

No more regex!

The pre-definied steps now use the new turnip syntax introduced in Behat 3:

Given I am viewing a/an :type (content )with the title :title

rather than

Given /^(?:a|an) "(?P<type>[^"]*)" node with the title "(?P<title>[^"]*)"$/

What’s a ‘node’?!

The term node has been removed from steps and replaced with content in all pre-defined steps.

What’s next? BDD Mini Summit

I will be attending the Behat mini-summit at BADCamp along with several other folks from Phase 2. I hope to highlight the Drupal Extension 3, and discuss best-practices for the wide variety of testing needs. I also hope to continue discussions around Behat, Mink and Drupal core.

Categories: Elsewhere

Mediacurrent: Website Launch Checklist

Tue, 04/11/2014 - 13:53

Launching a new Drupal website is exciting and can be a little risky if you aren’t careful. There are several things to accomplish, details that are too essential to overlook, and many people collaborating to make the deployment go smoothly. 

Categories: Elsewhere

Drupalize.Me: Controlling CSS Classes with the Classy Theme in Drupal 8

Tue, 04/11/2014 - 13:15

You may have heard some news about the fact that a new theme has been added to Drupal, named Classy. But what kind of theme is it exactly? Is it a pretty new look for Drupal 8? Well, no. You will still see Bartik as the default theme on your Drupal 8 site, so why another theme? Classy is a new base theme in core, which Bartik and Seven will then use as their bases. The idea here is to provide more flexibility to themers when it comes to choosing default CSS classes.

Categories: Elsewhere

Acquia: PHP is getting Faster

Mon, 03/11/2014 - 18:05

Competition is helping to drive big performance gains in PHP. Alternative ways of running PHP are becoming viable and with them is coming accelerated speed.

Categories: Elsewhere

OhTheHugeManatee: Drupalgeddon: Best Practices Aren't Good Enough Anymore

Mon, 03/11/2014 - 17:30

Last week’s Public Service Announcement from the Drupal security team caused a lot of attention. And rightfully so – it told us that the vast majority of Drupal 7 sites around the world are considered compromised. A mere 7 hours after critical security patch SA-CORE-2014-005 was released, robots were spotted in the wild, bulk-hacking Drupal 7 sites with this vulnerability. This is something that’s never happened to the Drupal community before, and it is extremely serious. In some way it’s our own version of Heartbleed and other highly-publicized critical vulnerabilities in open source software.

This issue should not reflect badly on the Drupal community, or the Drupal product at all. Vulnerabilities happen to every software project – particularly the large and complex ones like Drupal! In this case it was the result of a choice in the database abstraction layer to use emulated prepared statements. There’s a great dissection of the whole vulnerability at ircmaxell, but the point here is that it was an intentional decision. We were aware of a theoretical security risk, just as we are in making lots of decisions. But theoretical risks don’t mean much compared with real, measurable losses from the available alternatives. As I said before, this can happen to any software project, and Drupal is a relatively responsible, well written one. What’s interesting now, is the response.

First of all, I am amazed to read responses from many Drupal users who are panicked at having to run a diff of their sites, because they don’t have appropriate tools in place. If you are developing without a VCS and automated backups, you are doing more harm than good. Just stop. Take a week to learn the basic requirements of a development environment, and start employing them. End of story.

I’m not concerned for those people – their sites were disasters waiting for an excuse anyway. What’s frightening about this particular situation is that even if you are working with backups and a VCS, even if you patch critical security vulnerabilities on an aggressive schedule, it still wasn’t good enough.

All of my Drupal 7 sites are affected by this PSA. I work for a large, well-respected agency, with access to leading-edge workflows and tools. We follow best practices. All of my sites are secured well beyond PCI requirements. But PCI requirements say that critical security patches have to be applied within 30 days of release. Our best practices include patch review from the tech lead, and validating patches on test environments before pushing them live. With only 7 hours between patch release and exploits in the wild, there isn’t time for any of that.

I’ve heard people complain that it’s too difficult to update Drupal. “drush up —security-only” seems pretty simple to me, or at least simple enough that further simplification won’t address the real problem. That’s because the real problem isn’t that it’s difficult to apply updates – it’s that a human be ing has to initiate them. I live in the Central European timezone, GMT+6. The patch was released at 10PM for me, and bots were exploiting it by 5AM the following morning. I went to work that day and initiated the patching process, so that my patches could be “responsibly” deployed to live with 24-48 hours of client validation time on my dev and staging environments. Despite being relatively on top of patches and responding relatively quickly, the fact that I’m human, and my clients are human, meant we never stood a chance of patching this issue fast enough. Even if we skipped validation, and even if the update process was just one button (rather than two commands), we would still have failed to update in time. I find myself reminded of the Battlestar Galactica pilot, where the Cylon robots are chasing the humans. After each hyperspace jump, the humans have 33 minutes to complete the calculations for another jump before the machines catch up with them. After 130 hours and 237 jumps, it becomes apparent that the humans’ need for sleep is a critical vulnerability.

The only solution is automated patching. It’s hard to figure out a workflow that allows it; indeed you’re forced into post-hoc testing, which means engineering an easy rollback solution. The truth is that 99% of security patches will not affect any of the functionality you’ve customized or upon which you rely, so hopefully this will be an edge case. But it’s a problem that actually has to be addressed. Here’s how I’m adapting my own projects over the coming weeks:

Every wednesday, every hour, my Jenkins instance runs a script which checks modules and core for each project for security updates. When an update is available, it automatically creates a branch off of Stable (my staging branch), applies the updates, and pushes the result up to the server. My git scripts already create a new subdirectory environment for every pushed branch. Once the environment is ready, Jenkins runs all available behat tests against the new branch. If all tests pass, the branch is automatically merged back into Master, Stage, and Live, and pushed. This push operation triggers a normal Jenkins deployment, which takes a backup anyway. An email is generated to the project administrator advising them which security updates were automatically applied, and linking to the relevant changefiles.

I’m excited about implementing this new layer of automation, because it builds on the best practice workflows I already like (test driven development, git flow VCS organization, automated deployment and backups…) to produce a tangible time savings and security improvement for my sites. At the same time, I can’t say that this is something I recommend for EVERYONE, precisely because it requires such a high level of environment maintenance. When you’re a one-person development shop, it’s hard to afford the time to set up the perfect development environment. It’s hard to convince those bottom-of-the-food-chain clients to pay for things like automated testing and deployment. And certainly once you have those things set up, you don’t get paid for maintaining them!

I’m going to be keeping my eyes open for better solutions that can be applied by the “developer on the street.” Something relatively easy, but which allows the same kind of automated, fast response time for security patches. I’m interested in any ideas you want to post in the comments!

Categories: Elsewhere

Phase2: Learn The Hard Things About Project Management At BADCamp!

Mon, 03/11/2014 - 16:53

I’ll be giving a talk at BadCamp called “Mistakes I have Made: Collected Project Management Failures.” It’ll be funny, and true, and probably reference a few different stories from the past. However, when I look at what the real truth is to a talk about project management mistakes, I go to the source. What are the hardest things about project management?

If you google this, you’re likely to get the answer of ‘everything’.

For me, when I look at this, I separate this out into five different areas of hard:

  1. Team
  2. Clients
  3. Services
  4. Alignment / Mission  
  5. General Sucking: Hard decisions

1. Team

Around the area of team, I think this is one of the biggest things that you’re hired to watch over as a project manager. It’s your job to make sure that you’re engaging the team to make sure that the problems get solved, that you’re building what you set out to build. It’s so common in my own work that when I feel like there is friction or struggle, I have to lean back and ask myself if I’ve actually worked on really engaging the team – or if I’ve just charged ahead full bore.  (Mistake #543)

Do I have the right team?

I have definitely been on projects or working with teams that just didn’t have the right fit. There had never been a conversation about if the people working on that particular ‘thing’ were right for it. (Mistake #324) Or they were being used in ways that didn’t suit them personally, they were being asked to use their weakest skills in a really strong way, and it was burning them out. (Mistake #221)

Did I give everyone enough time?

This is where people will use Agile to its best advantage. Agile, when you’re actually tracking story points and estimating, will give you enough space to be able to understand if you’ve crammed too much in. (Mistake #112) Did we ask too much in that space from people? (Mistake #14) Are we working under a really silly timeline (Mistake #87) and did we not find out until too late? (Mistake #98.) Even more to the point, once we know the problem, are we not willing to correct it? (Mistake #465)

2. Clients

Do we have the right clients? Are we, the people building things for them, the right people to do it? Do we understand their mission? Did we do enough to make sure they understood when, how, and where we were going to build? Do they understand what we’re not doing? Are they ok with their role here? Do they understand ‘scarcity’ in action? Does that shock them?

The list goes on, but in order to be the best technology partner, and you’re helping to lead everything to the finish line, everyone has to agree.

3. Services

This is the day-to-day stuff and where new project managers that are client facing get tripped up. Answering for the developers when you shouldn’t. “That should be easy.” Making estimates with having no idea what you’re doing. Estimating things in general. Making the expectations that you’re going to be available all the time. Or not setting the expectations at all.

Services isn’t the hardest-hardest part of this, but it generally adds to it.

4. Alignment / Mission

There’s a statement running around the internet right now that working on things that aren’t aligned with your values is just stressful. Working on things that are is called passion. You’ll notice when it’s just not working, because you can’t get rid of that pit in your stomach, that sinking feeling. Not listening to it is a big mistake.

5. General Sucking: Hard decisions

Part of your job is being the person that says no, that continually tries to find a way to make the project a success. You’ll sometimes be in the place where everything, all of these 4 things above are collapsing around you. And it sucks. And it happens to a lot of us that do this, because you are the one that’s pulling the threads together.

It gets better.

You are not always going to have these weeks. I refer to them as ‘hell weeks’. Please keep your hands and arms inside the hell week until it comes to a full and complete stop. In these weeks, it’s even more important for you to pay attention to you. Get some sleep. If you can’t get some sleep, talk to your team about how you are feeling, and figure out how to articulate what the problem is so that everyone can solve it together. (Also, ask yourself how you’re working with your team!)

Internalize the idea that you are no good to us dead, and take care of what you can. Projects end, one way or another, and you’ll get through it – one email, one day at a time. These things are hard, projects are hard, building things is hard – but hard things are worth doing.

Hope to see you at BADCamp for my session “Mistakes I have Made: Collected Project Management Failures.” Check out all of the Phase2 thought leaders at BADCamp!

Categories: Elsewhere

Singlebrook Technology: Super Simple Drupal Layout with Region View Modes

Mon, 03/11/2014 - 15:28

by Jeff Amaral

Combining Drupal core’s view modes and theme regions with a small home-grown module created a new way to lay out node pages.

The resulting module, Region View Modes, places copies of nodes, rendered through specific view modes, into theme regions. Yes, those are the same regions into which you would normally place blocks. There’s no new layout system here. You use the one you already have: your theme.

Once enabled, using the module is pretty easy:

  • Visit the Manage Display page for any content type (e.g. Article)
  • Expand the Custom Display Settings section
  • Check the view mode for one or more theme:region combinations. For example, Bartik theme: Sidebar first region
  • Click Save at the bottom of the page
  • You’ll now see the activated view mode(s) near the top of the page. Click on one.
  • Reorder, hide, or change the settings for any fields
  • View a node of that content type

Here’s a demo:

That’s all you need to know to use the module, but if you’re curious about how it works, read on!...

Categories: Elsewhere

Drupal.org Featured Case Studies: Greenpeace Greenwire global community

Mon, 03/11/2014 - 15:21
Completed Drupal site or project URL: https://greenwire.greenpeace.org/An international community for a greener future

Nalini lives in a small city in India. To save money, all school books and student papers are copied or printed at the local print shop. Nalini is immensely annoyed with her classmates when they choose to print on a single side of paper. If everyone used both sides, she reasons, it would reduce their paper use by half. Nalini sends a message to Greenpeace International through Facebook: "I have an idea for a campaign you should run!"

Greenpeace International is an worldwide independent nonprofit organisation that aims to protect the environment and promote world peace. Originally founded in 1971, the organisation is now active in 44 countries and has 2.8 million supporters. With nearly 2 million Facebook likes and millions of site visitors worldwide, Greenpeace International receives suggestions like Nalini’s thousands of times per year, and because they simply can’t take on every new campaign idea, they wanted to find a way to empower its supporters to run their own campaigns, in their own communities.

In addition, Greenpeace International already had an active volunteer base of 20,000 volunteers, organised in about 400 local groups - each local group, or national volunteer network, had it’s own management and communication tools - a true global volunteering ‘database’ was non-existent, with the data instead spread across lots of individual spreadsheets and google-docs, making it hard to track and measure.

Challenges like these spurred Greenpeace International to create Greenpeace Greenwire, its own online community for employees and volunteers. It’s a meeting place where people can connect with other volunteers, activists and groups working on environmental campaigns in their country. When Greenpeace Greenwire rolls out to more offices, it will allow international connections too.

As well as helping activists find and participate in Greenpeace-led volunteer groups and events, Greenpeace Greenwire lets users create their own events and organize their own activities. Users can start groups, host events, run campaigns, share photos and videos, and write blogs.

Greenpeace Greenwire is a unique project in that it serves a worldwide community - so it needs to be able to scale up to hundreds of thousands of global users - but it also serves each element of that community’s specific set of needs. Flexibility is another key element of the project: allowing users to have different roles in different domains for national and regional offices, and also allowing for flexibility regarding which languages each user could choose. It was also crucial that each user feel comfortable providing their personal data in order to take full advantage of the Greenpeace Greenwire community, but on the other hand, the data must be kept secure and limited only to certain authorized users.

Key modules/theme/distribution used: Domain AccessOrganic groupsSearch APIUniversally Unique IDentifierContextEntity referenceMessageMessage SubscribeLanguage fieldMediaCDNEntity cacheSimpleTest FixtureUser RelationshipsViewsAutomated LogoutOrganizations involved: GoalGorillaTeam members: jaapjanbramtenhovejochemvnstefanotabarellironaldtebrakekevinmuller7gipsy
Categories: Elsewhere

Jonathan Brown: Drupal / Bitcoin BIP 70 / PKI certificates

Mon, 03/11/2014 - 15:00

Previously: Update on Drupal / Bitcoin Payment Protocol (BIP 70) integration

BIP 70 provides a mechanism so that a customer can be sure that they are sending a Bitcoin payment to the correct place. Before BIP 70, the customer would simply be presented with a Bitcoin address to send the amount to. This address could potentially be tampered with so the funds get sent to someone else. It is also not very user-friendly to be sending money to a random collection of letters and numbers.

Now public key infrastructure (PKI) is used to present the customer with cryptographic proof that they are making the correct payment. The payment information that the Bitcoin wallet receives is supplied with a certificate and is digitally signed. The wallet can then present a "human-readable, secure payment destination" to the customer, i.e. the name of the company or a verified email address.

This functionality is now implemented in Coin Tools.

To start using it you need to obtain a certificate. The easiest way to do this is to create a free account at StartSSL. Once they have verified that you own your email address they will put a certificate to this effect into your web browser.

You need to extract this certificate (and private key). Here is how to do it using Firefox, but other browsers are similar. First you need to view your certificates.

Then backup the certificate for your email address provided by StartCom Ltd.

Make sure you save the file with .p12 extension, i.e. jbrown@bluedroplet.com.p12 - P12 is an "archive file format for storing cryptographic objects like private keys and certificates." You will be prompted for a password to encrypt this file.

Next you need to extract your certificate and public key from this file like so:

openssl pkcs12 -in jbrown@bluedroplet.com.p12 -clcerts -nokeys -out publicCert.pem
openssl pkcs12 -in jbrown@bluedroplet.com.p12 -nocerts -out privateKey.pem

Each of these commands will require you to enter the password you encrypted the P12 file with. When extracting the private key you must provide a passphrase it should be encrypted with.

Next you need to add the certificate to your payment type (or create a new one). With the latest version of Coin Tools 8.x-1.x there are additional fields on the payment type form for this. Paste the contents of publicCert.pem into the "Certificate" field.

And paste the contents of privateKey.pem into the "Private key" field. Select "Private key is encrypted" and enter the passphrase you encrypted it with.

When making a payment, the customer's wallet will now display the certificate's Common Name. In this case it is a verified email address.

Categories: Elsewhere

Pages