Drupal

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

drupal.org aggregator - Thu, 01/11/2018 - 09:20

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

Drupal Dev Thursdays: Post here with development questions or discussion

Drupal - Open Source Content Platform - Thu, 01/11/2018 - 09:07

This is the weekly thread for development questions or chit-chat that doesn't belong in the Monday Beginner Questions thread. All questions/comments/ranting about Drupal dev is fair game.

(Check out the weekly post schedule in the sidebar)

submitted by /u/AutoModerator
[link] [comments]

Mark Shropshire: Drupal SEO Presentation at CharDUG

drupal.org aggregator - Thu, 01/11/2018 - 07:30

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

Agiledrop.com Blog: AGILEDROP: Who will get the control of personal data after GDPR?

drupal.org aggregator - Thu, 01/11/2018 - 04:36
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

drupal.org aggregator - Thu, 01/11/2018 - 04:04
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

drupal.org aggregator - Thu, 01/11/2018 - 02:30
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

Oauth2 JWT SSO

drupal.org - Modules - Wed, 01/10/2018 - 22:03

An Oauth2 JWT Single Sign On module.

Categories: Drupal

Matomo Analytics

drupal.org - Modules - Wed, 01/10/2018 - 18:17

Adds the Matomo web statistics tracking system to your website.

The module allows you to add the following statistics features to your site:

  • Single/multi domain tracking
  • Selectively track/exclude certain users, roles and pages
  • Monitor what type of links are tracked (downloads, outgoing and mailto)
  • Monitor what files are downloaded from your pages
  • Cache the Piwik code on your local server for improved page loading times
  • Custom variables support with tokens (D7 only)
  • Custom code snippets
  • Site Search
  • Drupal messages tracking
  • Modal dialog tracking (Colorbox)
  • Access denied (403) and Page not found (404) tracking
  • User ID tracking across devices
  • DoNotTrack support
Categories: Drupal

Drupal 8 Video Series

Drupal - Open Source Content Platform - Wed, 01/10/2018 - 17:52

Hey,

Has anyone watched any decent Drupal 8 video series that go through the entire process of setting up an example Drupal 8 site for some business or app?

Thanks!

submitted by /u/bigbastardnate
[link] [comments]

Commerce Extended Quantity

drupal.org - Modules - Wed, 01/10/2018 - 17:03

Allows to set quantity field's default_value, step, min, max, prefix and suffix on a form display widget. Additionally, validates user input on the field and order item availability both on the Add to cart form and Quantity column of the Shopping cart table. See more on the module's Github repository:

https://github.com/drugan/commerce_xquantity

Categories: Drupal

Drupal Association blog: DrupalCon Vienna Recap

drupal.org aggregator - Wed, 01/10/2018 - 17:01

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

Commerce simple hierarchical select

drupal.org - Modules - Wed, 01/10/2018 - 15:35

The SHS module is a very useful tool for improving Drupal's core functionality when using taxonomies that have hierarchy. In particular, it provides a better UI for entity fields (for taxonomies), and for exposed filters in views (for taxonomies).

However, Drupal Commerce products are not content types. If you have a taxonomy field on a commerce product, with hierarchy, SHS is not available in Views to create the desired exposed filters.

Categories: Drupal

Dries Buytaert: How to decouple Drupal in 2018?

drupal.org aggregator - Wed, 01/10/2018 - 14:16

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. As a result, Acquia now offers Node.js hosting, which means it's never been easier to implement decoupled Drupal on the Acquia platform.

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.

Conclusion

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. Moreover, for Acquia customers, Acquia's recent launch of Node.js hosting on Acquia Cloud means that developers can leverage the most modern approaches in JavaScript while benefiting from Drupal's capabilities as a content repository.

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

How to decouple Drupal in 2018

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. As a result, Acquia now offers Node.js hosting, which means it's never been easier to implement decoupled Drupal on the Acquia platform.

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.

Conclusion

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. Moreover, for Acquia customers, Acquia's recent launch of Node.js hosting on Acquia Cloud means that developers can leverage the most modern approaches in JavaScript while benefiting from Drupal's capabilities as a content repository.

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

Node view published override

drupal.org - Modules - Wed, 01/10/2018 - 11:45

This is a simple module that override View published content permission provided by core.

The following permissions will be added to each content type:
view any published content
view own published content

Installation
Please follow instructions in README file

Support
Please report any issue to module issue queue

Categories: Drupal

SHOPTASY

drupal.org - Modules - Wed, 01/10/2018 - 11:23
Categories: Drupal

Pages