Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 13 hours 23 min ago

Amazee Labs: Don’t Push it: Using GraphQL in Twig

15 January 2018 - 1:40am
Don’t Push it: Using GraphQL in Twig

Using GraphQL in Drupal with Twig instead of React, Vue or the next month's javascript framework might sound like a crazy idea, but I assure you it’s worth thinking about.

Philipp Melab Mon, 01/15/2018 - 10:40

Decoupling is all the rage. Javascript frontends with entirely independent backends are state of the art for any self-respecting website right now. But sometimes it’s not worth the cost and the project simply does not justify the full Drupal + React technology stack.

Besides the technological benefits of a javascript based frontend like load times and responsiveness, there’s another reason why this approach is so popular: It moves control to the frontend, concept and design unit, which matches project workflows a lot better.

Status quo

Traditionally Drupal defines data structures that provide a “standard” rendered output, which then can be adopted by the so-called “theme developer” to meet the clients' requirements. Template overrides, preprocess functions, Display Suite, Panels, Layouts - there are myriads of ways how to do this, and twice as many opinions determining the right one. When taking over a project the first thing is to figure out how it was approached and where the rendered information actually comes from. Templates only have variables that are populated during processing or preprocessing and altered in modules or themes, which makes it very hard to reason with the data flow, if you were not the person that conceived it in the first place.

There are ideas to improve the situation, but regarding the success of decoupling, perhaps it’s time to approach the problem from a different angle.

Push versus Pull

The current push model used by Drupal scatters responsibilities across modules, preprocess functions and templates. The controller calls the view builder to prepare a “renderable” that is altered 101 times and results in a set of variables that might or might not be required by the current theme’s template.

If we would turn this around and let the template define it’s data requirements (as it happens in decoupled projects naturally), we could achieve a much clearer data flow and increase readability and maintainability significantly.

And that’s what the GraphQL Twig module is supposed to do. It allows us to add GraphQL queries to any Twig template, which will be picked up during rendering and used to populate the template with data.

A simple example node.html.twig:

{#graphql query($node: String!) { node:nodeById(id: $node) { title:entityLabel ... on NodeArticle { body { processed } } } } #} <h1>{{ }}</h1> {% if %} <div class="body">{{ }}</div> {% endif %}


This is already enough to pull the information we need and render it. Let’s have a look at what this does:

The graphql comment on top will be picked up by the module. When the template is rendered, it tries to match the queries input arguments to the current template variables, runs the GraphQL query and passes the result as a new graphql variable to the template. Simple as that, no preprocessing required. It works for every theme hook. Be it just one complex node type, an exceptional block or page.html.twig.

Imagine we use GraphQL Views to add a contextual GraphQL field similarArticles that uses SOLR to find similar articles for a given node. It could be used immediately like this:

{#graphql query($node: String!) { node:nodeById(id: $node) { title:entityLabel ... on NodeArticle { body { processed } similarArticles { title:entityLabel url:entityUrl { alias } } } } } #} <h1>{{ }}</h1> {% if %} <div class="body">{{ }}</div> {% endif %} {% if %} <h2>Similar articles</h2> <ul> {% for article in %} <li> <a href="">{{article.title}}</a> </li> {% endfor %} </ul> {% endif %}


The module even scans included templates for query fragments, so the rendering of the “similar article” teaser could be moved to a separate component:

node.html.twig {#graphql query($node: String!) { node:nodeById(id: $node) { title:entityLabel ... on NodeArticle { body { processed } similarArticles { ... NodeTeaser } } } } #} <h1>{{ }}</h1> {% if %} <div class="body">{{ }}</div> {% endif %} {% if %} <h2>Similar articles</h2> <ul> {% for article in %} <li> {% include 'node-teaser.twig' with { node: article } %} </li> {% endfor %} </ul> {% endif %}


node-teaser.twig {#graphql fragment NodeTeaser on Node { title:entityLabel url:entityUrl { alias } } #} <a href="">{{node.title}}</a>


No preprocessing, a clear path where data flows and true separation of concerns. The backend provides generic data sources (e.g. the similarArticles field) that can be used by the product development team at will. All without the cost of a fully decoupled setup. And the possibility to replace single theme hooks allows us to use existing Drupal rendering when it fits and switch to the pull-model wherever we would have to use complex layout modules or preprocessing functions to meet the requirements of the project.

Future development

There are some ideas for additional features, like mutation based forms and smarter scanning for query fragments, but first and foremost we would love to get feedback and opinions on this whole concept. So if you are interested, join on Slack or GitHub and let us know!

Categories: Drupal Blog: AGILEDROP: Our blog posts from December

14 January 2018 - 4:42pm
You have already seen what Drupal blogs we trending in the previous month, and now it is time to look at all our blog post we wrote. Here are the blog topics we covered in December.   The first blog post in December was Why Drupal is the most secure CMS. It explains and shows the reasons why Drupal is a secure CMS even though many people doubt that due to being open source. The second was In the beginning, Drupal had an ambition. We talked about Dries keynote from DrupalCon Vienna and his statement that Drupal is for ambitious digital experiences. What are three critical ingredients for… READ MORE
Categories: Drupal

Lullabot: The Out of the Box Initiative

13 January 2018 - 7:42am
Matt and Mike the ins and outs of Out of the Box initiative, which endeavors to showcase Drupal's power "out of the box." They are joined by some of the developers from the Out of the Box initiative.
Categories: Drupal

Joachim's blog: Triggering events on the fly

12 January 2018 - 1:45pm

As far as I know, there's nothing (yet) for triggering an arbitrary event. The complication is that every event uses a unique event class, whose constructor requires specific things passing, such as entities pertaining to the event.

Today I wanted to test the emails that Commerce sends when an order completes, and to avoid having to keep buying a product and sending it through checkout, I figured I'd mock the event object with Prophecy, mocking the methods that the OrderReceiptSubscriber calls (this is the class that does the sending of the order emails). Prophecy is a unit testing tool, but its objects can be created outside of PHPUnit quite easily.

Here's my quick code:

$order = entity_load('commerce_order', ORDER_ID); $prophet = new \Prophecy\Prophet; $event = $prophet->prophesize('Drupal\state_machine\Event\WorkflowTransitionEvent'); $event->getEntity()->willReturn($order); $subscriber = \Drupal::service('commerce_order.order_receipt_subscriber'); $subscriber->sendOrderReceipt($event->reveal());

Could some sort of generic tool be created for triggering any event in Drupal? Perhaps. We could use reflection to detect the methods on the event class, but at some point we need some real data for the event listeners to do something with. Here, I needed to load a specific order entity and to know which method on the event class returns it. For another event, I'd need some completely different entities and different methods.

We could maybe detect the type that the event method return (by sniffing in the docblock... once we go full PHP 7, we could use reflection on the return type), and the present an admin UI that shows a form element for each method, allowing you to enter an entity ID or a scalar value.

Still, you'd need to look at the code you want to run, the event listener, to know which of those you'd actually want to fill in.

Would it same more time than cobbling together code like the above? Only if you multiply it by a sufficiently large number of developers, as is the case with many developer tools.

It's the sort of idea I might have tinkered with back in the days when I had time. As it is, I'm just going to throw this idea out in the open.

Tags: eventsdeveloper tools
Categories: Drupal

Drupal core announcements: Drupal 8.5.0 will be released March 7; alpha begins week of January 17

12 January 2018 - 12:12pm

Drupal 8.5.0, the next planned minor release of Drupal 8, is scheduled for Wednesday, March 7, 2018. Minor releases include new features, usability improvements, and backwards-compatible API improvements. Here's what this means now for core patches.

The goal of the alpha phase is to begin the preparation of the minor release and provide a testing target for theme or module developers and site owners. Alpha releases include most of the new features, API additions, and disruptive changes that will be in the upcoming minor version.

Drupal 8.5.0-alpha1 will be released the week of January 17

In preparation for the minor release, Drupal 8.5.x will enter the alpha phase the week of January 17, 2018. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release. (More information on alpha and beta releases.)

  • Developers and site owners can begin testing the alpha next week.

  • The 8.6.x branch of core has been created, and future feature and API additions will be targeted against that branch instead of 8.5.x. All outstanding issues filed against 8.5.x will be automatically migrated to 8.6.

  • All issues filed against 8.4.x will then be migrated to 8.5.x, and subsequent bug reports should be targeted against the 8.5.x branch.

  • During the alpha phase, core issues will be committed according to the following policy:

    1. Most issues that are allowed for patch releases will be committed to 8.5.x and 8.6.x.

    2. Drupal 8.4.x will receive only critical bugfixes in preparation for its final patch release window. (Drupal 8.3.x and older versions are not supported anymore and changes are not made to those branches.)

    3. Most issues that are only allowed in minor releases will be committed to 8.6.x only. A few strategic issues may be backported to 8.5.x, but only at committer discretion after the issue is fixed in 8.6.x (so leave them set to 8.6.x unless you are a committer), and only up until the beta deadline.

Drupal 8.5.0-beta1 will be released the week of February 7

Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Even if an issue is pending in the Reviewed & Tested by the Community (RTBC) queue when the commit freeze for the beta begins, it will be committed to the next minor release only.

The release candidate phase will begin the week of February 21, and we will post further details at that time. See the summarized key dates in the release cycle, allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

Categories: Drupal

Drupal blog: How to decouple Drupal in 2018

12 January 2018 - 10:19am

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

In this post, I'm providing some guidance on how and when to decouple Drupal.

Almost two years ago, I had written a blog post called "How should you decouple Drupal?". Many people have found the flowchart in that post to be useful in their decision-making on how to approach their Drupal architectures. Since that point, Drupal, its community, and the surrounding market have evolved, and the original flowchart needs a big update.

Drupal's API-first initiative has introduced new capabilities, and we've seen the advent of the Waterwheel ecosystem and API-first distributions like Reservoir, Headless Lightning, and Contenta. More developers both inside and outside the Drupal community are experimenting with Node.js and adopting fully decoupled architectures.

Let's start with the new flowchart in full:

All the ways to decouple Drupal

The traditional approach to Drupal architecture, also referred to as coupled Drupal, is a monolithic implementation where Drupal maintains control over all front-end and back-end concerns. This is Drupal as we've known it — ideal for traditional websites. If you're a content creator, keeping Drupal in its coupled form is the optimal approach, especially if you want to achieve a fast time to market without as much reliance on front-end developers. But traditional Drupal 8 also remains a great approach for developers who love Drupal 8 and want it to own the entire stack.

A second approach, progressively decoupled Drupal, offers an approach that strikes a balance between editorial needs like layout management and developer desires to use more JavaScript, by interpolating a JavaScript framework into the Drupal front end. Progressive decoupling is in fact a spectrum, whether it is Drupal only rendering the page's shell and populating initial data — or JavaScript only controlling explicitly delineated sections of the page. Progressively decoupled Drupal hasn't taken the world by storm, likely because it's a mixture of both JavaScript and PHP and doesn't take advantage of server-side rendering via Node.js. Nonetheless, it's an attractive approach because it makes more compromises and offers features important to both editors and developers.

Last but not least, fully decoupled Drupal has gained more attention in recent years as the growth of JavaScript continues with no signs of slowing down. This involves a complete separation of concerns between the structure of your content and its presentation. In short, it's like treating your web experience as just another application that needs to be served content. Even though it results in a loss of some out-of-the-box CMS functionality such as in-place editing or content preview, it's been popular because of the freedom and control it offers front-end developers.

What do you intend to build?

The most important question to ask is what you are trying to build.

  1. If your plan is to create a single standalone website or web application, decoupling Drupal may or may not be the right choice based on the must-have features your developers and editors are asking for.
  2. If your plan is to create multiple experiences (including web, native mobile, IoT, etc.), you can use Drupal to provide web service APIs that serve content to other experiences, either as (a) a content repository with no public-facing component or (b) a traditional website that is also a content repository at the same time.

Ultimately, your needs will determine the usefulness of decoupled Drupal for your use case. There is no technical reason to decouple if you're building a standalone website that needs editorial capabilities, but that doesn't mean people don't prefer to decouple because of their preference for JavaScript over PHP. Nonetheless, you need to pay close attention to the needs of your editors and ensure you aren't removing crucial features by using a decoupled approach. By the same token, you can't avoid decoupling Drupal if you're using it as a content repository for IoT or native applications. The next part of the flowchart will help you weigh those trade-offs.

Today, Drupal makes it much easier to build applications consuming decoupled Drupal. Even if you're using Drupal as a content repository to serve content to other applications, well-understood specifications like JSON API, GraphQL, OpenAPI, and CouchDB significantly lower its learning curve and open the door to tooling ecosystems provided by the communities who wrote those standards. In addition, there are now API-first distributions optimized to serve as content repositories and SDKs like Waterwheel.js that help developers "speak" Drupal.

Are there things you can't live without?

Perhaps most critical to any decision to decouple Drupal is the must-have feature set desired for both editors and developers. In order to determine whether you should use a decoupled Drupal, it's important to isolate which features are most valuable for your editors and developers. Unfortunately, there is are no black-and-white answers here; every project will have to weigh the different pros and cons.

For example, many marketing teams choose a CMS because they want to create landing pages, and a CMS gives them the ability to lay out content on a page, quickly reorganize a page and more. The ability to do all this without the aid of a developer can make or break a CMS in marketers' eyes. Similarly, many digital marketers value the option to edit content in the context of its preview and to do so across various workflow states. These kind of features typically get lost in a fully decoupled setting where Drupal does not exert control over the front end.

On the other hand, the need for control over the visual presentation of content can hinder developers who want to craft nuanced interactions or build user experiences in a particular way. Moreover, developer teams often want to use the latest and greatest technologies, and JavaScript is no exception. Nowadays, more JavaScript developers are including modern techniques, like server-side rendering and ES6 transpilation, in their toolboxes, and this is something decision-makers should take into account as well.

How you reconcile this tension between developers' needs and editors' requirements will dictate which approach you choose. For teams that have an entirely editorial focus and lack developer resources — or whose needs are focused on the ability to edit, place, and preview content in context — decoupling Drupal will remove all of the critical linkages within Drupal that allow editors to make such visual changes. But for teams with developers itching to have more flexibility and who don't need to cater to editors or marketers, fully decoupled Drupal can be freeing and allow developers to explore new paradigms in the industry — with the caveat that many of those features that editors value are now unavailable.

What will the future hold?

In the future, and in light of the rapid evolution of decoupled Drupal, my hope is that Drupal keeps shrinking the gap between developers and editors. After all, this was the original goal of the CMS in the first place: to help content authors write and assemble their own websites. Drupal's history has always been a balancing act between editorial needs and developers' needs, even as the number of experiences driven by Drupal grows.

I believe the next big hurdle is how to begin enabling marketers to administer all of the other channels appearing now and in the future with as much ease as they manage websites in Drupal today. In an ideal future, a content creator can build a content model once, preview content on every channel, and use familiar tools to edit and place content, regardless of whether the channel in question is mobile, chatbots, digital signs, or even augmented reality.

Today, developers are beginning to use Drupal not just as a content repository for their various applications but also as a means to create custom editorial interfaces. It's my hope that we'll see more experimentation around conceiving new editorial interfaces that help give content creators the control they need over a growing number of channels. At that point, I'm sure we'll need another new flowchart.


Thankfully, Drupal is in the right place at the right time. We've anticipated the new world of decoupled CMS architectures with web services in Drupal 8 and older contributed modules. More recently, API-first distributions, SDKs, and even reference applications in Ember and React are giving developers who have never heard of Drupal the tools to interact with it in unprecedented ways.

Unlike many other content management systems, old and new, Drupal provides a spectrum of architectural possibilities tuned to the diverse needs of different organizations. This flexibility between fully decoupling Drupal, progressively decoupling it, and traditional Drupal — in addition to each solution's proven robustness in the wild — gives teams the ability to make an educated decision about the best approach for them. This optionality sets Drupal apart from new headless content management systems and most SaaS platforms, and it also shows Drupal's maturity as a decoupled CMS over WordPress. In other words, it doesn't matter what the team looks like or what the project's requirements are; Drupal has the answer.

Special thanks to Preston So for contributions to this blog post and to Alex Bronstein, Angie Byron, Gabe Sullice, Samuel Mortenson, Ted Bowman and Wim Leers for their feedback during the writing process.

Categories: Drupal

Valuebound: A beginners guide to caching in Drupal 8

12 January 2018 - 8:38am

Caching is a popular technique to optimize the performance of a website. It is a process that stores web data (HTML, CSS, Image) in some accessible space. Moreover, a cache is a detailed information of a validity of a resource. This information defines for how long the resource is valid and should not be considered stale. The information can be stored at every level right from the original server to intermediate proxies to the browser.

Here you will get to learn about what key/value pairs in the header mean and Cacheability metadata in Drupal 8.

Every request or response contains a HTTP header, which provides additional information about the request/response. This…

Categories: Drupal

CTI Digital: Drupalcamp London 2018

12 January 2018 - 6:46am

Drupalcamp London returns in March for its 6th year. As the largest Drupal camp in Europe, it provides a scale of high-quality knowledge I rarely see elsewhere. If you’re new to Drupalcons and camps, Drupalcamp is a three-day knowledge-sharing conference in London that attracts a wide variety of over 600 Drupal stakeholders, including developers, agencies, business owners, and end users.

Categories: Drupal

Amazee Labs: The stalker - a story

12 January 2018 - 2:27am
The stalker - a story

The #techfiction story about how a backend developer feels as he starts working on his first frontend task.

Tadej Basa Fri, 01/12/2018 - 11:27

#techfiction #noir

It’s late. The cold breeze stings my face as I wander the dark alleys of the City. Now and then dim neon lights cut through my shadows. I’ve been wandering around aimlessly for what feels like hours. Now I find myself standing in front of Avery’s again. I enter, in a force of habit.

There are a bunch of familiar faces. Christmas is around the corner, and everybody’s celebrating, but I’m not in the mood for “jingle bells” today. I grab an empty chair at the bar and order a shot of Glenlivet.

'What’s with the grim face, Tony?'

It didn’t last long. Peter approaches holding a bottle of beer in his right hand. I can’t lie to him. He’ll see right through me.

'She’s gone, Peter. I’ll never see her again.'

'Oh, come on! There’s plenty of fish in the sea. Here, I’ve got something that might cheer you up.'

He puts down his beer and reaches into his leather jacket, pulls out a crumpled piece of paper and hands it to me. Just a short note written on it, smeared bold letters read “GZA-220”.

'What’s this?'

'I was going to give this to Sanchez, but looks like you need it more.'

Sanchez. He’s been stealing assignments from me for months laughing it up while I’ll cry myself blind, bored to death, working day in and day out on those seemingly insignificant backend nuisances. I might relish this, just to get back at him.

'Come on! Look it up.'

It turns out to be a task ID on JIRA, the project management system we use internally. I put my machine on the desk, start up the browser and navigate straight to the task page.

'It‘s a frontend task,' I mumble out of pure surprise.

'You might need some change,' he says.

He’s right. I need something to regain focus. A new kind of challenge.

'Ok. Assign that to me. I’ll do it.'

The task is as follows. A website is composed of horizontally stacked regions each having a background colour setting defined by the editor. When hovering over the areas with a blue background setting a radial smudge should follow the mouse cursor in the background.

I don’t waste any time and quickly employ my usual routine: look it up on Google. Surely someone’s already done something similar, and I don’t want to waste my precious time. I’ve got to get back to feeling sorry for myself.

Here it is, right off the bat, almost the exact same thing. But after a quick investigation, I find it uses CSS, and a transform style attribute changes as I move the mouse around. While this looks good, I’ll try another approach, draw directly on canvas and check how this performs. So for every blue region, I just add another "canvas" and resize it so that it covers the whole background area. A global variable will keep track of the smudge’s position and other movement data.

I’ll set up my mouse move listener and a draw loop and quickly find out that scrolling the document leaves my smudge hanging motionless. I need to treat the scroll same as a vertical mouse move.

It’s getting serious now. I light up a cigarette.

I used to be a non-smoker. Then I met my buddy George back in April. We had a couple of drinks, and he offered me one of his Luckies. Now I’m sucking them down like there’s no tomorrow. Two packs a day.

I've been sitting here for two hours already. Time passes by so quickly when the mind is busy. I’ve got something going on, but I see problems already. We might have multiple disconnected regions on the same page, and the effect has to flow through them seamlessly. I have to track the global coordinates and just draw the damn thing with a local offset. If the regions are far apart, the smudge might not be visible in all of them at once. No sense in redrawing the canvas if the thing is entirely out of its bounds. We can calculate if the smudge is inside of each rectangular region and omit to redraw it when they don’t overlap. I find some useful math shenanigans on StackExchange and plug it in.

My complete draw loop looks like this:

A figure reflects in my excessively glossy Dell XPS screen.

'What going on here? Is it still 2015? Ever heard of requestAnimationFrame()?'

Douglas. His real name is Bob-Douglas, but I just call him Dick. Funny guy. Rumors go he can recite the complete team channel conversation from Slack by heart.

'What are you talking about? No, I’ve never heard of it… I’ve never heard of anything. I don’t even know what I’m doing here.'

Let’s see what Dick is trying to tell me. According to the documentation, by calling window.requestAnimationFrame() you’re telling the browser that you wish to animate something and that the specified callback should be invoked before the repaint. This is better for performance reasons as requestAnimationFrame() calls are paused when running in background tabs.

This approach needs a little adjustment. If I keep calling requestAnimationFrame() the browser will try to keep up with my screen’s refresh rate and the animation is too quick. I’ll slow it down to 60Hz by checking the timestamp parameter that gets passed into my callback. Much better.

My job here is done. I close the lid, take another shot of whisky and head out on the street. I’ve got to find her. I’ve got to see her again. Don’t try to stop me and don’t you come looking for me. It’s a big city, and I’ll be hiding in the shadows. The best chance you’ve got is hearing the receding echoes of my footsteps as I fade into the darkness.


Can you spot the stalker?


Categories: Drupal

Roman Agabekov: Making your Drupal web server secure, step by step

11 January 2018 - 10:53pm
Making your Drupal web server secure, step by step

In the previous article, we covered How to stay out of SPAM folder? and today we will learn how to secure our Drupal web server.

Setting up Firewall

So, we have Debian OS powering our Drupal web server, and we need to make it secure, adjust everything so as to minimize all risks. First of, we want to configure the firewall. Basic stuff. Our "weapon of choice" here is IPTables.

admin Fri, 01/12/2018 - 06:53 Теги
Categories: Drupal

Freelock : The Spectre of a Meltdown

11 January 2018 - 4:31pm
The Spectre of a Meltdown John Locke Thu, 01/11/2018 - 17:31

The news was supposed to come out this Tuesday, but it leaked early. Last week we learned about three variations of a new class of attacks on modern computing, before many vendors could release a patch -- and we come to find out that the root cause may be entirely unpatchable, and can only be fixed by buying new computers.

Disaster Recovery Drupal Planet hacked site maintenance Meltdown Security Spectre
Categories: Drupal

Drupal Commerce: Drupal Commerce 2.x: 2017 in review

11 January 2018 - 3:45pm

Now that 2017 is over and we’re back from our well deserved holidays, it’s time to look at what the Drupal Commerce community accomplished over the past year.

There is no doubt that Drupal Commerce is one of the largest and most active projects in the Drupal community. The #commerce channel is now the most active channel on the Drupal Slack, with 550 members. Over a hundred modules have received contributions from several hundred contributors working for dozens of different agencies. Just a few months after the initial stable release, there are over 2000 reported installations with new case studies appearing every week!

Let’s take a closer look.

Categories: Drupal

Acro Media: Drupal Commerce 2: How to Set up Taxes

11 January 2018 - 3:10pm

Setting up taxes in Drupal Commerce 2 is a snap. The component comes bundled with some predefined tax rate plugins, such as Canadian sales tax and European Union VAT. This means that enabling these tax types is as easy as checking a box. More complicated tax regions, like you would find in the United States, have integrations available with services such as Avalara AvaTax, TaxCloud and more. Custom tax types can also be created out-of-the-box.

In this Acro Media Tech Talk video, we user our Urban Hipster Commerce 2 demo site to quickly show you how to configure the predefined tax plugins as well as add a custom tax type. 

Its important to note that this video was recorded before the official 2.0 release of Drupal Commerce. The current state of the Taxes sub-module is even more robust than what you see here, and additional plugins have been added out-of-the-box. Documentation is also still lacking at the time of this post, however, we've added a link anyway so that whoever finds this in the future will benefit.

Urban Hipster Commerce 2 Demo site

This video was created using the Urban Hipster Commerce 2 demo site. We've built this site to show the adaptability of the Drupal 8, Commerce 2 platform. Most of what you see is out-of-the-box functionality combined with expert configuration and theming.

More from Acro Media Drupal modules used in this video Additional resources

Categories: Drupal

Phase2: How Digital Marketing is Evolving with Drupal

11 January 2018 - 9:32am

With exponential growth in marketing tools and website builders, why are marketers still adopting Drupal and maintaining their existing Drupal systems? And how has Drupal evolved to become a crucial piece of leading brands’ martech ecosystems?

For marketing decision makers, there are many reasons to choose and stick with Drupal, including:  

  • Designed to integrate with other marketing tools

  • Increased administrative efficiencies

Categories: Drupal

Community: Nominations are now open for the 2018 Aaron Winborn Award

11 January 2018 - 6:20am

The Drupal Community Working Group is pleased to announce that nominations for the 2018 Aaron Winborn Award are now open. This annual award recognizes an individual who demonstrates personal integrity, kindness, and above-and-beyond commitment to the Drupal community. It will include a scholarship and stipend to attend DrupalCon and recognition in a plenary session at the event.

Nominations are open to not only well-known Drupal contributors, but also people who have made a big impact in their local or regional community. If you know of someone who has made a big difference to any number of people in our community, we want to hear about it.

This award was created in honor of long-time Drupal contributor Aaron Winborn, whose battle with Amyotrophic lateral sclerosis (ALS) (also referred to as Lou Gehrig's Disease) came to an end on March 24, 2015. Based on a suggestion by Hans Riemenschneider, the Community Working Group, with the support of the Drupal Association, launched the Aaron Winborn Award.

Nominations are open until March 1, 2018. A committee consisting of the Community Working Group members and past award winners will select a winner from the submissions. Members of this committee and previous winners are exempt from winning the award.

Previous winners of the award are:

  • 2015: Cathy Theys
  • 2016: Gábor Hojtsy
  • 2017: Nikki Stevens

If you know someone amazing who should benefit from this award you can make your nomination.

Categories: Drupal

Mark Shropshire: Drupal SEO Presentation at CharDUG

11 January 2018 - 4:30am

I had a great time talking general and Drupal SEO at last night's CharDUG meetup! Just wanted to drop my slide deck here for reference. There are a lot of fantastic links in the deck.

Thanks to Mediacurrent for having a great culture for internal training. They invested in a large group of staff to go through the SEO Olympian program. I also want to thank the Mediacurrent Digital Strategy team for putting this training together. This training inspired me to dig more into SEO and put together this presentation and live demo of Drupal SEO modules.

I hope to present this talk again in the future.

Blog Category: 
Categories: Drupal Blog: AGILEDROP: Who will get the control of personal data after GDPR?

11 January 2018 - 1:36am
When taking steps in the digital arena footprints are left behind. While browsing websites or when accepting the terms of use of a certain application, data is stored. Data that contains sensitive and personal information (IP address is also a personal information). That is why EU is imposing a new set of rules in the form of General Data Protection Regulation (GDPR). The goal of GDPR is to protect EU citizens from privacy and data breaches in a world never so digitally connected as it is now. The directive was first established in 1995, we have to bear in mind that a lot has changed since… READ MORE
Categories: Drupal

Amazee Labs: Launching Forever Chocolate

11 January 2018 - 1:04am
Launching Forever Chocolate

We are happy to announce the website launch of Forever Chocolate, providing Barry Callebaut with a platform for their initiative to make sustainable chocolate the norm by 2025. 

Sian Wheeler Thu, 01/11/2018 - 10:04

Barry Callebaut is the world’s leading manufacturer of high-quality chocolate and cocoa and considers a sustainable production the only way through which it can continue to thrive as a company. 

To succeed with this ambitious plan by 2025, Barry Callebaut has set the following goals:

  • eradicate child labour from our supply chain

  • lift more than 500,000 cocoa farmers out of poverty

  • become carbon and forest positive

  • have 100% sustainable ingredients in all of our products

The new site was built in collaboration with London based communication agency SalterBaxter. SalterBaxter designed the report with reference to Barry Callebaut’s annual report which is built and published by Amazee Labs. The new report includes certain graphical elements which can optionally be replicated in any upcoming annual report.

Based on the uniform design with big, colourful hero elements and beautifully displayed data the information is easily comprehensible. In addition to its responsiveness, the use of animations adds a lively appearance to the site. To achieve this, the Drupal module "Paragraphs" was used to build all media & text options. From a content editor point of view, this means that anything can be reused anywhere. It is also very easy to replicate selected features for future annual reports.

Categories: Drupal

WeKnow: Switching from Vagrant to Docker

10 January 2018 - 11:30pm
Switching from Vagrant to Docker

Setting up a new local environment can be challenging and really time-consuming if you're doing it from scratch. While this might not be a big deal when working as a single developer on a project, in a team-based scenario it's important to share the same infrastructure configuration. That's why we highly recommended using a tool like Docker to simplify the process.

Last summer, Jesus Manuel Olivas (Project lead) and I started working on a new project, and we had to discuss which setup we should use for the local environments. Since the project was already set up to use Lightning and BLT, we both agreed to use DrupalVM with Vagrant. Everything seemed to work great apart from some permissions conflicts, which we could easily resolve since the project only had two developers at the time.

bonfil1 Thu, 01/11/2018 - 07:30
Categories: Drupal

Drupal Association blog: DrupalCon Vienna Recap

10 January 2018 - 2:01pm

This past September we gathered together in Vienna, Austria to talk all things Drupal. Over 1,600 of us came together to watch keynotes, present sessions, have impromptu conversations in the hallway, and sprint.

One of the hot topics on site was the future of DrupalCon in Europe. The community has rallied around facilitating a large Drupal event in 2018. The Drupal Association continues to focus on 2019 and beyond, and recently posted a call for proposals for licensing DrupalCon in Europe. You can read more about that in Megan's blog post.

We made some changes to the DrupalCon event format for DrupalCon Vienna, in an effort to improve its financial sustainability. While some of these changes were controversial in the run-up to the event, once we all arrived in Vienna there were a lot of highlights - meeting Dries, sprints, anything related to migration, and (of course!) the Viennese Ball! To read the full recap of DrupalCon Vienna, check out these slides.

Beyond Vienna, we have heard requests for previous years' slides. While we're working on a place to archive them on the website - for quick reference, here are the past couple years' presentations:

See you in Nashville!

Categories: Drupal