Planet Drupal

Subscribe to flux Planet Drupal - aggregated feeds in category Planet Drupal
Mis à jour : il y a 41 min 49 sec

KatteKrab: Constructive Conflict Resolution

jeu, 30/04/2015 - 00:09
Thursday, April 30, 2015 - 08:09

I'm speaking at DrupalCon Los Angeles. 5pm, Tuesday 12 May in the 518 - Trellon room.

I first spoke about Constructive Conflict Resolution in Amsterdam at DrupalCon last year. I posted the slides, recording and speakers notes from that talk to the PreviousNext blog.

I'm reprising that talk in Los Angeles because someone else is now unable to make it, and I was asked if I could fill in. When I originally proposed the talk for LA I had planned to rework the slide and narrative - but unfortunately won't have much time to do that before the conference. However this is a conversation starter, and we'll have an opportunity in the room to discuss how we might embrace conflict as a force for good, as a force for progress. How to harness it, how to minimise it's potential for harm.

I hope to see you there!

Constructive Conflict Resolution will be in the core conversations track at DrupalCon Los Angeles.

Catégories: Elsewhere

DrupalCon News: First Time Attendee Social

mer, 29/04/2015 - 22:08

Attending a large conference for the first time can be both exciting and uncertain — and DrupalCon is no exception. What should first-time attendees to DrupalCon expect? 

Catégories: Elsewhere

Promet Source: Melding AngularJS With Drupal Sites

mer, 29/04/2015 - 20:29

After spending the weekend going through a rather excellent (I thought) video overview course on AngularJS, my head was spinning with the possibilities when it came to building Drupal sites that were much more responsive in terms of loading and displaying content. So, I decided to start working on some proof of concept modules that would help me better understand how to effectively meld these two tools together.

Catégories: Elsewhere

Lullabot: Should you Decouple?

mer, 29/04/2015 - 20:00

One of the major topics of discussion in the Drupal community has been decoupled (or headless) Drupal. Depending on who you ask, it’s either the best way to build break-through user experiences, or nothing short of a pandemic. But what exactly is a decoupled architecture?

Catégories: Elsewhere

Midwestern Mac, LLC: Developing for Drupal with Vagrant and VMs

mer, 29/04/2015 - 16:21

Many blog posts have outlined the benefits of using VMs (Virtual Machines) for local Drupal development instead of either using native PHP and Apache, or a bundled environment like MAMP, XAMPP, or Acquia Dev Desktop. The advantages of using virtualization (usually managed by Vagrant) are numerous, but in certain cases, you can make a good argument for sticking with the traditional solutions.

If you'd like to take the dive and start using virtualized development environments, or if you're already using Vagrant and VirtualBox or some other VM environment (e.g. VMWare Fusion or Parallels Desktop), how do you optimize local development, and which pre-bundled Drupal development VM will be best for you and your team?

Criteria for the Perfect Local Development Environment

These are the criteria I use when judging solutions for local Drupal development (whether virtualized or traditional):

  • Should be simple and easy to set up
  • Should be fast by default
  • Should be flexible:
    • Should work with multiple providers; VirtualBox is free, but VMWare can be much faster!
    • Should allow configuration of the PHP version.
    • Should work with your preferred development workflow (e.g. drush, makefiles, manual database sync, etc.)
    • Should prevent filesystem friction (e.g. permissions issues, slow file access speeds, etc.)
    • Shouldn't have hardcoded defaults
  • Should be complete:
    • Should work without requiring a bunch of extra plugins or 3rd party tools
    • No extra languages or libraries should be required (why install Ruby gems, npm modules, etc. unless you need them for your particular project?)
  • Should be Free and Open Source
  • Should include all the tools you need, but allow you to disable whatever you don't need (e.g. XHProf, Apache Solr, etc.)
  • Should work on Windows, Mac, and Linux with minimal or no adjustment
  • Should be deployable to production (so your local dev environment matches prod exactly)

A lot of these points may have more or less importance to a particular team or individual developer. If you're a die-hard Mac user and don't ever work with any developers on Windows or Linux, you don't need to worry about Windows support. But some of these points apply to everyone, like being fast, simple, and flexible.

Catégories: Elsewhere

Modules Unraveled: 134 Deciding when to upgrade to Drupal 8 with Kristof Van Tomme and Peter Kohan - Modules Unraveled Podcast

mer, 29/04/2015 - 14:30
Published: Wed, 04/29/15Download this
  • What is
  • When did you put the site together?
    • Today
  • How were you offering the service before the site was up?
    • Talk about MVP
  • Why did you guys create this service?
    • Build a more direct communication channel for module maintainers - Mailing list (module devs talk to people using module
    • Initiative to get out the catch 22 - modules aren’t ready, so you can’t upgrade, you don’t upgrade so the modules don’t get money to be upgraded.
  • Does it cost anything?
    • Nope - it’s free
  • Are you planning to monitize the site in any way?
    • We expect a lot of site owners will be looking for a way to upgrade their website, if they don’t yet have an agency, we can help them find a good agency. If this evolves how we imagine, this could fuel the sales pipeline for our consultancy and a few selected partners. We are not going to go hardcore salesy on this, but put in links for module work and 2for1 discounts and hopefully some of those will convert into customers for us or our partners.
  • How does it work? What do I have to do to track a site?
    • As simple as possible, conscious choice to not make it a module - just copy paste your module page
  • How many people have signed up so far?
    • We’ve got a total of 73 sites now, some from the same people - after Drupalcon LA we expect that to become a few hundred.
  • What do you have planned for the future of the site?
    • The community misses a permission marketing channel for module developers. We would like to let site owners sign up for important information about the modules they use through a push communication channel. There is a lot of talk in the community that we are not getting any support from site owners for the development of D8, but we’ve made it almost impossible for them to stay up to date. There is no way they are going to start reading the issue queues of modules on regular basis.
  • I took a look at the site and saw something called 2for1 - Give to Get. What’s that?
    • This is part of the strategy we want to use to monetise the platform: we offer our customers a 2 dollar discount on their future D8 project for every dollar they invest in helping Drupal 8 get out of the door. This gets us more business and brings outside funding into the community. For too long we’ve been giving money from one developer’s pocket to the next developer’s pocket. We hope we can change that this way. We are inviting other consultancies to join us in this campaign, if you want to join, you can become a partner in the campaign.
Special Thanks!

Thank you FourKitchens for the DrupalCon Ticket and Kalamuna for helping offset my travel expenses! You guys (and gals) are all awesome!

Episode Links: Kristof on drupal.orgKristof on TwitterKristof on Skype - kvantommeKristof on LinkedInPeter on drupal.orgPeter on TwitterPeter on LinkedInPeter on Skype - kenya1hud8upgrade.orgTags: Drupal 8Upgradingplanet-drupal
Catégories: Elsewhere

Jim Birch: Drupal 7: Organizing with Field Group

mer, 29/04/2015 - 13:30

The Drupal Field Group module has been on my Essential Drupal list since I first learned about it, and with 200,000 installs, I am certainly not the only one.

Field Group lets you add the common CCK field wrappers on their own so you can organize not only the display of the nodes through the Entity View Modes, or Display Suite on the "Manage Display" tab, but it also lets you organize fields as they are displayed to the administrator on the Add and Edit screens through the "Manage Fields" tab.

Field Groups allows for adding and configuring of the following field types:

  • Fieldsets
  • Horizontal tabs
  • Vertical tabs
  • Accordions
  • Divs
  • Multipage steps
  • HTML5 elements
  • HTML elements

If you are using a default Admin theme like Seven, adding and configuring the default Fieldsets, tabs and accordions make your content configuration screens blend in perfectly since they are already styled.  You can also take your node add and edit screens to the next level by theming DIV's, or any HTML/HTML5 elements if you are using your front end theme for administration screens, or a custom admin theme.

Read more

Catégories: Elsewhere Cross Browser Visual Regression Tests With Shoov

mar, 28/04/2015 - 23:00

Maintaining visual regression tests can be hard, but the more tests we write for our projects, the more we see the tremendous power it provides in terms of QA and monitoring our sites.

One daunting task each developer hates (and often avoids) is validating their markup on multiple browsers. All of Gizra's developers use either Mac or Ubuntu on their machines, so the line to the "IE computer" on the far end of the office is getting long. Way too long.

And honestly - after our poor developers validated their work once, if we'd ask them to do it again. And again. And again... we'd probably be left without any.

Developers moral shouldn't be underestimated!

Shoov means "Again" in Hebrew for this very reason.Go ahead and jump to our example repo which now has cross browser tests. Writing your tests once - but testing on multiple platforms and browsers is a big win. tested by BrowserStack on Windows7, IE11, with 1024x780 resolution

Continue reading…

Catégories: Elsewhere

DrupalCon News: Come to the Community Summit

mar, 28/04/2015 - 18:50

Submitted by:  William Estrada - DCon LA Community Summit volunteer

Do you love your local Drupal community?  Do you want to grow Drupal adoption in your hometown? Do you take satisfaction is providing mentorship or are you looking to pay it forward after being mentored? Are you the person who always raises their hand to help others and wants to get involved?

Catégories: Elsewhere

Drupalize.Me: How to Contribute to Translations in Drupal Projects

mar, 28/04/2015 - 14:02

Let’s take a brief look at how translation contributions work in Drupal. This written tutorial is based on the free video, Translation in Drupal.

Catégories: Elsewhere

Jim Birch: Essential Drupal: Global Redirect Module

mar, 28/04/2015 - 13:00

The Global Redirect module ensures that we will have the best possible technical output from Drupal for Search Engine Optimization (SEO).  It is available for Drupal 6 and Drupal 7, and it looks like they have been hard at work building it for Drupal 8.

For years, the best practice for any site is to make the URLs keyword rich and friendly so the user knows what to expect when they visit.  So we change Drupal's "Clean URL" settings from to and then we change Pathauto's settings from to

What we are missing is that those original URLs still remain live on the internet, and can be considered duplicate content, a detriment to good SEO.  Global Redirect automatically sets up 301 Redirects for both of the old URL schemes, to the new friendly URL.

The same goes for the trailing slash.  This module removes (or adds if you so choose) the trailing slash, so there will be only one canonical URL living between and

The last big option is the home page.  In Drupal's Site Information, we set which node we want as the site's homepage.  Global Redirect makes sure that we only have one page indexed, rather than and

There are quite a few more options that can be configured at:

Read more

Catégories: Elsewhere

ERPAL: 6 steps to avoiding unrealistic budgets and deadlines in projects

mar, 28/04/2015 - 12:50

In our preceding post we focused on the topic of "responsibilities and communication" and the importance of questions that help to clarify duties and responsibilities. Today we’ll deal with unrealistic deadlines and budgets – and how to avoid them.

An 800-hour project is not finished in a day, not even with 100 programmers. The completion time of a project is derived from the sum of the times estimated for the individual requirements. In order to do this reliably, it’s essential to know in detail what has to be done. This is why requirement engineering is vital at the beginning of a project. Even though a deadline (completion date) is determined by the sum of expenses, it’s important to note that not everything in a project can run in parallel, meaning that more is not always faster. A project plan for the overall project and for every single sprint will help you to control the progress, expenses and deadlines.

1) What task requires what expertise?

Not every job requires the same expertise. In addition to technical skills, there are often technical requirements that are necessary to reflect specific customer business processes in the software. These requirements should be stated in the individual tasks. It’s part of the project management to make this categorization a responsibility of the developer. If you optimize your project plan, for example with a Gantt chart, you can plan resources such as time, money and people at the beginning of a project and validate the plan accordingly.

2) Which developers can do which tasks?

One developer is not equal to every other developer. Everyone in the team has specific competencies: you get selected for a project because your skills fit well. Even in software development, it’s rarely the case that everyone all has the same expertise. A good Drupal developer is not necessarily a good site builder nor a good themer. You might make this assumption when hiring a person, but you’ll be disappointed if you don’t verify his/her skills. Therefore, you should be able to associate the expertise of your team with the specific tasks on hand. A good way to illustrate the dependencies of tasks is with a Gantt chart: for realistic budgeting you need a detailed plan so that you know, as a provider, what you have to achieve over which period of time. On the customer side, a detailed plan with clear time estimations helps you know what you’re getting for your money so you can rest assured that all the features – such as deadline, budgets, prices and specifications – are realistic. This is necessary because you want to achieve something positive with your project and, thus, have to rely on the data from good and realistic planning. The deadline is determined by adding up the times required by each developer in the team, taking the dependencies of each task into account. Plan in a fixed buffer for project management, quality assurance and communication.

Project management cannot be hurried. It costs time and money, but if done right, it’s worth it. When the project’s time and budget are reaching the end without the certainty that the project itself is facing a successful end, the quality inevitably suffers. So: plan realistically to protect your team from unnecessary stress and to provide your customer with the assurance that he can count on your word. This is an essential foundation for any successful project.

3) Done does not equal completed

Even when all the development work is done in your project, it doesn’t mean that the project is really completed. Now, when acceptance is imminent, the integration of all the single tasks needs to be (double-)checked. When deploying the project to acceptance you should definitely first check internally whether all benefits promised in the concept were actually implemented and tested. This usually happens on a staging system to prepare a customer presentation. Optimally, for each task you should also be able to demonstrate that you’ve fulfilled it with the promised performance and validated it by testing for proper execution. Only once this internal process is successfully completed should the project results be presented to the client for approval. Unfortunately, it’s often overlooked that the cooperation of the customer is required: your customer needs to test his specification accordingly and, hence, accept the project if there are no more serious bugs. Working cleanly and in detail is even more important at the beginning of the design phase. This becomes evident not just in the acceptance: if there are only minor bugs that don’t prevent the functioning of the concept, the project must be accepted with a bug report, which will then be attached to the acceptance report.

So, try desperately to stick to the following points:

4) Only provide what was actually tested

Although you have the right to repair, it looks unprofessional if you provide your customer with a project result that has obvious errors. This casts the project team in a poor light. So, write down what you’ve tested. Key points about each task and the benefits of the concept are sufficient. Clear acceptance criteria will help prove that all the requirements have been fulfilled

5) Involve your clients in the acceptance and prepare it well

Nothing is worse and more unproductive than if you provide your customer with the results of the project after three months of silence. Certainly, you may argue that you’ve just been doing focused work, but communication is simply essential to managing expectations. Your customer will feel lost if you don’t communicate at all. If you don't communicate recent status updates in recurring meetings, your customer will create his own expectations regarding the progress. So, communicate and show individual project results continuously – but only when they’re also really presentable. Engage your clients in the purchase process and show a demo of what the software can do and how that fits into the concept you created earlier, so your customer isn’t left with doubts and ambiguities but can ask you directly. Questions and problems can then be discussed immediately – and resolved.

6) Collect all the aspects that your customer wants to be changed

Sure, there will be functions and requirements that must be implemented in the software before it can go into production. Collect all these points in an initial protocol. Then, evaluate the different points, examine the requirement changes (change requests) and determine which of the points are still outstanding to the concept. Those still owing must either be implemented as soon as possible or appear in the internal quality assurance. Actually, they shouldn’t be there at all if you’ve already tested internally against the specifications! Change requests are then processed after acceptance. The same applies to minor bugs that don’t affect the functionality.

Both parties should have the same goal: To achieve (partial) acceptance and thus arrive at a decision that a project milestone is completed, after which work can continue and the software enhanced with other useful features. The project is taken forward after each individual milestone, with partial acceptances for single milestones and checks against the project objectives. This has the nice side effect that your customers will become familiar with the software in small pieces and you’ll get immediate feedback on whether the development is going in the right direction or not. So you see :

An agile approach doesn’t mean that there’s no concept! Quite the opposite – planning is important.

In the planning phase, particularly in terms of effort and deadlines, you have to count on further work after acceptance of the project.

The next post will deal with how to manage agile projects with structure and control.

Other blog posts of this series:

These 3 questions help you to ensure satisfactory project results

Setting objectives in projects with these 3 rules

Agile projects for a fixed price? Yes you can!

3 things to consider when creating project specifications

6 rules to follow to promote communication in projects

Catégories: Elsewhere

Vardot: Ready to Upgrade Your Website? Here's Tips for Migrating to Drupal

mar, 28/04/2015 - 10:38

A basic content management system works fine for a simple, static website, but for those of us with content-heavy websites—like online news platforms or schools or non-profits—a basic CMS will be hopelessly overmatched. Dynamic companies and organizations need a correspondingly agile CMS to effectively meet their web needs—and the words “dynamic” and “agile” and “effective” are all practically synonyms for “Drupal.”

Drupal is generally regarded as the most powerful and adaptable open source CMS available, and it’s utilized by influential news organizations like Al-Jazeera, powerful NGO’s like UNRWA, and prestigious universities like Georgetown. Additionally, Drupal boasts an active and passionate developer network that ensures that it’s an excellent system because it's constantly evolving to meet your evolving needs.

But a trade-off for its power is its complexity, and the simple truth that Drupal is a powerful tool that can potentially be overkill for a modest website—and this means migrating to Drupal shouldn’t be taken lightly, and that you will need to work with a competent development team.

But if you’re willing to undertake a few simple steps, you can discover whether or not Drupal is the CMS for you and make the process of migrating to Drupal simple and stress free,  while unlocking its incredible potential…

1. Map your Ambition

This is basic, but necessary, and if you avoid it it can come back to bite you down the road. Identical to if you’re planning on moving your business to a new office or introducing a new product or campaign, you need to turn that idea into a tangible model before you can actually proceed with any direction.

When it comes to migrating to Drupal, this will allow you to estimate how many resources you have to commit to the project and what your expectations are, and will reveal to you how achievable your ambitions are.

You should ask yourself:

  • What’s the timeline for your migration?
  • How soon do you need to see a return-on-investment?
  • Which in-house employee will oversee the transition? 
  • What do you envision the minimal viable product looking like?
  • What potential hangups can you not possibly incur?
  • How much is the opportunity cost of upgrading?

Covering these simple steps will make it clearer whether or not you’re ready to migrate to Drupal, and armed with this model you’ll be ready to get the actual wheels turning towards your goal.

2. Perform an Organizational Site Audit

The Drupal development team needs to understand your organization's needs if it's going to build a functional website, and that means your organization can’t have a vague idea of what it needs—it needs a concrete understanding. You should comb through your site and analyze its functionality versus your needs. This will save innumerable back-and-forth meetings and potential disaster down the road—when you’re in too far to turn back.

So before collaborating with Drupal designers, you should to be able to identify:

  • Which components currently provide value from the source site?
  • Which parts need to be migrated from the source site?
  • What enhancements to design and functionality does your new site require?
  • Which design or functionality features you would like to retain?
  • Which required features from the old site will be difficult to integrate because of custom design?
3. Select the Right Drupal Development Team

Now, having actualized your ambitions and mapped your situation, you should be able to consult with a Drupal development team and let them dig into your site with a technical site audit. But to do that, first you need to find the right developers for the job–and this should be done carefully.

A couple things to look for when choosing your team:

  • Are they Drupal approved?
  • Does their portfolio contain similar projects to yours?

As said before, Drupal is a complex CMS, and if you entrust your web development needs to an inexperienced developer or hire a single freelancer to handle a demanding task, the development process will stressful and the eventual product will undoubtedly be flawed. 

Freelancers have their merits—but if you contract a Drupal development team with a proven track record of success, you will be dealt with efficiently and professionally. The resulting migration process will be stress-free and your updated site will be up and running promptly.

Migrating to a new CMS can be a daunting process—but it doesn’t have to be. If you put in a little legwork, and collaborate with top-notch Drupal experts like Vardot, your resulting website will satisfy your requirements and put you one step further along the path to success in an increasingly digital world.

Questions or Comments? Respond below or drop us an email and we’ll get back to you no time.

Tags:  Migrating to Drupal Drupal Development Drupal Planet Title:  Ready to Upgrade Your Website? Here's Tips for Migrating to Drupal
Catégories: Elsewhere

Amazee Labs: Drupal 7 total language fallback

mar, 28/04/2015 - 09:22
Drupal 7 total language fallback Reasons for language fallback

Let's assume you have a website divided by countries. The site structure is:

  • Global (en, de, fr)
  • Germany (de)
  • France (fr)
  • Switzerland (de, fr)

You have your content translated to three languages. Normally, this works, but there could be cases when you need languages per country. Words might have a slightly different meaning from country to country (examples) or spelling might be different (en-US vs en-GB, or using "ß" in de-DE vs "ss" in de-CH). Or, for example, the "Contact us" page can contain a country specific information - locations.

So, the site structure can be turned to:

  • Global (en, de, fr)
  • Germany (de-DE)
  • France (fr-FR)
  • Switzerland (de-CH, fr-CH)

This can bring a translation nightmare until you have a language fallback ;)

Having the language fallback, you would only translate strings/content to the "base" languages and, in special cases, you may also translate to "country" languages.

Fortunately, there is a module for that. The Language fallback.

Language fallback 7.x-1.x

The first version of the module provides language fallback only for locale strings (strings that are passed through the t() function). After the module installation, you can find the "Language fallback" option at the language edit form.

If a string translation is missing for the de-CH language, the translation from the fallback language (de) will be used in this case.

How the locale fallback works

There is a strings override feature in Drupal 7 core. Basically, you can define translations for some strings via variables. For example, you can put something like that into your settings.php file:

$conf['locale_custom_strings_de-CH']['']['Home'] = 'Startseite';

While this possibility is used really rarely, the Language fallback module transforms it into the real power. It saves instances of the localeWithFallback class to locale_custom_strings_* variables. The localeWithFallback implements ArrayAccess, thus it can return string translations automagically.

Language fallback 7.x-2.x

We also want to have the language fallback for our content translated via the Entity Translation module. The second version of the Language fallback module provides this feature.

This option enables the translation fallback for entities on the field level. For example, if an entity does not have a certain field translated to the de-CH language, the de translation of this field will be used for the entity rendering.

How the entity translation fallback works

Actually, this ability is provided by the core Locale module. The Language fallback module just hooks into the process.

Here is the call stack describing how it works:

  • field_language()
  • hook_field_language_alter()
  • locale_field_language_alter()
  • locale_field_language_fallback()
  • language_fallback_get_candidates()
  • hook_language_fallback_candidates_alter()
  • language_fallback_language_fallback_candidates_alter()

The last function does the job.

Language fallback chains

That's another feature only available from language fallback 7.x-2.x.

Now, on the language edit form, you can define several fallback languages in a particular order.

Language fallback 7.x-2.x-amazee

If you try to use the language-per-country workflow with the Language fallback module, the first thing you'll miss is the i18n support. The Internalization module helps us to deal with the translation of menu links, field labels, panels, etc. So, we started work in this direction and have prepared a patch.

After the patch was tested, we found that it would be quite useful to have the fallback information displayed right on the translation overview pages. We implemented this feature, too.



We've submitted a patch containing both improvements to #2322883: Add support for i18n strings.

After using the new overview pages for some time, we decided to also improve the entity translation overview pages, since it improves the usability for content editors.

This developed into another patch #2444203: Show fallback information on the translation overview. This time, for the Entity translation module. (Be sure to enable the "Show fallback statuses on overview pages" checkbox on the admin/config/regional/entity_translation page after you have applied the patch.)

Language fallback for path aliases

There was an issue we have met implementing language fallback on our projects. The Pathauto module only generates aliases for the existing node translations. To fill that gap we have created the Path alias force module. It forces creation of aliases for all languages. Furthermore, it supports language_fallback, so aliases respect the fallback rules which is nice.

Total language fallback

Having all these patches applied, we have the complete solution for the language fallback on Drupal 7 websites. Now the language-per-country workflow can be used for real projects.

BTW. If you don't want to apply patches, you can use the Amazee Labs repositories which contain all required changes:

Let us know if you have any issues!

Catégories: Elsewhere simpleTest with Behat for Drupal 8

lun, 27/04/2015 - 23:00

The first time I heard about Behat was at DrupalCon Munich 2012. Since then use of Behat has grown exponentially and the tools it can be integrate with grew as well. With Behat we can test the markup of a page - pretty neat, right?

Well, it's time to take Behat integration with Drupal a little further. I've decided to try and integrate it with Drupal's simpleTest, as this would open the door for writing simpleTests that are more readable and more "behavior driven" by nature.

Scenario: Testing the login form. Given I visit 'user' And I fill in 'Username' with '@user-name' And I fill in 'Password' with '@user-pass' When I press 'Log in' Then I should see '@user-name'

Amazingly enough, the above Gherkin code which is being executed by PHPunit can test your Drupal installation!

Behat code executed from within Drupal's simpleTest

This functionality is provided by an experimental repo, which comes with an example test.

Continue reading…

Catégories: Elsewhere

Midwestern Mac, LLC: Honeypot for Drupal 8, 3 years in the making

lun, 27/04/2015 - 21:03

Almost three years ago, on Feb 19, 2013, I opened the 8.x-dev branch of the Honeypot module (which helps prevent form spam on thousands of Drupal sites). These were heady times in the lifetime of the then-Drupal 8.x branch; 8.0-alpha1 wasn't released until three months later, on May 19. I made the #D8CX pledge—when Drupal 8 was released, I'd make sure there was a full, stable Honeypot release ready to go.

Little did I know it would be more than 2.5 years—and counting—before I could see that promise through to fruition!

Catégories: Elsewhere

Chapter Three: Presentation: Drupal 8 Theming

lun, 27/04/2015 - 20:30
Catégories: Elsewhere

Advomatic: Automating Living Style Guides in a Drupal Theme

lun, 27/04/2015 - 20:18
Over the past year or so here, we’ve tried to make front-end development less painful by creating living style guides in our Drupal themes that we can use internally as a valuable resource during development, as well as externally as a client deliverable. They allow us to write consistent, reusable and efficient code that is easy to maintain over... Read more »
Catégories: Elsewhere

Drupal Watchdog: VIDEO: DrupalCon Amsterdam Interview: The Drupal 9 Question

lun, 27/04/2015 - 18:07

Taking advantage of the DrupalCon Amsterdam gathering of Drupal bigwigs – and in our eternal quest to quench our thirst for enlightenment, and thrust onwards into the future and deeper into the unknown – we corner some of those key Drupal players to ask the all-important question burning in everyone’s mind: When is Drupal 9 coming out?

Dries Buytaert (Drupal Creator and CTO & Co-Founder of Acquia): Nine?

MortenDK (Viking, geek Röyale): Oh! Ho-ho-ho!

Leslie Hawthorn (Director, Developer Relations, Elasticsearch): After Drupal 8.

Tom Erickson (CEO, Acquia): Drupal 9!

Michael Meyers (V.P. Large Scale Drupal, Acquia): I think that the real question is how fast can we accelerate the pace of innovation in the Drupal community and get to 8.1, 8.2, 8.3, and I’m a lot less interested in Drupal 9 right now.

Holly Ross (Executive Director, Drupal Association): How much time have you got?

Bastian Widmer (Development and Operations Engineer, Amazee Labs): Let’s first finish Drupal 8.

Robert Vandenburg (President and CEO, Lingotek): When is Drupal 9 coming out? Never! When pigs fly!

Fabian Franz (Senior Performance Engineer, Technical Lead, Tag1 Consulting): I’m still thinking about Drupal 7.

Kieran Lal (Technical Director, Corporate Development, Acquia): I actually know the exact time... When it’s ready.

Tags:  DrupalCon DrupalCon Amsterdam Video Video: 
Catégories: Elsewhere

NEWMEDIA: Improve your Frontend Toolset with Grunt and LibSass

lun, 27/04/2015 - 17:26
Improve your Frontend Toolset with Grunt and LibSassLearn how you can leverage Grunt and LibSass as groundwork to improve your Frontend Development process and deliver better optimized sites for clients.

At newmedia we've been utilizing Sass and Compass compiled with Ruby for CSS Preprocessing for quite some time now in our Drupal projects. While this toolset has served us well, the toolset for Frontend Developers has been growing and improving tremendously as time goes on. Thus, we want to leverage those tools not only to improve our day-to-day development tasks, but more importantly to better provide more optimized websites for our clients.

In this post we will walk through overhauling our Frontend tooling with Grunt and LibSass, what's involved, and what the benefits are for clients. For the purpose of this article, we're just going to focus on getting Grunt and LibSass up and running - from there the heavy lifting is done, and you're free to expand on your Grunt tasks as you see fit.

What's the client benefit?

Implementing these tools allows us to work faster and spend less time waiting for tools to run. The other key benefit is that, since Grunt runs arbitrary tasks, we can add more tools to ensure our end product is optimized - not just CSS, but also Javascript, images, and more, resulting in all-around faster-loading websites.

What are these Frontend tools & why are we using them?

Grunt is a task runner built in Javascript that leverages node.js. Currently, there are two popular task runner projects: Grunt and Gulp. While there are slight pros and cons between the two projects, we decided to implement Grunt for our Drupal projects, as our Wordpress team had already begun to use Grunt, and we wanted to converge some of our tooling and processes.

LibSass is an implementation of the Sass compiler written in C instead of Ruby. The primary benefit over the original Ruby compiler is a tremendous boost in speed resulting in much faster compile times.

Note on LibSass: Unfortunately LibSass does not yet have feature parity with Ruby Sass, but it's not too far off and continues to improve. This Sass Compatibility reference is handy for specific features that may be missing. Personally, I have yet to hit an issue with feature parity, but your mileage may vary.

Get the prerequisites in place

You will need node.js if you don't have it already. I suggest using the "n" version management tool to help manage your node install:

Once you have n installed, install the current stable version of node:

n stable

Next, you'll need to get a couple node modules installed globally: grunt-cli, the commandline interface for grunt, and bower, a dependency manager for web projects.

npm install -g grunt-cli npm install -g bower

From here, many of the node modules we'll need can be managed at a project level.

Setting up Grunt for your project

Now that we have our prerequisites in place, we need to set up three files within our project:

  1. package.json to manage our project-level node dependencies
  2. Gruntfile.js to define our tasks
  3. bower.json will be used to define our sass library dependencies (in our case, singularity and breakpoint).

Special note on Drupal projects: Currently, placing node_modules within Drupal's directory can potentially cause it to crash, and otherwise could negatively impact performance. We structure our repository so that we have the Drupal directory contained in a folder called docroot, so we handle node at the root level of our project repo above the Drupal directory, rather than at the theme level. See these Drupal Core issues for more information:


Here's our example package.json:

{ "name": "newmedia", "version": "0.0.1", "description": "newmedia grunt tools", "devDependencies": { "grunt": "^0.4.5", "grunt-contrib-watch": "^0.6.1", "grunt-sass": "^0.18.1", "load-grunt-tasks": "^3.1.0" } }

The devDependencies section defines the node modules we're using:

  • grunt (Grunt itself is installed on a per-project basis, only the commandline interface grunt-cli is installed globally),
  • "grunt-contrib-watch", which provides a watch tool (think sass watch or compass watch),
  • grunt-sass, which will bring in and manage libsass for us, and
  • load-grunt-tasks, which allows us to automatically load our grunt dependencies in, rather than manually specifying each one in our Gruntfile.js

As times goes on, you'll likely want to add dependencies to your toolset. Adding them with "npm install [name] --save-dev" will download the module for you and automatically add it to your package.json.


Using the Ruby Sass compiler, you use Bundler to manage your Sass library dependencies. Bower will take the place of that in our Grunt/LibSass workflow:

{ "name": "newmedia", "version": "0.0.1", "description": "newmedia build dependencies", "authors": [ "NEWMEDIA!" ], "ignore": [ "**/.*", "node_modules", "bower_components", "test", "tests" ], "devDependencies": { "breakpoint-sass": "~2.5.0", "singularity": "~1.6.2" } } Gruntfile.js

Now that we have dependency management out of the way, we can setup our tasks. Here's our example Gruntfile:

module.exports = function(grunt) { // Load tasks automatically with 'load-grunt-tasks' plugin. require('load-grunt-tasks')(grunt); // Define our theme directory var themeDir = 'path/to /theme'; // Specify where to find dependencies we load in with Bower var sassLib = ['bower_components']; // Define the CSS files we want compiled from SCSS files var sassFiles = {}; sassFiles[themeDir + '/css/style.css'] = themeDir + '/scss/style.scss'; sassFiles[themeDir + '/css/print.css'] = themeDir + '/scss/print.scss'; // Project configuration. grunt.initConfig({ sass: { dev: { options: { sourceMap: true, outputStyle: 'expanded', includePaths: sassLib }, files: sassFiles, }, build: { options: { sourceMap: false, outputStyle: 'compressed', includePaths: sassLib }, files: sassFiles, } }, watch: { sass: { files: ['**/*.scss'], tasks: ['sass'], } }, }); // Default task(s). grunt.registerTask('default', ['sass:build']); grunt.registerTask('dev', ['sass:dev']); grunt.registerTask('build', ['sass:build']); }; Changes to your Sass

Now that we have the tools in place, we will need to update how we import our sass libraries. Fortunately this is a simple change. Here are our existing imports:

@import "breakpoint"; @import "singularitygs";

These imports get updated to:

@import 'breakpoint-sass/stylesheets/breakpoint'; @import 'singularity/stylesheets/singularitygs';

The exact change to your Sass imports may be different depending on the library. To determine the path you need to use, add the library to bower.json, and look inside bower_components to locate the library and determine the path to the main scss file to import.

Note on Compass

At the time of writing this post, Compass is still dependent on Ruby and can't be used with LibSass. Depending on your case, there are a couple options. If you are using Compass mixins and want to continue to use them, there is a compass-mixins library you can use with LibSass. If you primarily use Compass to handle vendor prefixes, you might want to look at adding Autoprefixer to your Grunt task instead.. If you're using other libraries that depend on Compass, it's likely that even using the compass-mixins library, you won't be able to use those libraries with LibSass.

Ready to Go!

At this point you should be in a good place to try running your grunt task. In our example, we have two defined tasks, build and dev, as well as our watch task. Try running "grunt dev" to do a one-time run. Once you are getting successful task runs, you are ready to start working on your project! You can now use "grunt watch" to detect changes and automatically run tasks.

You're also now at a good point to look at adding additional tasks to your workflow. Some suggestions would be to add tasks to handle optimizing your Javascript and image assets. You can find an expansive selection of tasks on the official Grunt Website’s plugin directory.

Catégories: Elsewhere