Drupal Planet

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 28 weeks 1 day ago

Drupal core announcements: Drupal core security release window on Wednesday, July 15

Fri, 2015-07-10 16:56
Start:  2015-07-15 (All day) America/New_York Online meeting (eg. IRC meeting) Organizers:  David_Rothstein

The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, July 15.

This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix/feature release on this date; the next window for a Drupal core bug fix/feature release is Wednesday, August 5.

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: Drupal

Drupal Watchdog: Know Your Audience

Fri, 2015-07-10 08:24

Drupal.org is one of the largest and oldest continuously-operating Drupal websites in the world. The amount of content we have is both a blessing and a curse. Historically developed and maintained by community volunteers, Drupal.org has been growing organically for over a decade. New content keeps being added, while no major changes to information architecture and navigation have made it easily findable. With about 1.2 million pieces of content, the need to overhaul Drupal.org has become obvious. But where do we even start?

It is tempting to jump straight into content strategy, kick off a massive content audit, and talk about content types and archival processes. However, to develop comprehensive content strategy, you need to understand what kind of content is actually needed on your site. And to understand that, you need to know your audience.

Researching the Users

We underwent a user research project which lasted from May to August of 2014. Through a public request for proposal (RFP) process, we partnered with Whitney Hess, a user experience coach, to help guide the Drupal Association staff and community volunteers through the research.

The project kicked off with a full-day workshop at DrupalCon Austin. Participants included representatives from the Drupal Association staff and the Board of Directors, community volunteers, and advisors. Together, we brainstormed objectives for the new Drupal.org and metrics of success, as well as provisional user personas – our ideas about what those personas could be.

With that groundwork in place, we set out to validate (or disprove) our assumptions with real people.

We talked to 30 different users of our website located in the Americas and Europe: people who were new to Drupal, long-term community members, ex-Drupalistas, developers, site builders, designers, content strategists, PMs, and more. We sat down for an hour with each one of them and asked numerous questions about the way they use Drupal.org, things they enjoy about it, and their frustrations.

Once we had the data from the interviews, we started to synthesize it and develop personas.

Categories: Drupal

Drupal core announcements: Recording from July 10th 2015 Drupal 8 critical issues discussion

Fri, 2015-07-10 03:10

This was our 7th critical issues discussion meeting to be publicly recorded in a row. (See all prior recordings). Here is the recording of the meeting video and chat from today in the hope that it helps more than just those who were on the meeting:

If you also have significant time to work on critical issues in Drupal 8 and we did not include you, let me know as soon as possible.

The meeting log is as follows (all times are CEST real time at the meeting):

[11:21am] berdir: pfrenssen: that's one scary profile picture ;)
[11:22am] pfrenssen: haha it zooms in nicely :D
[11:23am] jibran: berdir: yay! https://bugs.php.net/bug.php?id=69996&edit=1 got fixed.
[11:26am] jibran: https://www.drupal.org/project/issues/search/drupal?status[0]=1&status[1]=13&status[2]=8&status[3]=14&status[4]=4&priorities[0]=400&categories[0]=1&categories[1]=2&categories[2]=5&version[0]=8.x
[11:27am] jibran: https://www.drupal.org/node/2497243
[11:27am] Druplicon: https://www.drupal.org/node/2497243 => Rebuilding service container results in endless stampede [#2497243] => 139 comments, 34 IRC mentions
[11:27am] GaborHojtsy: jibran: that’s the one that Fabianx-screen is talking about, right? :)
[11:29am] Fabianx-screen: Issues I talked about:
[11:29am] Fabianx-screen: https://www.drupal.org/node/2529516
[11:29am] Druplicon: https://www.drupal.org/node/2529516 => Decouple tests from relying that $container is a container builder [#2529516] => 10 comments, 9 IRC mentions
[11:30am] jibran: https://www.drupal.org/node/2502785
[11:30am] Druplicon: https://www.drupal.org/node/2502785 => Remove support for $form_state->setCached() for GET requests [#2502785] => 119 comments, 23 IRC mentions
[11:30am] jibran: https://www.drupal.org/node/2505989
[11:30am] Druplicon: https://www.drupal.org/node/2505989 => Controllers render caching at the top level and setting a custom page title lose the title on render cache hits [#2505989] => 54 comments, 10 IRC mentions
[11:30am] pfrenssen: I can't talk
[11:30am] Fabianx-screen: https://www.drupal.org/node/2530586
[11:30am] Druplicon: https://www.drupal.org/node/2530586 => Read-Only Container is not working properly. [#2530586] => 0 comments, 4 IRC mentions
[11:30am] pfrenssen: nice construction noises :)
[11:30am] pfrenssen: https://www.drupal.org/node/2524082
[11:30am] Druplicon: https://www.drupal.org/node/2524082 => Config overrides should provide cacheability metadata [#2524082] => 82 comments, 24 IRC mentions
[11:31am] pfrenssen: That's what I am working on. Next steps are to address the last remarks.
[11:31am] pfrenssen: It's clear how to move forward.
[11:31am] GaborHojtsy: pfrenssen: :)
[11:32am] jibran: https://www.drupal.org/node/2525910
[11:32am] Druplicon: https://www.drupal.org/node/2525910 => Ensure token replacements have cacheability metadata and that it is bubbled in any case [#2525910] => 72 comments, 10 IRC mentions
[11:32am] jibran: https://bugs.php.net/bug.php?id=69996&edit=1
[11:33am] GaborHojtsy: https://www.drupal.org/node/2512718
[11:33am] Druplicon: https://www.drupal.org/node/2512718 => EntityManager::getTranslationFromContext() should add the content language cache context to the entity [#2512718] => 144 comments, 46 IRC mentions
[11:35am] GaborHojtsy: https://www.drupal.org/node/2529516
[11:35am] Druplicon: https://www.drupal.org/node/2529516 => Decouple tests from relying that $container is a container builder [#2529516] => 10 comments, 10 IRC mentions
[11:37am] jibran: https://www.drupal.org/node/2528178
[11:37am] Druplicon: https://www.drupal.org/node/2528178 => Provide an upgrade path for #2354889 (block context manager) [#2528178] => 36 comments, 7 IRC mentions
[11:40am] jibran: https://www.drupal.org/node/2454439
[11:40am] Druplicon: https://www.drupal.org/node/2454439 => [META] Support PHP 7 [#2454439] => 126 comments, 25 IRC mentions
[11:40am] berdir: jibran: http://d8php7bot.erwanderbar.de/
[11:42am] pfrenssen: yay! :D
[11:42am] GaborHojtsy: dawehner: alexpott: we are running out of topics to talk about :D any topics you wanted discussed while we are on the call?
[11:42am] GaborHojtsy: dawehner: alexpott: https://plus.google.com/hangouts/_/gspzs5s25ucfasw6puf7muif7ya
[11:43am] alexpott: GaborHojtsy: yep
[11:44am] jibran: https://www.drupal.org/node/2505989
[11:44am] Druplicon: https://www.drupal.org/node/2505989 => Controllers render caching at the top level and setting a custom page title lose the title on render cache hits [#2505989] => 54 comments, 11 IRC mentions
[11:45am] dawehner: GaborHojtsy: oh let me try to join
[11:45am] GaborHojtsy: dawehner: alexpott is discussing title filtering
[11:45am] alexpott: https://www.drupal.org/node/2530474
[11:45am] Druplicon: https://www.drupal.org/node/2530474 => Discuss whether => 0 comments, 1 IRC mention
[11:46am] • dawehner tries to join again
[11:49am] dawehner: alexpott: GaborHojtsy I can't talk probably (given the speed of the net, can kinda listen) but I think allowing is a thing, given that people wanted something like tags
[11:57am] jibran: https://www.drupal.org/node/2493911
[11:57am] Druplicon: https://www.drupal.org/node/2493911 => Update guzzle, goutte and mink-goutte-driver to the latest release [#2493911] => 76 comments, 2 IRC mentions
[11:58am] jibran: https://github.com/guzzle/guzzle/pull/1167
[11:59am] pfrenssen: yay! D:
[12:00pm] pfrenssen: 14
[12:00pm] dawehner: https://www.youtube.com/watch?v=P_yl2WuiW4g
[12:00pm] pfrenssen: have a nice weekend!

Categories: Drupal

KatteKrab: Landscape design: a great analogy for the web

Fri, 2015-07-10 00:16
Friday, July 10, 2015 - 17:16

I often find myself describing the digital domain to people who don't live and breathe it like I do. It's an intangible thing, and many of the concepts are coded in jargon. It doesn't help that every technology tool set uses it's own specific language, sometimes using the same words for very different things, or different words for the same things. What's a page? A widget? A layout? A template? A module, plugin or extension? It varies. The answer "depends".

Analogies can be a helpful communication tool to get the message across, and get everyone thinking in parallel.

One of my favourites, is to compare a web development project, to a landscape design project.

One of the first things you need to know, is who is this landscape for and what sort of landscape is it? The design required for a public park is very different to one suitable for the back courtyard of an inner city terrace house.

You also need to know what the maintenance resources will be. Will this be watered and tended daily? What about budget? Can we afford established plants, or should we plan to watch the garden grow from seeds or seedlings?

The key point of comparison, is that a garden, whether big or small, is a living thing. It will change, it will grow. It may die from neglect. It may become an un-manageable jungle without regular pruning and maintenance.

What analogies do you use to talk about digital design and development?

Image: XIIIfromTOKYO - Plan of the gardens of Versailles - Wikipedia - CC-BY-SA 3.0

Categories: Drupal

Drupal CMS Guides at Daymuse Studios: Elegant Drupal 7 Administration: Mobile Theme, Menu, Modules

Thu, 2015-07-09 16:29

Use this system of Drupal admin theme and modules to create a mobile-friendly, modern Drupal 7 administration user experience. Improve workflow, help users.

Categories: Drupal

Acquia: Front End Performance Strategy: Scripts

Thu, 2015-07-09 12:31

In the last installment of this series, we considered CSS optimization. This time we’re going to look at the impact of scripts.

Remember, as architects and developers, it’s up to us to inform stakeholders about the impacts of their choices, offer compromises where we can, and implement in smart and responsible ways.

So, picking up on our last post, most everything about the way Drupal handles CSS holds true for JavaScript, with a few notable exceptions.

CSS aggregation removes whitespace, but JavaScript aggregation done using Drupal core's aggregation system doesn't do that or any other form of minification or uglification. It simply concatenates our scripts.

Like CSS, JavaScript also has three groups:

  • Library - Libraries, via drupal_add_library
  • Default - Modules
  • Themes - Your theme

Drupal creates aggregates for each of these three groups in the head, but can also deploy to the footer when the scope is set to ‘footer.’

When and where to load your JS

Drupal_add_js features a great option in the options array called scope that allows us to load JavaScript in the footer. This helps decrease our visual page load times by moving render-blocking JavaScript out of the way to a place where it won't impede the loading of other assets (like images, styles, other scripts).

The options array also provides an option called type which defaults to ‘file.’ When using the default option of ‘file,’ it tells Drupal that this is a script hosted on our site, so it's eligible to be aggregated. Combined with the every_page flag set to ‘true,’ just like with our CSS, these scripts get aggregated with the scripts added using ‘.info’ files into the big site-wide aggregates. If the every_page option is left out, or it is set to ‘false,’ then these scripts are aggregated as one-offs outside of our main three site-wide JavaScript aggregate files, again, just like with our CSS.

The type option can also be used to create inline scripts, which can be handy in a couple of ways. It will print our JavaScript directly into our header or footer depending on scope, but it's also useful for dynamically loading external scripts so they become asynchronous. Going forward, the async_js module is probably the way to go. I personally haven't had the opportunity to try it out, but I look forward to the chance. If you've used it, let us know in the comments how it worked out for you.

The third 'type' is the one we use for loading external scripts, which we seem to do often these days. Using an asynchronous method, mentioned above, is important because of the additional round-trip time to get the script. However, a slightly less effective way to handle it without using the older method of an inline script, or an additional module, is simply scoping the script to the footer and setting the type option to external (which prevents it from being aggregated).

Unlike with CSS, I'm less inclined to add JavaScript on every page because I like to scope JavaScript to the footer whenever possible. Since it isn't blocking render down there, the additional HTTP request doesn't really bother me. Generally, if it's on most pages, or a page visited by most users, go ahead and add it to every page. If it isn't and it's scoped to the footer, then only add it when it is needed. If it has to be in the header, and on an obscure page that isn't frequently visited by users, you're probably going to need to do some A/B testing to compare the performance hit on the obscure page by not including it on all pages vs. the performance hit on all the other pages by including it on all pages. I like to err on the side of the majority, meaning, I tend to only include the JavaScript on the obscure pages.

JavaScript: Know when to say when

You can do almost anything with JavaScript, and leveraging a framework like jQuery makes it easier to want to do everything with JavaScript. However, in addition to blocking page render and increasing the size of the page that has to be processed by the browser, there are other performance considerations with JavaScript.

It runs locally, in the browser, which means it uses a visitor's memory and processor. Poorly written or heavy use of JavaScript can lead to a poor user experience in the form of everything from delayed and choppy animations to browsers becoming unresponsive and/or crashing. For simple animations, consider using CSS3 animations, benchmark them using a tool like Chrome's dev tools or Firebug, and go with the least expensive performance option (these usually end up being the smoothest animations as well).

These script performance problems are often magnified on mobile devices where the hardware resources are more scarce and we often resort to using more JavaScript to solve challenges presented by the smaller viewport. This should reinforce the importance of a mobile first strategy, not only for design but also for development. It also highlights the need for open communication between the product owners, the design team, and the development team.


Scripts, like styles, contribute front-end implementations that can seriously hamper Drupal’s back-end magic. By favoring stylesheet aggregation and reigning in exuberant preprocessing, we can save the browser a lot of work. Applying the same principles to JavaScript, while properly placing scripts in the header or footer-based on function, can also improve our page-load times.

Next time, in our final post of the series, we’ll take a grab-bag look at some subtle, more specialized techniques that just might shave off those last few milliseconds. Stay tuned for a post covering Content Delivery Networks (CDN), semantic HTML, and how to encourage improved client-side content selection.

Tags:  acquia drupal planet
Categories: Drupal

Acquia: Quick Tips for Writing Object Oriented Code in PHP

Thu, 2015-07-09 12:15

Recently I began working on a D8 module, but this isn't a story about a D8 module. The work I did provided me an opportunity to get back to my pre-Drupal object oriented (OO) roots. Writing OO code in PHP presented some curve balls I wasn’t prepared for. Here are some of the issues I encountered:

PSR-4 Autoloading: How to set up your files to be loaded

First things first, how do you include OO code in your project? In D7 you had to add the files to a .info file for a module or do module_load_include. In D8 all you have to do is follow PSR-4 namespacing. If you follow the PSR-4 folder and namespace structure your classes will be auto-detected. No more need to add them to a .info file! If you are writing code for D8 then it’s done. Great. In D7 you can use the XAutoload module to get PSR-4 autoloading in D7 today!

Namespacing In PHP: Loading your files

Namespacing in PHP can be confusing and misleading. In Java or .NET, in a file you first import other namespaces you intend to use. In the example below we use the “using” keyword. Then you declare the namespace wrapper for the code that is being implemented.

using System;
using Microsoft.VisualBasic.Devices;
namespace SampleNamespace
    class SampleClass
PHP is VERY different. It’s actually the opposite. First you declare the namespace then inside the namespace you have your “includes.” In PHP including the use statements outside of the namespace would contaminate the global-scope.

namespace SampleNamespace
use GuzzleHttp;
use GuzzleHttp\Subscriber;

class SampleClass
Now this is where things get tricky. If there is a class called Client inside GuzzleHttp then you would expect that you could use it by writing the following.

namespace SampleNamespace
use GuzzleHttp;

class SampleClass {
function sampleFunction(){
          $myClient  = new Client();
And you would be wrong. The way that PHP interprets classes are RELATIVE to the current file’s namespace. So it actually sees “$myClient = new Client();” as “ $myClient = new SampleNamespace\Client();” which does not exist so the declaration fails. To work around this you can reference the actual class in the use statement. If you have multiple classes you must have an include for each one. It’s more verbose than what you might expect coming from .Net or Java e.g.:

namespace SampleNamespace
use GuzzleHttp\Client;
use GuzzleHttp\Subscriber\Mock;

class SampleClass {
function sampleFunction(){
          $myClient  = new Client();
   $mock = new Mock();
} Dynamic Typing: A variable can be anything!

PHP is a dynamically typed language. It provides great flexibility and velocity when coding, especially procedural code. However, this can be a nightmare when you are writing OO code. It means that you cannot make assumptions about the type being passed into an object. If you make assumptions and those assumptions are invalid your code can behave unpredictably. What are you to do?


You might be surprised to know that PHP allows you to apply and enforce function param types. PHP 5 introduced the concept of type hinting. With type hinting you can set type on objects. e.g
function sampleFunction(MySampleClass $a){

If a type hint is violated, an InvalidArgumentException is thrown. There is a catch to type-hinting in PHP, it doesn’t work for scalar types e.g (string, int, bool). There is also no type hinting on return types. You’ll have to wait for PHP 7 for both. In order to work around the scalar limitation in PHP5 you’ll need to write your own functions.

Setting up your code for an IDE

One of the advantages to writing Object Oriented code is that it works really nicely with an IDE like PHPStorm. If you have written type hinted code PHPStorm will pick up on it and help you with auto completion as you work. For the things that aren’t explicitly hinted you can use PHPDoc comments. e.g

* Gets a specific setting by its name/ID.
* @param string $id
*   The name/ID of the setting to retrieve.
* @return ZoneSettingBase
*   The setting object given the ID passed in.
public function getSettingById($id) {
return $this->settings[$id];
PHPDoc comments are actually mandatory as part of drupal-coding standards. Their omission causes coder’s code sniffer to fail.

You can also type-hint variables:

/* @var GuzzleHttp\Client $client/*
private $client;
While these hints are comments and not syntax they make the developer experience a lot more pleasant. No Enums :(

PHP still doesn’t have a formal enumeration type so you will have to get creative and roll your own.

I often create CONST arrays and throw an exception if a function param is not in that array. It’s a poor-man’s enum. There is currently a proposal to add enums to PHP7. We’ll see if it makes the cut!

Associative Arrays

Associative arrays reflect the dynamic typed heritage of PHP. They are incredibly flexible and a quick and easy way to move data from one point of your app to another that being said the lack of structure requires a developer to know everything about the underlying implementation of the array. Also without a debugger they have no way to determine what is actually in an array. The dynamic nature of these arrays makes them undocumentable. That makes coding with someone else’s array hard. The idea of OO is that you have structured data and layers of abstraction so that a dev doesn’t need to know the low-level implementation details. When going OO you should try to convert arrays into structured, documentable classes that hide the underlying implementation. If you need to accept an array as input parse it and break it out into objects as soon as possible. Developers will praise you for it!

No Function Overloading

PHP does not natively support function overloading. Since PHP is dynamic it’s possible to come up with some Frankenstein solutions to get around this. However, Frankenstein code often confuses other developers interacting with your code and is to be avoided. For better or worse you need to accept this constraint.

Dusting off the design cobwebs. How to assign responsibility to classes.

The lack of overloading can actually be beneficial especially in the context of class constructors. Like normal functions you cannot have multiple constructors in PHP (You can technically write a static class method to work around this constraint). This sounds like a pain. However, it forces you to articulate the single responsibility of a class. Often overloaded class constructors can be a sign that a class is taking on too many responsibilities. For example if you have a constructor that take params and another for parsing an array you might ask why should my class know about another representation. Maybe it's a break in tiered architecture and violating a separation of responsibilities. In this case something that might be perceived as a limitation is actually supportive and liberating.

Go Forth and Write OO Code

As we transition into D8 writing solid PHP OO code is more important than ever. D8 is built around OO classes. Even in Drupal 7 we can start to strive towards an OO world. Obviously in Drupal 7 most problems don’t lend themselves to an OO approach. However, even having that option gives you new tools to solve problems in Drupal! The resulting code has a clarity and aesthetic that most procedural code just can’t match.

Finding those opportunities to apply an OO solution keeps you sharp and ready to hit the ground running on Drupal 8.

Tags:  acquia drupal planet
Categories: Drupal

Cruiskeen Consulting: Drupal 8 and hosting requirements

Thu, 2015-07-09 10:05

I'm writing a little bit today about some of the concerns that folks are having about Drupal 8, the new hosting requirements it imposes, and particularly the concerns that smaller organizations will not be able to find Drupal 8 compatible hosting plans. There is a lot going on with us and with other hosting companies at the moment to support Drupal 8 and other PHP software that has more modern requirements. We don't think this will be an issue with most reliable hosting companies by the time Drupal 8 ships.

Categories: Drupal

Acquia: Sustainable contribution 2/2 - Giving back is the same as making money.

Thu, 2015-07-09 09:35
Language Undefined

Part 2 of 2 - I spoke with John Faber, Managing Partner with Chapter Three, on March 17th, 2015.

In part 1 to talk about the business advantages of contribution and sustainability when basing your business on open source software. We also touch on Drupal 8's potential power as a toolset and for attracting new developers, doing business in an open source context, and more!

Categories: Drupal

Drupal Bits at Web-Dev: Drush sql-query output

Thu, 2015-07-09 07:47

Despite several tries, I have never had any luck using the native sql output formatting commands to work with drush

Categories: Drupal

Drupalize.Me: Learning Drupal 8 from Boilerplate Code

Thu, 2015-07-09 06:02
Drupal 8 represents a lot of changes and a steep learning curve for many Drupal developers and themers. While many of these changes are exciting, there are many things to learn just to get started. One way to learn about the code involved with Drupal 8 modules and themes is to take a look at core's modules and themes for examples to follow. Another, is to use a code scaffolding tool like Drupal Console to generate boilerplate code and comments that you learn from and then customize.
Categories: Drupal

Drupal core announcements: Drupal 8's minimum PHP version increased to 5.5.9

Wed, 2015-07-08 21:17

Pursuant to the discussion at [policy] Require PHP 5.5, the minimum PHP version of Drupal 8 has been raised to 5.5.9, and this change will be included in the next Drupal 8 beta (8.0.0-beta13).

(PHP 5.5.9 was chosen because it is also the same minimum version as Ubuntu's LTS, which in turn influenced Symfony 3.0, Travis CI, etc.)

This is a future-proofing move which buys us a few things:

  • Some nice language features and a built-in opcode cache.
  • Compatibility with the latest versions of various external dependencies, including Guzzle 6 and the upcoming Symfony 3.0
  • Better security for our end users, since PHP 5.4 will become end of life September 15, 2015 (most likely prior to Drupal 8's release).

We looked extensively into the adoption and hosting support of PHP 5.5 prior to making this move. While there is not widespread adoption of PHP 5.5 as of today, we nevertheless found that most hosts offer the option for PHP 5.5, due to PHP's security policy.

Categories: Drupal

Mediacurrent: Mediacurrent Dropcast: Episode 7

Wed, 2015-07-08 19:39

In this episode we celebrate the founding of our country by talking up a few modules we have discovered and enjoy. Ryan talks about the Image Field Focus module and how it makes cropping a joy without the gamble of a cropping image style. Bob waxes poetic about the WYSIWYG Field module, which is very similar to his WysiField module. As always we keep you up to date about Drupal 8 and Ryan brings it home with The Final Bell. This was recorded on the day before all went out for the holiday weekend so there are times where we derail the train. At least this time we have an excuse.

Categories: Drupal

Drupal core announcements: API module seeking co-maintainer

Wed, 2015-07-08 15:24

For the past 8+ years, Neil Drumm (drumm) has been maintaining the API module, and I've been co-maintaining it for the past 3+ years. (This is the module that builds and displays the Drupal API reference site api.drupal.org). Both of us have "some" other responsibilities in the Drupal ecosystem, and we'd like to find a new co-maintainer.

The ideal person would be:
- A good PHP coder familiar with and willing to follow the Drupal project's coding standards
- Familiar with the api.drupal.org site and its features
- Familiar with the API docs standards
- Familiar with both Drupal 7 and Drupal 8 core code (or at least familiar with the kinds of code it contains and the Drupalisms that it has), since both are displayed on the site
Of course, all of these "ideals" are negotiable and/or learnable, and it could be that a few co-maintainers would be better than just one.

The next step would be for the person or people who are interested to start making patches for a few issues, and once a few of those have happened, we would consider making you an official co-maintainer. The project page has a link to documentation for how to get a local API site set up, and the module also has a robust set of tests. The code in the API module is somewhat obtuse, but I'd be happy to start anyone out with a quick tour (or help you find an issue to work on). The module runs on Drupal 7 only at this time, and this is unlikely to need to change anytime soon (it displays Drupal 8 code but runs on Drupal 7, like the other *.drupal.org sites).

So if you're interested, you can either jump in and find an API module issue to work on and make a patch, or use my contact form or IRC to contact me and discuss.

Sorry... by policy, comments on this post are disabled, since it is going into the Core group (as well as Documentation).

Categories: Drupal

DrupalCon News: Save 100€ on Barcelona Tickets: Buy by Friday

Wed, 2015-07-08 11:32

Are you planning on attending DrupalCon Barcelona? If you are, we hope you’ll get your tickets this week and save 100€ in the process.

Every DrupalCon has varied ticket pricing levels, and DrupalCon Barcelona is no different. We’re offering earlybird pricing so that frugal DrupalCon attendees can get their tickets for less, but that pricing expires on Friday at 23:59 Barcelona local time (UTC +2).

For those looking at purchasing tickets, be aware that prices are as follows as we lead up to the convention:

Categories: Drupal

Drupal Watchdog: Caffeinated Drupal

Wed, 2015-07-08 07:34

One of the signs that you’re in a good coffee shop is if they serve their milk-based espresso drinks with an artful rosetta (floral pattern) on top. This is referred to as Latte art. At first glance, it may appear to be an offhand flourish by the barista – similar to a bartender flipping a bottle in the air before pouring a drink – but it is actually much more than that.

Latte art is a representation of the care and expertise that went into creating your drink: a good quality coffee bean; the ideal grind in order to pull an espresso with the right amount of crema (the oily brownish foam that sits on top of a good shot of espresso); milk that has been steamed just right to have a micro-foam consistency (uniform small bubbles throughout); and, of course, the perfect pour to blend the milk and espresso just right until a flower, heart, or other artful creation emerges on top.

While we sit back and enjoy today’s coffee – a Brazil Yellow Bourbon Latte (amazing bitter cocoa flavors, is this a latte or a hot chocolate?!?) – let’s consider how an optimally performing Drupal site compares to the creation of latte art.

There are many factors that contribute to a high performance Drupal site. For starters, we can look at factors such as code quality, the use of caches where possible, database configuration, and front-end caching. For a Drupal site to perform at its best, all of these components must be done well. Even a small misconfiguration or a bit of buggy code can be enough to slow a site to a crawl, especially when serving a large amount of traffic. The same can be said for latte art: if the coffee beans aren’t fresh enough to produce crema, or the milk isn’t foamed properly, or the pour of the milk isn’t done with the correct technique, the result will be an ordinary-looking – and possibly poor-tasting – drink.

Categories: Drupal

Mpumelelo Msimanga: Drupal: Filters for External Data Views

Wed, 2015-07-08 07:18
Drupal: Filters for External Data Views

A Drupal View that uses Views Database Connector (VDC) to show external database tables will not have all features of a “normal” View. For example, select filters are only available for list fields, references and taxonomy terms. In this post I use two modules to improve the exposed filters in my external data View.

Categories: Drupal

Realityloop: Custom Formatters 7.x-2.4

Tue, 2015-07-07 22:51
8 Jul Stuart Clark

Full disclaimer, I am saying this as the developer of the module, but it is definitely the module that I am the most proud of.

That’s Custom Formatters with a capital CF; custom formatters (with lower case characters) are a core part of Drupal, they are the layer that takes Field data from the database and presents it to the frontend of your website in a more visually appealing style.

The Custom Formatters module quite simply adds the ability for site builders and developers to create or tweak their own custom formatters from within the website, never needing to touch the site file system.

And now, with Custom Formatters 7.x-2.4, it’s even better.


What’s new in Custom Formatters 7.x-2.4?
  1. New Formatter format/engine; Formatter presets
    This is the big one, the catalyst for the new release; Formatter presets give you the ability to take complex Formatters with settings and turn them into new simplified, end-user approved formatters.

    More on this below.
  2. Support for Display Suite fields
    I’ve been a big fan of Display Suite (DS) since I first came across it years ago. Custom Formatters did have support for DS in the Drupal 6 version, but I had made the decision to not support it in Drupal 7 due to DS’s own Code fields. Due to popular demand (my self included), that decision has been reversed.
  3. Fixes to the HTML + Token format
    HTML + Tokens was always supposed to be the format that made this module site builder friendly, but to various issues with native Field tokens in Drupal 7 it has never worked overly well. I’m happy to say that this is no longer the case, and HTML + Tokens formatters work extremely well.

    More on this below.
  4. Miscellaneous bug fixes.


How to use Custom Formatters?

Using custom formatters is relatively straight forward, anyone who has used any CTools Export UI based module (Views, Context, etc) should be familiar with the user interface:

By default it comes with some example formatters, and you can import others from your own collection or from CustomFormatters.com, but chances are you are most likely going to want to create your own Custom Formatters.

To do so, simply click the + Add button and you will be presented with the following interface:

You will need to provide the following information:

  1. Formatter name
    The human readable name of the formatter, what the site-builder, or possibly end user will see when choosing a formatter.

    Entering this value will auto-generate the Machine name, which can also be manually edited.
  2. Description
    Only used within the Custom Formatters interface, useful to explain what the purposes of the formatter are, where it’s to be used and what modules it requires.
  3. Format
    The format/engine of the formatter you are about to create. Out of the box there are three formats, but additional modules are able to provide additional formats. The format determines the method of how the Formatter is created, and as such I will go into more detail for each individual format below.
  4. Field type(s)
    Depending on the chosen format, you need to assign the formatter to one or many field types types (image, file, textfield, etc).
  5. Formatter
    The formatter interface itself is dependent on the chosen format, more details on each format below.

Once you have created your formatter, you can preview the formatter within the Preview interface. This allows you to apply the formatter to an existing field on an existing entity, or if the Devel generate module (provided by the Devel module) is present you can apply the formatter against a devel generated item.

Lastly, ensure you save your formatter, as you don’t want all your hard work to go down the drain. Alternatively, Save & Edit frequently during the creation of the formatter.


Format types

Out of the box there are three formats available with Custom Formatters, but the module is written in such a way that any 3rd part module could add an additional format.



The PHP format was the original format engine for the Custom Formatters module, it mimics as closely to writing a formatter within a Drupal custom module as feasible, and as such is only recommended for use by those with knowledge of PHP and the Drupal API.

The PHP format is provided with all required data for writing a formatter in the $variable array, as well as an individual variable per array key ($variable['#items'] is the same as $items):

  1. $obj_type: The entity type (node, taxonomy_term, etc)

  2. $object: The entity object.

  3. $field: The field definition.

  4. $instance; The field instance.

  5. $langcode; The language code.

  6. $items; An array of all field item data for formatting.

  7. $display; The formatter display settings and formatter settings.

With this data you are free to do with what you will. However, in general a standard pattern is to iterate over the $items array and populate an $elements array which is finally returned to Drupal:

  1. $elements = array();
  3. foreach ($items as $delta => $item) {
  4. $elements[$delta] = array(
  5. '#markup' => $item['value'],
  6. );
  7. }
  9. return $elements;

This pattern allows support for multiple items, as well as taking advantage of Drupal's Render Arrays system.


HTML + Tokens

The HTML + Tokens format allows you to create simple and easy Custom Formatters with no more than HTML and Tokens, as the name implies. While this has been available for a long time in Custom Formatters, in the latest release it has been vastly improved upon, primarily with improved support for the Entity tokens module (provided by the Entity API module).

Any entity type token can be used, as well as chained tokens specific to the field in use, but it is important to take into account where the formatter will be used when choosing the formatters. For instance, if you were to use a Taxonomy term token on an Image field formatter that is going to be displayed on a Node entity, the Taxonomy term token will not work.

The markup in your formatter is rendered per field item, so if you are using a multi-value field, each value will run through your formatter. This is where the improvements to the Entity tokens module support is important, as you can target the field values directly.

If you are formatting an Image field, you can target the URL using the Entity tokens chained token [file:url], which is unique to each item value.

In addition to the improvements with the Entity tokens module integration, I also released a new module, Field tokens, which adds two different type of tokens which are extremely useful with HTML + Tokens formatters:

  1. Formatted field tokens
    Tokens that allow you to pass the field through an existing Formatter with provided formatter settings.

    Example: [formatted_field-image:image:image_style-thumbnail] would pass the current image field value through the Drupal core Image formatter via the thumbnail image style.
  2. Field property tokens
    Tokens that provide you with the specific property of a field value.
    Example: [field_property:alt] would return the Alt value for the current image field value.


Formatter preset

A new addition to the Custom Formatters module, and while maybe not the most obvious, it is a great addition that was a direct response to the Wysiwyg Fields module.

The Formatter preset format allows you to replace formatters with complex formatter settings forms with simple preconfigured formatters with more user friendly names. Especially useful when the formatter choice is exposed to a non-technical user.

Below you can see an example of the Youtube field and formatter in use in Wysiwyg Fields with it’s abundance of formatter settings (on the left) and a Formatter preset of the same formatter preconfigured as desired (on the right).

It’s obvious a lot simpler, so simple in fact that there’s no evidence that a formatter or formatter settings are present, it will just work.

Creating a Formatter preset is quite different to the other Custom Formatter formats. There is no textarea field, instead you are presented with an interface similar to screenshot below:

Things to note are:

  1. Formatter
    The existing formatter which you are using as a source for this Formatter preset.

  2. Formatter settings
    Everything below the Formatter field are specific to the chosen Formatter, they are that Formatter’s settings.

Extremely simple, but a huge improvement to the user experience.



While not an out of the box Format for the Custom Formatters module, I think it’s important to mention this for two reasons:

  1. Drupal 8 is coming, and it’s bringing the Twig templating system with it.
  2. This is a great example of how other modules can create new Custom Formatters format types.

The Twig format requires the Twig filter module, which doesn’t yet have a stable release, but is still well worth a look.

The interface is much like the PHP and HTML + Tokens formats, with the difference of using the Twig templating language, which is said to be simpler for frontend developers.


Using a formatter

Once you’ve created your formatter, that formatter can be used in many different ways, as the the Formatter system is just the theme layer to Drupal’s field system, so in general a Formatter should be able to be used anywhere a Drupal field is used.

Examples of ways to use a Formatter include, but are not limited to:

  1. Drupal’s core Manage display interface

  2. Views using the Field style

  3. Wysiwyg Fields

  4. Formatted field tokens with the Field tokens and Token filter modules



CustomFormatters.com is a companion website for the CustomFormatters module.

It contains various Formatters which can be used as they are, or as examples of how to write your own formatters.

There are also plans to provide the ability for uses to share their own formatters with others.

The website is completely open source, and anyone wishing to steal the site or contribute to the site can do so at https://github.com/Decipher/customformatters.com


Download Custom Formatters now

Head on over to the Custom Formatters project page and download Custom Formatters 7.x-2.3 now.

drupal planetdrupal 7custom formatters
Categories: Drupal

OpenConcept: The Drupal North Code Sprint

Tue, 2015-07-07 14:40

The inaugral Drupal North Regional Summit was a blast!

The official Drupal North sprint was held on Sunday, June 28th, starting around 10am and ending at 4pm, in Ryerson University's Rogers Communication Centre Transmedia Zone. 21 attendees showed up from all over Canada, the United States, and even Costa Rica:

After everyone introduced themselves, Cottser and I gave an introduction to writing patches, and how issues move through the issue queue from "Active" to "Closed" (video to follow).

Then, we paired up to get Drupal 8, Drush, and Drupal Console working on our computers, and work on issues we were interested in. We worked on 9 issues:

At time-of-writing, 2 of these issues are fixed, and 5 more need review.

Also, congratulations to Jeremy Knab for his first commit mention in Drupal core (from #2501701)!

Overall, we had a great time and learned a lot! Thanks to everyone who came out, and to the DrupalNorth organizers for organizing everything!


AttachmentSize DrupalNorth 2015 sprinters sitting around a table, introducing themselves.167.46 KB DrupalNorth 2015 sprinters sitting around a table, listening to Cottser.189.44 KB DrupalNorth 2015 sprinters gathering around and setting up a television, about to set up Drupal Console.164.66 KB cyborg_572 and crasx setting up.177.64 KB Cottser demonstrating how to turn on the automated testing module in Drupal 8 to enzo, bohemier, adamwhite, and HelloNewman.142.43 KB bohemier and adamwhite working together on an issue and laughing.143.63 KB HelloNewman eating a Timbit while nafes & Cottser concentrate on their work. In the foreground is an iconic Tim Hortons coffee.93.58 KB Topic: Primary Image: 
Categories: Drupal

Powered By