Planet Drupal

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

Advomatic: Fajitas, Front End Meets Design, and Remembering to Shower: A DrupalCon Recap

Tue, 17/06/2014 - 16:27

Like many of you, the AdvoTeam hit Austin a coupe of weeks ago for DrupalCon 2014. Now that we’ve had some time to digest all the knowledge dropped (pun intended), we’re sharing our favorite DrupalCon takeaways. We’ve even included links to the DrupalCon sessions, so you can share in the joy.


Amanda, Front-End Developer:

Design and front end are figuring out how to fit together. Do designers need to know how to code? Should they really uninstall Photoshop? And while front-enders are benefiting from all the dev work coming down the pipe, we’re a bit overloaded waiting to see what emerges when the dust settles.

Despite our gripes, it is pretty satisfying that our teams now recognize that the front-end is infinitely more complex than it was just a few years ago.

Lastly, I was blown away that the conference attendance was 20% women! For me, that’s an indication that the community is doing something right in terms of attracting women in ways that other softwares don’t. Kudos!

Monica-Lisa, Director of Web Development

Loved the session on running a shop of remote workers. The big takeaways: Be in constant, positive, fun communication with one another. Find the best tools to keep in touch. If you can’t work all the same hours, choose a few hours a day, every day to overlap. Have a lot of trust in your people. And of course, don’t forget to take a shower every once in a while.

Dave, Web Development Technical Manager

This was one of the best DrupalCons I’ve been to. Top of the list of sessions: Adam Edgerton’s talk on scaling a dev shop. This year was also one of the best DriesNotes (keynote by Dries Buytaert, founder and lead developer of Drupal.)

And in past years, I’ve spent a lot of time hanging out with anyone I bumped into. But this year, I spent almost all my time with the Advoteam; going biking and swimming - we even went to Monica’s mom’s house for fajitas one night.

Jim, Senior Web Developer

The Core Sprint was inspiring, because everyone was getting the help they needed while also giving help to others. Everyone knew different things, so as a group, we were all able to share our collective knowledge to get people set up on Drupal 8, review patches, and to commit new ones.

Jack, Front End Developer

Once again, Drupalcon has shown me that it's not safe (or fun) to get comfortable.  The tools we use to make our work go faster and smoother are constantly changing.  What’s all the rage this year will probably be obsolete next year.  Don't fall in love with any one way of doing things.

Front-end development and theming has never felt more "sink or swim", and that's probably a good thing.  However, as things get more and more complicated, the single front-end developer that knows everything becomes more of a mythological creature.  As new worlds of specialization open up, it becomes more important to have new specialists available.

Lastly, it was awesome to get some face time with the Advoteam.  It's good for the remote team's morale, and also nice to be reminded you work with other human beings that have other things to talk about besides technical Drupal talk.

Did you make it to DrupalCon? What sessions did we miss?


Categories: Elsewhere

Drupalize.Me: Drupal 8 Survey Insights

Tue, 17/06/2014 - 15:30

Last month we asked the Drupal community a few questions. We received 243 responses to our survey, and we'd like to share some of the information. While we're not making scientific generalizations from this data, it is an interesting picture of our community nonetheless. A big thank you to everyone who participated in the survey.

Here are 4 things we learned:

Categories: Elsewhere

Open Source Training: Building a Business Directory With Drupal

Tue, 17/06/2014 - 14:43

Over the last couple of weeks, several different OSTraining members have asked me about creating a directory in Drupal.

I'm going to recommend a 4-step process for creating a basic directory.

Using default Drupal, plus the Display Suite and the Search API modules, we can create almost any type of directory.

Categories: Elsewhere

Liran Tal's Enginx: Drupal Performance Tuning for Better Database Utilization – Introduction

Tue, 17/06/2014 - 08:13
This entry is part 1 of 1 in the series Drupal Performance Tuning for Better Database Utilization

Drupal is a great CMS or CMF, whichever your take on it, but it can definitely grow up to be a resources hog with all of those contributed modules implementing hooks to no avail. It is even worse when developers aren’t always performance oriented (or security oriented god save us all) and this can (unknowingly) take it’s toll on your web application performance.

Drupal performance tuning has seen it’s share through many presentation decks, tutorials, and even dedicated books such as PacktPub’s Drupal 6 Performance Tips but it seems to be an always continuing task to get great performance so here are some thoughts on where you should start looking.


Checklist for glancing further into Drupal’s rabbit hole and getting insights on tuning your web application for better performance:

  1. Enable MySQL slow query log to trace all the queries which take a long time (usually >1 is enough, and with later versions of MySQL or compliant databases like Percona or MariaDB you can also specify milliseconds for the slow query log)
  2. Enable MySQL slow query log to also log any queries without indexes
  3. Make sure to review all of those query logs with EXPLAIN to figure out which queries can be better constructed to employ good use of indexes. Where indexes are missing it’s worth reviewing if the database would benefit from modifying existing indexes (and not breaking older queries)
  4. Use percona-toolkit to review out standing queries
  5. Use New Relic’s PHP server side engine which can tune into your web application and provide great analysis on function call time, wall time, and overall execution pipelines. While it’s not a must, I’ve personally experienced it and it’s a great SaaS offering for an immediate solution without having to need to install alternatives like XHProf or Webgrind.


(adsbygoogle = window.adsbygoogle || []).push({});

The post Drupal Performance Tuning for Better Database Utilization – Introduction appeared first on Liran Tal's Enginx.

Categories: Elsewhere

AGLOBALWAY: Drupal to Excel with Views

Mon, 16/06/2014 - 23:06

Every now and then we need to export a bunch of content from our Drupal site into a spreadsheet. This can easily be accomplished through views with modules like Views Excel Export, which allows you to add a new display for your view. Also, you can add it as an attachment to your existing view, creating a button. Click, and you download a spreadsheet (or CSV, there are options!) just like that. Modules like this one work really well if your data structure is straightforward, and there is no need to format your spreadsheet. What happens if you want it to look a certain way, add borders to columns or rows? What if your view is referencing Entities? Suddenly Views Excel Export doesn't quite cut it anymore. Enter PHP Excel. While this module has no UI to speak of, it does add PHP Excel to your Libraries folder in your Drupal installation. The PHP Excel library gives you a ton of functions that allow you to format an Excel spreadsheet, as well as write to it directly. Let's say we wish to output our "Events" view to Excel. By creating our own custom module, we can call our view programmatically after referencing the PHP Excel library:

function my_custom_spreadsheet_view() {
$view = views_get_view('events');


Rather than calling


, we can use


to find and extract the exact information we want. Assign your data to variables so that you can loop through your Events and write them to Excel in the format you like.

$events = $view--->results;
// start writing to row 5 of your spreadsheet
$rowID = 5;
foreach($events as $event => $e){
// do magic with your data
->setCellValue('A'.$rowID, $data)
->setCellValue('B'.$rowID, $data1)
->setCellValue('C'.$rowID, $data2)
// move to the next row for the next Event

PHP Excel comes with a number of examples, simple and complex. Use these to learn how to format and generate your spreadsheet when you call your custom function.

Tags: drupaldrupal planet
Categories: Elsewhere

Acquia: Search API Drupal 8 Sprint June 2014

Mon, 16/06/2014 - 22:50

During 13th of June until the 15th of June we had a very successful Search API D8 sprint as announced at and at Intracto's site. The sprint was organized with the money but even more valuable than money is time.

Categories: Elsewhere

Acquia: Migrate in 8, DrupalCon post-mortem

Mon, 16/06/2014 - 22:16

At DrupalCon Austin, I led a Core Conversation panel, Status of Migrate in 8, along with chx, ultimike, Ryan Weal, and bdone. The conversation was well-received, and we fielded some good questions. To summarize what we went over, updated for continued developments:

Categories: Elsewhere

Acquia: First patch! Matt Moen and a village of contributors

Mon, 16/06/2014 - 19:23

Every DrupalCon, there's a moment I especially look forward to: the First-Patch "ritual". This time around, a patch written by Matt Moen, Technical Director at Kilpatrick Design, was selected for fast-track testing, approval, and was committed to Drupal 8 core in front of a few hundred of us at the Austin convention center. In this podcast, I talk with Matt about becoming a core contributor; we hear from Angie "webchick" Byron about how it takes a village to commit a patch; and I've included a quick refresher on how version control works with the Gitty Pokey from the DrupalCon Austin pre-keynote. You can see the full patch approval and commit process in the 2nd video embedded on this page.

Categories: Elsewhere

SitePoint PHP Drupal: Building a Drupal 8 Module: Blocks and Forms

Mon, 16/06/2014 - 18:00

In the first installment of this article series on Drupal 8 module development we started with the basics. We’ve seen what files were needed to let Drupal know about our module, how the routing process works and how to create menu links programatically as configuration.

In this tutorial we are going to go a bit further with our sandbox module found in this repository and look at two new important pieces of functionality: blocks and forms. To this end, we will create a custom block that returns some configurable text. After that, we will create a simple form used to print out user submitted values to the screen.

Drupal 8 blocks

A cool new change to the block API in D8 has been a switch to making blocks more prominent, by making them plugins (a brand new concept). What this means is that they are reusable pieces of functionality (under the hood) as you can now create a block in the UI and reuse it across the site - you are no longer limited to using a block only one time.

Let’s go ahead and create a simple block type that prints to the screen Hello World! by default. All we need to work with is one class file located in the src/Plugin/Block folder of our module’s root directory. Let’s call our new block type DemoBlock, and naturally it needs to reside in a file called DemoBlock.php. Inside this file, we can start with the following:

<?php namespace Drupal\demo\Plugin\Block; use Drupal\block\BlockBase; use Drupal\Core\Session\AccountInterface; /** * Provides a 'Demo' block. * * @Block( * id = "demo_block", * admin_label = @Translation("Demo block"), * ) */ class DemoBlock extends BlockBase { /** * {@inheritdoc} */ public function build() { return array( '#markup' => $this->t('Hello World!'), ); } /** * {@inheritdoc} */ public function access(AccountInterface $account) { return $account->hasPermission('access content'); } }

Like with all other class files we start by namespacing our class. Then we use the BlockBase class so that we can extend it, as well as the AccountInterface class so that we can get access to the currently logged in user. Then follows something you definitely have not seen in Drupal 7: annotations.

Continue reading %Building a Drupal 8 Module: Blocks and Forms%

Categories: Elsewhere

Friendly Machine: Quick Tip: Syncing Databases Between Drupal Websites with Backup and Migrate

Mon, 16/06/2014 - 16:48

A common scenario that Drupal developers and site builders run into is the challenge of keeping the database in sync between the dev, testing and production versions of a site. Web hosts like Pantheon (highly recommended) make this a snap, but what if you're using a VPS or some other hosting that doesn't have that functionality? One popular option is to use Drush, but that isn't a good fit for everyone.

Backup and Migrate (BaM) can be a great tool for helping with this sort of problem. In this post we'll talk about using BaM for this task and include a very handy companion service that makes things even easier. What I often see with site builders who are using Backup and Migrate is the manual downloading of backup files and then doing a manual restore from the downloaded file.

A great alternative to that process is setting up an Amazon S3 bucket (cloud storage) where you can directly place your backups from Backup and Migrate. Once each version of the site has the S3 bucket set up, keeping the database in sync becomes a snap.

Setting up an account with Amazon Web Services is free - you get 5 GB of Amazon S3 storage, 20,000 get requests, 2,000 put requests, and 15GB of data transfer each month for one year with the free account. If you start to use the service more heavily, you pay for what you use, but for most dev scenarios, you probably won't incur fees.

Amazon has a nice tutorial to walk you through the process of getting started with the service.

Once you have an account with AWS, you head back to Backup and Migrate on your Drupal site - /admin/config/system/backup_migrate. Go to the Destinations tab and you'll see an 'Add Destination' link as in the image below. Click that link and in the list on the next page, select 'Amazon S3 Bucket' as the destination.

You'll most likely be prompted to add a PHP library - simply follow the link provided in the prompt and download the library to the 'libraries' folder of your site. It's really easy, so don't be put off.

The next step is to fill in the form you see below with the information from your S3 bucket.

That's pretty much all there is to it. Make sure everything is working by running a manual backup to the new S3 bucket destination. A good next step is to configure scheduled backups on the target machine so you can periodically restore a fresh copy on your other environment(s).

To restore your database from the S3 bucket in the UI, you just go to the 'Destination' you have configured in Backup and Migrate for the bucket and click the 'restore' link next to the copy you want to use. A nice twist is using Drush to help with some of this.

If you're brand new to Drush but would like to learn, here's a good place to start. If you'd just like to know how to use Drush and Backup and Migrate together, here's a good tutorial on that topic.

If you have any comments on this post, you may politely leave them below.

Categories: Elsewhere

LightSky: CKEditor in Core and Why that is a Big Deal

Mon, 16/06/2014 - 16:37

I can remember back to the first time I installed Drupal.  I ran the install through CPanel (I know right, don’t hold it against me) and bingo there was my brand new website… or something like that.  Drupal 6 just didn’t offer me out of the box much to be excited about, and while Drupal 7 was certainly an improvement it still didn’t offer much more than a platform to simply get started with what I had just found out was going to be a long process.  I was building a site for my newly formed curling club, and I just learned that this was going to be a bit of work to get it where it needed to be, and even then I started to fear that I may not be able to teach anyone else how to update the site, which would mean even more work. 

I fought the urge, the strong urge to use a platform that was a little more, how do you say, out of the box ready.  But here we are several years later and I am glad I stuck with Drupal, the curling club is as well.  The functionality that I have been able to add over the years and the payment and registration integration just wouldn’t be quite possible under some of the other available systems. 

Drupal long took the approach that the core should be very lightweight, compact, and should allow site builders the flexibility to make decisions on what to use in their site.  I applaud this as a bloated core is just as bad as one that doesn’t accomplish the intended task, but usability has to be taken into mind.  As the user base for Drupal has grown though the need for a higher level of functionality to come out of the box has come as well. 

Drupal’s somewhat philosophical shift to adding some key features to core, like CKEditor, is a huge step in the right direction.  Now Drupal is a step closer after install to being ready to run, and positions itself to be used by more site builders and developers by decreasing the amount of work they will have to get a simple site up and running.  This is an indicator that you don’t have to load down core to the point where it interferes with enterprise level projects to concede a bit to the smaller players.  Bravo Drupal!

What features do you seem to install on every Drupal site.

For more tips like these, follow us on Twitter, LinkedIn, or Google+. You can also contact us directly or request a consultation

Categories: Elsewhere

Appnovation Technologies: 5 Best Drupal Starter Themes

Mon, 16/06/2014 - 16:16

Learning and working on a Drupal starter theme can not only speed up workflows significantly for 'themers', but also enable you to focus solely on building custom layouts without having to worry about browser incompatibilities an

var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});
Categories: Elsewhere

Drupal Watchdog: Drupal 7 Content Types from Code

Mon, 16/06/2014 - 16:04

One key feature of Drupal 7 that makes it one of the most flexible content management frameworks available, is the ability for administrators to build new types of content – beyond the two built into a standard installation of Drupal 7, “Article” and “Basic page”. Content types are typically created in the administration section of the website, clicking through a series of pages, and manually entering information such as the names of new fields. This is sufficient for most situations, but can become tedious and error-prone. There are several advantages to automating this process: You could define new content types for your own use without having to step through all the screens and mouse clicks. You could define them for use by other people and on other websites without having to document the steps. It would expand your module-writing capabilities, since oftentimes module functionality calls for one or more custom content types. On a related note, this can be valuable in setting up testing harnesses (e.g., in test/modules/node/node.test, the class NodeWebTestCase).

Fortunately, Drupal allows for the programmatic building of content types, using its Fields application programming interface (API). We have already noted two useful examples, "Article" and "Basic page", which we can build upon.

Consult the Core

During a standard installation, Drupal runs the PHP code in the file profiles/standard/standard.install, which consists of a single function, standard_install(). It includes the code to create the two aforesaid content types:

Categories: Elsewhere

Web Omelette: Drupal 8 Dependency Injection, Service Container And All That Jazz

Mon, 16/06/2014 - 09:07

With the move from a mostly procedural to a mostly OOP based architecture in Drupal 8, many Drupal developers have been introduced to new concepts we don't fully understand. I myself was terrified of notions such as dependency injection and service container, making me worry about the future of my Drupal development.

So I took it to Symfony (from where many components have been borrowed) and then Drupal 8 alpha releases and turns out it's not a big deal. All you need in order to understand them is to know basic OOP principles. Check out Larry Garfield's timeless introductory article to Object Oriented Programming on Drupal Watchdog for a good start.

In this article I am going to talk a bit about what dependency injection is and why one would use a container for managing these dependencies. In Symfony and Drupal 8 this is called a service container (because we refer to these global objects as services). Then, we will take a look at how these are applied in Drupal 8. Briefly, because you don't need much to understand them.

So what is dependency injection?

Take the following simple class:

class Car { protected $engine; public function __construct() { $this->engine = new Engine(); } /* ... */ }

When you instantiate a new class Car you go like this:

$car = new Car();

And now you have an object handler ($car) that has an $engine property containing the handler of another object. But what if this car class needs to work with another engine? You'd have to extend the class and overwrite its constructor for each new car with a different engine. Does that make sense? No.

Now consider the following:

class Car { protected $engine; public function __construct($engine) { $this->engine = $engine; } /* ... */ }

To instantiate an object of this class, you go like this:

$engine = new Engine(); $car = new Car($engine);

Much better. So now if you need to create another car using another engine, you can do so easily without caring about the Car class too much since it is supposedly equipped to work with all the engines in your application.

$turbo = new TurboEngine(); $car2 = new Car($turbo);

And that is dependency injection. The Car class depends on an engine to run (dooh), so we inject one into its constructor which then does what it needs to do. Rather than hardcoding the engine into the Car class which would not make the engine swappable. Such constructor injections are the most common but you'll also find other types such as the setter injection by which we would pass in the engine through a setter method.

So what is this container business?

So far we've seen a very simple class example. But imagine (rightfully) that the Car has many other potentially swappable components (dependencies), like a type of gear shift, breaks or wheels. You have to manually instantiate all these dependent objects just so you can pass them to the one you actually need. This is what the container is for, to do all that for you.

Basically it works like this. You first register with the container your classes and their dependencies. And then at various points of your application, you can access the container and request an instance of a particular class (or service as we call them in Symfony and Drupal 8). The container instantiates an object of that class as well as one of each of its dependencies, then returns you that service object. But what is the difference between services that we usually access through the container and other PHP classes?

A very good definition that makes this distinction comes from the Symfony book:

As a rule, a PHP object is a service if it is used globally in your application. A single Mailer service is used globally to send email messages whereas the many Message objects that it delivers are not services. Similarly, a Product object is not a service, but an object that persists Product objects to a database is a service.

Understanding how the container works under the hood is I believe not crucial for using it. It's enough to know how to register classes and how to access them later. There are multiple ways to register services but in Drupal 8 we use YAML files. In Symfony, you can use directly PHP, YAML or even XML. To know more about how to do this in Drupal 8, check out this documentation page. Accessing the services in Drupal 8, on the other hand, is done in one of two ways: statically and using, yet again, dependency injection.

Statically, it's very simple. We use the global \Drupal namespace to access its service() method that returns the service with the name we pass to it.

$service = \Drupal::service('my service');

This approach is mostly used for when we need a service in our .module files where we are still working with procedural code. If we are in a class (such as a form, controller, entity, etc), we should always inject the service as a dependency to the class. Since I covered it elsewhere and the Drupal documentation mentioned provides a good starting point, I won't go into the exact steps you need to take in order to inject dependent services into your Drupal 8 classes. However, you can check out my introductory series on Drupal 8 module development, on, where I covered the process of creating services and injecting them as dependencies (in the third part).


So there you go. Dependency injection is a very simple concept that has to do with the practice of decoupling functionality between classes. By passing dependencies to objects we can isolate their purpose and easily swap them with others. Additionally, it make is much easier to unit test the classes individually by passing mock objects.

The service container is basically there to manage some classes when things get overwhelming. That is, when the number grows and the number of their dependencies also increases. It keeps track of what a certain service needs before getting instantiated, does it for you and all you have to do is access the container to request that service.

Hope its clear.

var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Categories: Elsewhere frontpage posts: Modernizing Testbot: Drupalcon Austin Update

Sun, 15/06/2014 - 07:08

"Modernizing Testbot" is a Drupal community initiative with the goal of rebuilding's Automated Testing / Continuous Integration infrastructure, leveraging modern practices and tools in order to enhance the capabilities and functionality provided by the platform and better meet the changing needs of the Drupal community. The initiative first took root with the vetting of a potential design and architecture during the DevOps Summit at BADCamp 2013, which then led to the development of a functional Proof of Concept during DevDays Szeged. DrupalCon Austin saw a number of further refinements to the model, and launch of the official project pages/repositories on This post is intended to provide a snapshot of what was accomplished. Project Pages

The week before DrupalCon saw the launch of the 'DrupalCI' project on, which is intended as the umbrella project for related 'Modernizing Testbot' work. The initiative has been broken down into five sub-projects under the same DrupalCI namespace. The initiative is still young, and code in the following repositories is not necessarily ready for use, but this is where you will find things during development and after the platform goes live:

  1. drupalci_drupalorg: Responsible for integration between and the DrupalCI platform
  2. drupalci_jenkins: Responsible for the scripts and configuration files used on the jenkins master/slave servers which serve as the central job dispatcher for the environment
  3. drupalci_testbot: Responsible for the job runners performing the actual work, but also functional as a standalone project for local testing
  4. drupalci_results: Responsible for the long-term archival, storage, and exposure of build artifacts and job results, similar to qa.d.o today
  5. drupalci_puppet: Responsible for the puppet configuration scripts used to build out the various servers which make up the environment.
Development Infrastructure

Also in the weeks leading up to DrupalCon Austin, we set up a full development environment with the help of the Infrastructure Team. This environment has been set up entirely on infrastructure, and is intended to closely mimic that which would be used for a production launch of the platform. A special thanks goes out to nick_shuch (PreviousNext) for his help in setting up the jenkins server and initial drupalci_puppet scripts.

Multiple Environment Support

One of the primary testbot sprint goals for the week was to enhance the proof of concept build, enabling support for testing on multiple database types and php versions. In addition to his contributions as sponsor of the DrupalCon sprints, user jaredsmith (Bluehost) also joined the testbot sprint team; where he started with developing a Docker build which would add support for a Postgres 9.1 test environment to the platform ... and then followed that up with builds for MariaDB 5.5 and 10 as well. With these Docker builds now available in the repository, we are ready to begin integration and testing of these environments with the actual run scripts; and any assistance the community could provide with this task would certainly be welcome.

Initial Integration

While it will be quite some time before the DrupalCI platform is actually integrated with itself, we anticipate the need for some means of triggering tests from a dev site, in order to demonstrate the full end-to-end communications path as envisioned for the final deployment. User Psikik dropped by our table during the Friday sprints in order to express an interest in the project, and looking for some way to chip in. Despite admitting to have never built a drupal module before, Psikik took on the task of developing the initial drupalci_drupalorg implementation, providing the ability to trigger jobs on our remote Jenkins server from a form located on (or, in this case, a D.o dev instance); with his final result ending up committed directly as-is (other than namespace changes) to the drupalci_drupalorg repository.

Test Runner Refinements

Throughout the week, and especially during the Friday/extended sprints, users dasrecht and ricardoamaro (original author of the Szeged proof of concept, sprinting remotely from Portugal) made a number of refinements to the test runner bash scripts; including refactoring to a new directory structure which should better position the project for an expanded set of functionality in the near future. Dasrecht also contributed an initial framework for a future 'drupalci' console command, which will eventually serve as the primary end-user interface for local interaction with the platform.

Jenkins scripts

Also during the Friday sprints, user geerlinguy and I both made progress on the development of jenkins scripts which will be triggered in order to kick off new jobs/test runs.

Where to from here ... What's next?

Starting next week, I intend on establishing a rotating weekly "Modernizing Testbot" call; alternating each week between North/South American and Europe/Asia/Australia-friendly timezones. Progress and updates on the initiative will be shared via the ' Testing Infrastructure' group on, so anyone interested in the ongoing progress of the initiative is encouraged to sign up there. Our immediate priority will be further testing and stablizing the Postgres and MariaDB environment support for local testing purposes, after which we'll turn attention towards the investigation of issue queue/patch workflow improvements which could be supported by the platform.

As always, testing and contributions are welcome; if you would like to get involved, please feel free to contact me via my contact form.

Bonus Points: QA.Drupal.Org "Test Complete" Notifications

While not directly related to the 'Modernizing Testbot' activities, I simply cannot leave without a huge shout out to justafish, who approached me during the extended sprints, asking what it would take to enable json support for qa.d.o test results. After I provided her with an admittedly not-so-helpful answer (i.e. "If someone else was to do the work, I'll deploy it; but it otherwise isn't a priority") and a qa.d.o dev site, she had a working json feed, PIFR patch, and new view definitions completed in no time. This work was deployed live to qa.d.o on Tuesday, so that end users can now access the json view of their test by appending '/json' to the 'view test' URL. This in turn enabled development this week of a chrome extension (also by justafish), which can monitor your tests in progress and notify you as soon as the qa.d.o test run is complete ... a project that I anticipate will very quickly find it's way into the toolset of Drupal core developers everywhere.

Categories: Elsewhere

Károly Négyesi: Reminder

Sun, 15/06/2014 - 00:14

Sticks and stones may break my bones
But words will never harm me.

Categories: Elsewhere

Bluespark Labs: Thinking outside of the Block: Drupal Layout tools in the Real World

Sat, 14/06/2014 - 12:00

 This blog post is an introduction to what will be a multipart series.  Although there is no shortage of posts and discussions of layout solutions for Drupal, there is a lack of a comprehensive overview of the available module options for layouts in Drupal, and we are aiming to remedy that.  We will both outline what the current state of the art is, and discuss what approaches might provide an easier migration path to Drupal 8. In this series, we will draw on our real-world experience building and maintaining sites using each of the major solutions available. We want to present this content in bite-sized chunks, highlighting what you need to know about each system, and discussing how to meet common use cases. 

We have an audience in mind, specifically, Drupal site builders that want to get beyond blocks and regions, and start doing really awesome things with their layouts. This of course, should be without having to ever get into code.

At this point in the Drupal 7 life cycle, there are at least three really solid layout module options available to a site builder.  The three Drupal modules that we will address, with one post per module, are Context, Display Suite, and Panels.  Given that we are focusing this series on site builders, and specifically avoiding solutions that require writing code, we will not get into php templating.  We will also talk about some of the available extra goodies that are out there for panels, such as panels everywhere and panalizer, and wrap up with an overview post that points us forward to Drupal 8, and future proofing your layout choices.

The difficulty that one encounters when embarking on a series like this is the sheer quantity of information that surrounds every level of the topic.  It would not be difficult to come up with a ten part blog series that discussed only panels, in fact the difficulty would lie in keeping it to only ten posts! It can also be really difficult to compare Drupal modules that do similar things, without actually downloading them and learning them all.  Ain't nobody got time for that.  So we've decided to structure the posts as follows:

Part 1. Give as broad an overview as possible of the strengths and weaknesses of the module in question.  Specifically, talk about how easy/difficult it is to get started with, and how flexible/powerful it is with an eye towards meeting more and more complicated use cases.

Part 2. Introduce the module, with some screenshots of how the UI works.  We will use two specific examples of common client requirements, (the same examples for each module), and step through how to fulfill the requirements, with screenshots.

The Examples:

  1. An extremely common requirement is to have a two column layout for the node display of a given content type, with individual fields in separate columns. (screenshot example here)  Seems like a simple request, yes?  It's not possible with regions and blocks.  This is simple enough to do with a node template, but in order to preserve flexibility for site builders and even content editors, we've decided that we don't want a solution that requires writing PHP.  This is something that is (dare I say it) simple to achieve with any of the three modules we are highlighting, and we will step through how to do it.
  2. A more advanced (but still common) use-case is to have layouts that react to various conditions. For instance, you may need to have different layouts for public and private events. The “out of the box” solution might be to make separate content types for each. However, this is not semantically accurate, and creates difficulties when a content editor wishes to turn one into the other. These systems all have the flexibility to meet this requirement.

These two use examples hardly scratch the surface of what can be done with these modules However, we hope that they will get you interested in the possibilities, and an idea of which system will best meet your needs.

Tags: Drupal Planet
Categories: Elsewhere

Acquia: DrupalCon Austin and a new job - Kris Vanderwater

Fri, 13/06/2014 - 23:35

Kris Vanderwater (eclipseGC), and I got together in a Google Hangout plagued with technical difficulties to discuss DrupalCon Austin and Kris's new job as Acquia's Developer Evangelist. In the sections I could save and keep reasonably useable after editing, we talk about Drupal 8 and the incredible energy present in the Drupal community recently; a couple of hot topics DrupalCon Austin; and Kris's new job as "a developer for the community".

Categories: Elsewhere

Dries Buytaert: About today’s Drupal Association Board resignation

Fri, 13/06/2014 - 19:52
Topic: DrupalDrupal Association

Today Morten Hyde-Birch Jørgensen stepped down from his role on the Drupal Association's Board of Directors. The Drupal Association's Board of Directors supports Morten’s decision. The Drupal Association and the Drupal community value inclusivity and diversity, and our leadership must demonstrate those values as well.

We want to thank Morten for his service; he came to the board with a mission to foster improved transparency and communication. He helped both the board and staff embrace those principles in a way that will carry into the future.

Today’s development underscores the need for a broader discussion that we need to have about inclusivity and diversity. Creating and maintaining the right culture and environment is vital to Drupal's success. Therefore, we have asked the Community Working Group to define a process to help our community address these issues and identify positive, proactive, and concrete steps we can take to ensure that everyone feels welcome in Drupal.

Morten is vacating a community elected seat. The Board of Directors will discuss how and when to fill this vacancy at the next board meeting.


Drupal Association Board of Directors

Categories: Elsewhere

Drupal Association News: About Today's Board Resignation

Fri, 13/06/2014 - 19:44

Today Morten Hyde-Birch Jørgensen stepped down from his role on the Drupal Association's Board of Directors. The Drupal Association's Board of Directors supports Morten’s decision. The Drupal Association and the Drupal community value inclusivity and diversity, and our leadership must demonstrate those values as well.

We want to thank Morten for his service; he came to the board with a mission to foster improved transparency and communication. He helped both the board and staff embrace those principles in a way that will carry into the future.

Today’s development underscores the need for a broader discussion that we need to have about inclusivity and diversity. Creating and maintaining the right culture and environment is vital to Drupal's success. Therefore, we have asked the Community Working Group to define a process to help our community address these issues and identify positive, proactive, and concrete steps we can take to ensure that everyone feels welcome in Drupal. In any community, people will make mistakes. The real test of our community is how we respond to these issues.

Morten is vacating a community elected seat. The Board of Directors will discuss how and when to fill this vacancy at the next board meeting.


The Drupal Association Board of Directors

Categories: Elsewhere