Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 15 min 15 sec ago

Drupal core announcements: Drupal core critical issues sprint in Princeton, Jan. 29 to Feb. 1

Wed, 07/01/2015 - 04:24
Start:  2015-01-29 (All day) - 2015-02-01 (All day) America/New_York Sprint Organizers:  pwolanin davidhernandez

Timed to coincide with the 4th DrupalCamp NJ and focusing on issues that were not addressed at the recent sprint in Ghent, Belgium.

The focus of this sprint will be resolving critical issues around menu, menu link, and routing issues in Drupal 8.

Dates: Wednesday, January 29 through Sunday, February 1
Location: Princeton University in Princeton, NJ. (See the camp website for details.)
Travel: From Newark Airport (EWR), a good option is the Newark Airport to Princeton Junction train.

Confirmed attendees for this area of focus include pwolanin, dawehner, kgoel, and mpdonadio. Additional attendees may include xjm, Wim Leers, effulgentsia, and beejeebus.

Most of the travel expenses for attendees to work on menu, menu link, and routing issues are being paid for by a grant from the new Drupal Association Drupal 8 Accelerate program.

Additionally, local participants plan to work on core issues related to finishing the "Classy" theme in core so that the base "Stark" theme lives up to its name and serves as a true blank slate of HTML.

We only have limited additional space available, so please contact pwolanin if you'd like to participate in the sprint. Everyone is welcome attend the camp (while tickets last!) and the Drupal mentoring and collaboration day on Feb 1.

Many of the expected attendees participated in person or remote at this past summer's Drupal 8 at the Jersey Shore sprint.

AttachmentSize jerseyshore-gallery1.jpg162.94 KB
Categories: Elsewhere

Capgemini Engineering: Drupal 8 in 2 steps

Wed, 07/01/2015 - 01:00

Drupal 8 is the latest version of Drupal, a modern, PHP 5.4-boasting, REST-capable, object-oriented powerhouse. The concepts are still the same as the previous versions but the approach is now different. Drupal 8 comes with a modern Object Oriented Programming (OOP) approach to most parts of the system thanks to the use of the Symfony2 framework.

I took part in the Drupalcon in Amsterdam and I enjoyed a number of really interesting talks about Drupal 8, among those ‘Drupal 8: The Crash Course’ realized and presented by Larry Garfield. In this post the idea is to recap few key points of his talk as I think they are important to fully understand the basics of this new Drupal version. In case you are interested you can also watch the full talk.

How do I define a module?

In Drupal 8 to define a module we need only a YAML (.info.yml) file:


name: D8 Test Module description: D8 Test Module type: module core: 8.x package: Custom

In Drupal 8 the .module file is not required anymore, so with only the .info.yml file the module is ready to be enabled.

How do I make a page?

Start creating a controller extending the ControllerBase class and return the output of the page:


namespace Drupal\d8_example_module\Controller; use Drupal\Core\Controller\ControllerBase; class D8ExampleModuleController extends ControllerBase { public function test_page($from, $to) { $message = $this->t('%from to %to', [ '%from' => $from, '%to' => $to, ]); return $message; } }

Once this is done, within the .routing.yml file we can define the path, the content, the title and the permissions:


d8_example_module.test_page: path: '/test-page/{from}/{to}' defaults: _content: 'Drupal\d8_example_module\Controller\D8ExampleModuleController::test_page' _title: 'Test Page!' requirements: _permission: 'access content' How do I make content themeable?

We still have the hook_theme() function to define our theme:


/** * Implements hook_theme(). */ function d8_example_module_theme() { $theme['d8_example_module_page_theme'] = [ 'variables' => ['from' => NULL, 'to' => NULL], 'template' => 'd8-theme-page', ]; return $theme; }

For the template page Drupal 8 uses Twig, a third-party template language used by many PHP projects. For more info about Twig have a look at Twig in Drupal 8. One of the cool parts of Twig is that we can do string translation directly in the template file:


<section> {% trans %} <strong>{{ from }}</strong> to <em>{{ to }}</em> {% endtrans %} </section>

And then we assign the theme to the page:


namespace Drupal\d8_example_module\Controller; use Drupal\Core\Controller\ControllerBase; class D8ExampleModuleController extends ControllerBase { public function test_page($from, $to) { return [ '#theme' => 'd8_example_module_page_theme', '#from' => $from, '#to' => $to, ]; } } How do I define a variable?

Drupal 8 has a whole new configuration system that uses human-readable YAML (.yml) text files to store configuration items. For more info have a look at Managing configuration in Drupal 8.

We define variables in config/install/*.settings.yml:


default_count: 3

The variables will be stored in the database during the installation of the module. We define the schema for the variables in config/schema/*.settings.yml:


d8_example_module.settings: type: mapping label: 'D8 Example Module settings' mapping: default_count: type: integer label: 'Default count' How do I make a form?

To create a form we extend a ConfigFormBase class:


namespace Drupal\d8_example_module\Form; use Drupal\Core\Form\ConfigFormBase; use Drupal\Core\Form\FormStateInterface; class TestForm extends ConfigFormBase { public function getFormId() { return 'test_form'; } public function buildForm(array $form, FormStateInterface $form_state) { $config = $this->config('d8_example_module.settings'); $form['default_count'] = [ '#type' => 'number', '#title' => $this->t('Default count'), '#default_value' => $config->get('default_count'), ]; return parent::buildForm($form, $form_state); } public function submitForm(array &$form, FormStateInterface $form_state) { parent::submitForm($form, $form_state); $config = $this->config('d8_example_module.settings'); $config->set('default_count', $form_state->getValue('default_count')); $config->save(); } }

Then within the .routing.yml file we can define the path, the content, the title and the permissions:


d8_example_module.test_form: path: /admin/config/system/test-form defaults: _form: 'Drupal\d8_example_module\Form\TestForm' _title: 'Test Form' requirements: _permission: 'configure_form'

We use another YAML file (.permissions.yml) to define permissions:


'configure_form': title: 'Access to Test Form' description: 'Set the Default Count variable'

We also use another YAML file ( to define menu links:


d8_example_module.test_form: title: 'Test Form' description: 'Set the Default Count variable' route_name: d8_example_module.test_form parent: system.admin_config_system How do I make a block?

To create a block we extend a ConfigFormBase class:


namespace Drupal\d8_example_module\Plugin\Block; use Drupal\Core\Block\BlockBase; /** * Test Block. * * @Block( * id = "test_block", * admin_label = @Translation("Test Block"), * category = @Translation("System") * ) */ class TestBlock extends BlockBase { public function build() { return [ '#markup' => $this->t('Block content...'), ]; } }

In this way the block is ready to be configured in the CMS (/admin/structure/block). Here is an example of a more complex block:

namespace Drupal\d8_example_module\Plugin\Block; use Drupal\Core\Block\BlockBase; use Drupal\Core\Form\FormStateInterface; /** * Test Block. * * @Block( * id = "test_block", * admin_label = @Translation("Test Block"), * category = @Translation("System") * ) */ class TestBlock extends BlockBase { public function defaultConfiguration() { return ['enabled' => 1]; } public function blockForm($form, FormStateInterface $form_state) { $form['enabled'] = [ '#type' => 'checkbox', '#title' => $this->t('Configuration enabled'), '#default_value' => $this->configuration['enabled'], ]; return $form; } public function blockSubmit($form, FormStateInterface $form_state) { $this->configuration['enabled'] = (bool)$form_state->getValue('enabled'); } public function build() { if ($this->configuration['enabled']) { $message = $this->t('Configuration enabled'); } else { $message = $this->t('Configuration disabled'); } return [ '#markup' => $message, ]; } } Structure of a module

The structure of a module should look like the example module d8_example_module:

d8_example_module | |- config | |- install | |- d8_example_module.setting.yaml | |- schema | |- d8_example_module.settings.yaml | |- src | |- Controller | |- D8ExampleModuleController.php | |- Form | |- TestForm.php | |- Plugin | |- Block | |- TestBlock.php | |- templates | |- d8-theme-page.html.twig | |- | |- | |- d8_example_module.module | |- d8_example_module.permissions.yml | |- d8_example_module.routing.yml

Drupal 8 in 2 steps: Extend a base Class or implement an Interface and tell Drupal about it.

Download the example module

Drupal 8 in 2 steps was originally published by Capgemini at Capgemini on January 07, 2015.

Categories: Elsewhere

PreviousNext: Drupal Testing Roadmap

Tue, 06/01/2015 - 23:19

Recently the patch to bring Mink based testing to drupal core went green. As result of that Lee Rowlands (@larowlan), Nick Schuch (@wesome1989), Adam Hoenich (@djphenaproxima), and myself (@grom358) had a discussion to create a roadmap for improving testing in Drupal core. Here is what we discussed.

Categories: Elsewhere

Mediacurrent: Introducing the Mediacurrent Contrib Committee

Tue, 06/01/2015 - 22:21

After Mediacurrent's excellent retreat in October 2014 it was decided to set up some internal committees to help organize various company initiatives. Several of these committees were fairly straight forward - marketing, training, porting our corporate site to D8, etc, but I felt that one had been overlooked - a committee for organizing our contrib efforts.

Categories: Elsewhere

Drupal Watchdog: PHP and JavaScript Closures

Tue, 06/01/2015 - 22:17

PHP closures are pretty simple as they are barely more than syntactic sugar over the following:

class Something { function __construct($x) { $this->x = $x; } function __invoke($y) { extract(get_object_vars($this)); // Your closure here. } }


function something ($y) use ($x) { // Your closure here. }

So closures are objects with a small difference: they are automatically constructed and once constructed they can not be changed and the only thing you can do with them is call them. Now it should be easy to see how variables work: variables given in use() are copied to properties on the object. If $x is an object itself then of course only its handler is copied so changing from inside the closure affects it everywhere else, exactly like how objects work in any other operation. All this is quite consistent on how PHP works and relatively simple to understand.

function foo() { $x = 1; $y = function() use (&$x) { $x++; print "in $x\n"; }; $y(); print "$x\n"; return $y; } $func = foo(); $func(); print "$x\n";

JavaScript is just a little different. First of all, there is no explicit import, every variable from the parent scope is imported. Second, since everything is an object, changing these variables affects the variables in the parent scope.

function foo() { var x = 1; var y = function() { x++; console.log('in' + x);} y(); console.log(x); return y; } func = foo(); func(); console.log(x); Flow Control

In both languages returning from a closure will simply return to the caller. If the closure is called in a loop then the loop will continue. Short of throwing an exception the closure can’t stop such a loop. See Smalltalk for an example of a language where this is different. Obviously, Common Lisp can do both kinds of returns and the syntax is succinct and easy to understand. Obviously again, Ruby can do both and the syntax is extremely obscure.

About $this / this

Since PHP 5.4, you can use $this in closure. Just imagine that one is passed in via use() and everything will be fine. So $this always means the object it is defined in even if the closure is passed to another method on another object. If necessary then a new closure can be created with a new $this variable: Closure::bind($closure, $newthis) or $closure->bindTo($newthis):

class foo { protected $x = 1; function bar() { return function() { $this->x++; print "$this->x\n";}; } } $func = (new foo)->bar(); $func(); class bar { protected $x = 10; } $func2 = $func->bindTo(new bar, "bar"); // "bar" allows the closure to access protected things $func2();

JavaScript this means the defining scope however it can be changed when calling the closures via the call or apply methods of the closure. This doesn't have a PHP equivalent. Your favorite framework or native DOM handling will often do this for you. each in jQuery sets this to the current object, event handlers will get the current event in this etc. ES5.1 in 2011 introduced the bind method on function objects which behaves exactly like bindTo in PHP: something.bind(newThis) returns a new closure with this being set to newThis. Examples:

function foo() { x = 1; var y = function() { this.x++; console.log(this.x);} y(); return y; } var func = foo(); func(); var func = function() { this.x++; console.log(this.x);}{x:1}); o = {x:10}; var func2 = func.bindTo(o); func2(); Tags:  PHP JavaScript Closures
Categories: Elsewhere

Drupal core announcements: Ghent critical issue sprint recap

Tue, 06/01/2015 - 22:08

Last month, 13 sprinters gathered in Ghent, Belgium for a very focused sprint designed to accelerate work on issues blocking the release of Drupal 8. The sprint was a great burst of momentum for the core critical queue -- we went from 115 critical issues at the start of the sprint to only 81 as of today. That means we have 30% fewer critical issues than we did a month ago.

During the 5-day sprint, we worked on an impressive 51 critical issues, 28 of which are already fixed. Of particular note are the 18 upgrade path blockers that we moved forward (that's 70% of the issues blocking a beta-to-beta upgrade path during that time).

Sprint goals: Accomplished!

Before the sprint, we set some goals for the progress we wanted to make on upgrade path blockers for the Entity Field API, Configuration system, and Views. Here's how we did on each of these goals:

Views data structure and Entity Field API integration

We decoupled Views' entity field data from the SQL table structure by storing entity field information in the view configuration. This will make it possible for Views to detect when the entity field schema has changed and respond to the changes (as well as allowing better support for non-SQL databases). We also defined the entity schema changes that Views will need to support, and work is underway to support them.

Content and configuration dependencies in Views

We added content and configuration dependencies to Views so that Views that use entity display modes, field formatters, user roles, and so on can be safely deployed. We also discussed how to store deployable references to entities (for example, the taxonomy term displayed at the top of taxonomy/term/* listings) based on the shared needs of Views and Entity Reference. A patch to implement the proposed API in Views is nearly ready.

Global settings.php overrides

We had a fruitful discussion that clarified the problem space and culminated in splitting the issue into two steps. We retitled and resummarized the original issue into the second step, and began work on the first step. While getting an initial patch for the first step to pass tests, we uncovered several blocker issues, each of which has now been committed. The patch for this issue is now up for review.

Configuration schema

All hidden configuration schema issues are now fixed and will not regress, because all tests now have strict schema checking enabled by default!
To help people get started with config schemas, Gábor Hojtsy also created a very handy cheat sheet that provides the most crucial information at a glance.

Data integrity on module uninstallation

The two critical bugs in this problem space are now fixed:

To implement both of the above, we created a new ModuleUninstallValidatorInterface. We also have a non-critical issue to better integrate those validators when a module is being uninstalled as part of a configuration import.

NOT NULL constraints for entity base fields

Thanks to fast collaboration between plach, amateescu, yched, and fago (which was greatly assisted by having them all together in-person), a patch that fixes the fatal error bug has now been committed. This required resolving some trickiness with entity reference fields, whose target_id property is simultaneously required but not known while in the process of referencing a not-yet-saved entity. The solution results in a more semantically correct API and better delineation of responsibilities between field types, field definitions, and storage handlers for identifying and implementing required-ness.

The UN of Chocolate

We worked hard at the sprint, but also managed to fit in some international chocolate comparisons, with Swiss, Hungarian, and Belgian sweets to power all that coding. Contributor pfrenssen also pledged not to shave until 8.0.0 (1 cm of beard per beta?), and Berdir shared just how brimming with criticals his issue tracker became. We even learned a bit about the history of Ghent, thanks to swentel and his father-in-law.


The sprint was sponsored by the Drupal Association and Wunderkraut.

The following organizations also contributed their employees' time to participate in the sprint:

Finally, thanks to all the sprinters: alexpott, amateescu, Berdir, bircher, dawehner, fago, Gábor Hojtsy, pfrenssen, plach, swentel, Wim Leers, xjm, and yched!

What's next?

With the record-breaking productivity of our sprint, we know that more sprints like these will help get Drupal 8 done. The Drupal Association's D8 Accelerate progam will include more critical issue sprints in 2015. Watch for an upcoming sprint on menu and routing criticals at DrupalCamp New Jersey later this month!

Categories: Elsewhere

Marzee Labs: Blueprinting Drupal projects

Tue, 06/01/2015 - 20:00

Planning the structure of a Drupal project is important. At Marzee Labs, we've developed some pretty robust methodologies over time to approach new Drupal projects, and in this post we'll outline some of these tools and processes that help us get off the ground in no time. While some of the topics are probably familiar (Drupal makefiles, installation profiles and such) you might learn some new tips and tricks to make your next Drupal project just that tiny bit more automated and run smooth.

The blueprint of any Drupal project: the makefile

Any project we start has to have a makefile. Full stop. Requiring that every module, library or theme we use - be it from, github, or any other source - is documented in a single file, is a great way to quickly get the gist of any drupal project.

Even though you might want to version your contributed modules (more on this below), the Drupal makefile should form the backbone of your website.

As an example, check out the makefiles of our MZ profile, our boilerplate profile that can be used to kickstart a new project. For a Drupal profile that can be contributed and packaged on, we typically have 3 different Makefiles, but now we’re only interested in mz.make.

Here are the instructions to make the link module.

projects[link][version] = 1.3 projects[link][subdir] = "contrib"

Everyone inspecting the site running this profile now knows that you are using the 1.3 version of the Link module.

Need to patch the link module because you encountered a bug or missing functionality? Sure thing. First we scan the issue queue for patches. An example is this issue, with a working patch. We add this to our makefile, with a one-liner comment and a link to the issue on d.o.

projects[link][version] = 1.3 projects[link][subdir] = "contrib" ; Provide the original_url when loading the field. ; @see projects[link][patch][] = ""

And we rebuild our project to test the patch in our Drupal sandbox, passing --projects=link (and also --no-core since we don’t want to rebuild Drupal core)

drush make profiles/mz/mz.make --projects=link --no-core .

Or we download the nifty Drush Patchfile to apply patches directly and work with a patch file (our makefile, in this case).

If you want to use the latest development version of a module, you can also do that. If you do however, always specify the revision hash as well (you find it in the commit log), so you make sure you’re working with that specific development release that you tested.

projects[link][version] = 1.x-dev projects[link][subdir] = "contrib" projects[link][revision] = 7dc306c

Feel the power of this? You can quickly evaluate community contributed patches, roll your own (and contribute them as a Gist if they don’t fit on, and not be dependent anymore on the module maintainers to publish that new release.

Since you also document every patch used, you’re making this knowledge available to the other developers in the team, to the reviewer of your Pull Request (if you are using the github branching model), or generally as part of the Git history of your project. You can often revisit your makefile to remove patches if they’ve been rolled out in a new release, and update your modules. Make this a habit and it will pay off eventually.

Bundling using profiles

All your custom code and modules, themes and libraries to be installed should be bundled as an installation profile, so your site can be installed over and over.

If you haven’t started organizing your sites as Drupal profiles, you probably should. Have a look at our boilerplate MZ profile. We use it to bundle our favourite contributed modules, but it also has some custom features and part of our common worfklows we find often useful. Other examples of great Drupal profiles are Commerce Kickstart or Drupal Commons.

Organizing your code in a git repository

It’s time to dive in the organization of your git repository (we love GitHub). If you’ve followed along so far, contributed code is documented in your makefile, while your custom features and code lives in your profile. It would be enough to version these, and that is the recommended way if you want to package your code as a profile or a base profile upon which to build new sites.

However, most of the time, you will also need to deploy off this repository directly, so we suggest that you store all your code - including Drupal core & contrib - in the git repository. Your directory structure could look like

profiles/mz/modules/contrib profiles/mz/modules/custom profiles/mz/modules/features profiles/mz/libraries profiles/mz/themes ... sites/default/settings.php sites/default/ sites/default/settings.test.php sites/default/ ... index.php ...

We also store settings.php in the git repository, and include an if statement to load the right settings.phpdepending on the environment that is available.

Another advantage of versioning environment-dependent settings is that you can force certain variables to be set in code, e.g. for production you might want to add

// Caching settings $conf['page_cache_without_database'] = TRUE; $conf['page_cache_invoke_hooks'] = FALSE;

to your, making all these settings directly available in git and thus for review by your peers, and it avoids having to wonder what setting is active on which environment

Finally, create a settings.local.php file that is loaded from settings.php, with your local database settings.

// For local development if (file_exists('./sites/default/settings.local.php')) { include_once('./sites/default/settings.local.php'); } What’s next?

Now that we have given an overview of our favourite project architecture in Drupal (makefiles, profiles, and github), some of the next topics we’d like to talk about our setting up a continuous integration pipeline (using Travis CI), writing a couple of Behat tests to assert your site works fine, and reviewing our worfklows with Github (pull requests, issues, releases).

Did you miss our “Coding as a Team” series? Check out pt.1: automation workflow using Phing, pt. 2: using content fixtures and pt. 3: code workflow.

Featured image credit: brianbutko / Flickr

Categories: Elsewhere

Drupal core announcements: This Month in Drupal Documentation - December 2014

Tue, 06/01/2015 - 17:46

Here's an update from the Documentation Working Group (DocWG) on what has been happening in Drupal Documentation in the last month or so. Sorry... because this is posted in the Core group as well as Documentation, comments are disabled.

If you have comments or suggestions, please see the DocWG home page for how to contact us. Thanks!

Thanks for contributing!

Since November 28, (our previous TMIDD post), 232 contributors have made 733 total documentation page revisions, including 8 people that made more than 20 edits (lolandese, Francewhoa, webchick, kreynen, YesCT, Pierre.Vriens, Wim Leers, and PsyCode) -- thanks everyone! Most of these people are seasoned Drupal contributors, but PsyCode is a Google Code-In participant who has been editing pages. That's great -- we love it when our old friends come back to help, and when new people get involved!

In addition, there were many many commits to Drupal Core and contributed projects that improved documentation -- these are hard to count, because many commits combine code and documentation -- but they are greatly appreciated too!

Documentation Priorities

The Current documentation priorities page is always a good place to look to figure out what to work on, and has been updated recently.

Of special note: We're trying to get the Help pages inside Drupal 8 updated -- check the priorities page and events section below on this page for details.

If you're new to contributing to documentation, these projects may seem a bit overwhelming -- so why not try out a New contributor task to get started?

Upcoming Events Report from the Working Group

The Working Group meets monthly via Google Hangouts, and our next meeting is January 14. Contact Boris if you'd like to join the meeting. We're currently discussing how we and the community can address several big problems:

  • The lack of documentation for Drupal in languages other than English.
  • The difficulty of locating documentation that answers specific Drupal questions.
  • The overwhelming size of Drupal documentation for newcomers (not knowing where to start).
Categories: Elsewhere

Blink Reaction: Getting up and VMing

Tue, 06/01/2015 - 17:32

Last time we overviewed virtualization and its advantages for Drupal developing. It was all theory stuff, so I’m sure you’re itching to actually get a VM going. Let’s get started.

Categories: Elsewhere

Gábor Hojtsy: 2014 in review from a multilingual Drupal perspective

Tue, 06/01/2015 - 15:30

Whew! 2014 was a fantastic year for the Drupal multilingual team. We had some great events with huge sprints, including but not limited to: Global Sprint Weekend, the amazing Drupal Dev Days Europe, NYC Camp, DrupalCon Austin, DrupalCon Amsterdam and BADCamp.

A fun fact about people on the multilingual team is that even though we usually turn out in big numbers at sprints, there are numerous great mentors among us, so we don't work on code that much at mentored sprints. We do a great job helping people get started and move into more serious core work though. Our most famous mentee this past year is 2014th Drupal 8 core contributor Holly Ross, Executive Director of the Drupal Association who contributed her first and second core patches fixing multilingual issues.

Categories: Elsewhere

Conocimiento Plus: Drupal 8 Web Services and Context Core (WSCCI) Initiative

Tue, 06/01/2015 - 13:07
Web services and mobile are more important than ever, and with that comes the need to have more flexible page and layout capabilities – Dries Buytaert Introduction The future is a world where content management systems need to output data to many more devices and integrate with more and more systems and services. Drupal 7 […]
Categories: Elsewhere

Evolving Web: Iterating over trees in PHP

Tue, 06/01/2015 - 13:00

As a good Drupal developer, one of your New Year's resolutions should be to learn more PHP features. Today, we'll talk about iterating over tree-structured data using the awkwardly-named class RecursiveIteratorIterator.

read more
Categories: Elsewhere

IXIS: Looking forward to a Drupaltastic 2015

Tue, 06/01/2015 - 12:20

It was an exciting and busy year here at Ixis in 2014 as we continued to build our portfolio of Drupal clients

Highlights have included celebrating our tenth birthday and building on and growing the team’s expertise which has allowed the company to win more clients across a variety of sectors. We also celebrated one of our best financial quarter since Ixis was founded in 2004. 

read more

Categories: Elsewhere

Blair Wadman: How do you create a single on/off checkbox field?

Tue, 06/01/2015 - 10:29

Simple on/off checkbox fields where you want the user to select or deselect a checkbox are a common requirement. Yet it is not so obvious how to create them in Drupal.

On/off checkbox fields are often used to toggle for things like:

Categories: Elsewhere

Drupal Association News: Get Ready for the 2015 Community Elections

Tue, 06/01/2015 - 05:31

During the holidays I met some folks who used to work at other open source projects. One of them asked me, "What's your favorite part of your job?" Lucky for me, I have a lot of great things to choose from, but the thing that always stands out is the global nature of our community. All the customs, cultures, and values are tough to navigate, but I love learning about the variety of perspectives you all bring to the table. I sincerely believe that this diversity of experince makes our community that much stronger.

That diversity is also why we have two At-Large positions on the Association Board of Directors - positions that are self-nominated and elected by the community. Simply put, the At-large Director position is specifically designed to ensure community representation on the Drupal Association board. If you are interested in helping shape the future of the Drupal Association, we encourage you to read this post and be prepared to nominate yourself between 1 February and 20 February, 2015.

How Do Nominations and Elections Work?

Specifics of the election mechanics were decided through a community-based process in 2012 with participation by dozens of Drupal community members. More details can be found in the proposal that was approved by the Drupal Association board in 2012 and adapted for use this year.

What Does the Drupal Association Board Do?

The Board of Directors of the Drupal Association are responsible for financial oversight and setting the strategic direction of the Drupal Association. New board members will contribute to the strategic direction of the Drupal Association. Board members are advised of, but not responsible for matters related to the day to day operations of the Drupal Association, including program execution, staffing, etc.

Directors are expected to contribute around five hours per month and attend three in-person meetings per year (financial assistance is available if required). You can learn more about what’s expected of board members by reviewing the board member agreement. You can also check out the presentation and summary we shared this summer.

Who can run?

There are no restrictions on who can run, and you don't need anyone to nominate you.

What will I need to do during the elections?

During the elections, members of the Drupal community will ask questions of candidates. They'll post comments on candidate profiles here on and to the public Drupal Association group at We'll also organize at least two all-candidates meetings (which will be announced on the Drupal Association group and blog), where community members and candidates will be able to ask questions and share information. The more you can participate, the more Drupal community members will be able to find out what you would bring to the Drupal Association board.

How Do I Run?

Candidates needed! If you are considering running, please read the entirety of this post, and then be prepared to complete a self-nomination form. This form will be open on 1 February, 2015 through 20 February, 2015 at midnight UTC. You'll be asked for some information about yourself and your interest in the Drupal Association Board. When the nominations close, your candidate profile will be published and available for Drupal community members to browse. Comments will be enabled, so please monitor your candidate profile so you can respond to questions from community members.

Who can vote?

Voting is open to all individuals who have a account by the time nominations open and who have logged in at least once in the past year. These individuals' accounts will be added to the voters list on and they will have access to the voting.

To vote, you will rank candidates in order of your preference (1st, 2nd, 3rd, etc.). The results will be calculated using an "instant runoff" method. For an accessible explanation of how instant runoff vote tabulation works, see videos linked in this discussion.

Elections process

Voting will be held from 9 March, 2015 through 20 March, 2015. During this period, you can review and comment on candidate profiles on and engage all candidates through posting to the Drupal Association group. We'll also be scheduling and announcing two phone-in all candidates meetings, where community members and candidates can ask questions and get to know each other.

Have questions? Please contact Drupal Association Executive Director Holly Ross. Many thanks to nedjo for pioneering this process and documenting it so well last year!

Flickr photo: Kodak Views

Categories: Elsewhere

Nextide Blog: Standalone Drupal 8 script using Guzzle

Mon, 05/01/2015 - 23:24

Drupal 8 will have web services as part of core which will provide native support for all entity types including custom entity types. Drupal 8 will have support for different serialization formats like HAL+JSON, XML and JSON.

A couple good article references:

Categories: Elsewhere

Pivots recommendations: Drupal Recommender API: Roadmap for 2015 and beyond

Mon, 05/01/2015 - 18:54

I have seen slow but steady adoption of the new release of Drupal Recommender API module over the past few weeks after the announcement. This post will explain my plans about future development of Recommender API in order to help the audience make informed decisions. This is also an update to an older post on 2012-2013 roadmap.

I will categorize all my development plans into three tiers.

Read more
Categories: Elsewhere

Lullabot: Lullabot's 2014 Year In Review

Mon, 05/01/2015 - 18:43

Wow! What a Year!

As we throw away the empty champagne bottles and start retraining ourselves to write a different year on our checks, it’s always a good time reflect upon the past year. 2014 was Lullabot’s 9th year in business and it was our biggest year ever. We contributed to projects for MSNBC, Pac-12,, Bravo TV, Saturday Night Live, Tesla Motors, NAMM, CNBC, Hotwire, Harvard University, American Booksellers Association, Intel, Comcast, GE, Qualcomm, and Teach For America, amongst others.

Our project with The Tonight Show Starring Jimmy Fallon won a Creative Arts Emmy for Outstanding Interactive Program.

Next month’s GRAMMY night will mark Lullabot’s 5th year as part of Over the years, we have been responsible for development and site performance. This year, however, Lullabot's design team takes charge of the GRAMMYs' site design and UX. It’s been really rewarding to work with the Recording Academy for so many years on such a high-profile project.

Categories: Elsewhere

Blink Reaction: Virtualizing your Drupal Dev Environment for Cleanliness and Consistency

Mon, 05/01/2015 - 17:52

Too many versions of PHP on your system? MAMP got you down? Can’t find that .ini file? Don’t fret, go Vagrant! Many Drupal developers use a web developer stack such as WAMP, Acquia Dev Desktop, or MAMP to host their projects locally. When working with multiple clients, your hard drive can turn into a dorm room nightmare of multiple copies of PHP, MySQL, and Apache in order to assure compatibility with the client. Instead, simplify and standardize your workflow — and your team’s — by using freely available virtualization tools.

Categories: Elsewhere

Tyler Frankenstein: DrupalCamp Michigan 2015

Mon, 05/01/2015 - 17:43

Let's get together for DrupalCamp Michigan 2015. This year the camp will be hosted at Henry Ford College in Dearborn, MI on Saturday January 31st. Please visit the camp's website for more details:

Tickets are only $15.00, The deadline for session proposals is January 11th, and sessions will be chosen on the 12th. JetBrains will be giving away 3 personal PHPStorm licenses at the camp, so be sure to attend for a chance to win.

We hope to see you there, cheers and happy coding!

Categories: Elsewhere