Drupal Planet

Subscribe to canal de noticias Drupal Planet
Drupal.org - aggregated feeds in category Planet Drupal
Actualizado: hace 8 horas 27 mins

Dries Buytaert: To PESOS or to POSSE?

Mar, 02/06/2018 - 07:43

Yesterday I shared that I uninstalled the Facebook application from my phone. My friend Simon Surtees was quick to text me: "I for one am pleased you have left Facebook. Less Cayman Island pictures!". Not too fast Simon. I never said that I left Facebook or that I'd stop posting on Facebook. Plus, I'll have more Cayman Islands pictures to share soon. :)

As a majority of my friends and family communicate on Facebook and Twitter, I still want to share updates on social media. However, I believe I can do it in a more thoughtful manner that allows me to take back control over my own data. There are a couple of ways I could go about that:

  • I could share my status updates and photos on a service like Facebook or Twitter and then automatically download and publish them to my website.
  • I could publish my status updates and photos on my website first, and then programmatically share them on Facebook, Twitter, etc.

The IndieWeb movement has provided two clever names for these models:

  1. PESOS or Publish Elsewhere, Syndicate (to your) Own Site is a model where publishing begins on third party services, such as Facebook, and then copies can be syndicated to your own site.
  2. POSSE or Publish (on your) Own Site, Syndicate Elsewhere is a publishing model that begins with posting content on your own site first, then syndicating out copies to third party services.

Here is the potential impact of each strategy:

PESOS POSSE Dependence A 3rd party is a required intermediary within the PESOS approach. When the 3rd party platform is down or disappears completely, publishers lose their ability to post new content or retrieve old content. No dependence, as the 3rd party service is an optional endpoint, not a required intermediary. Canonical Non-canonical: the data on the 3rd party is the original and copies on your domain may have to cite 3rd party URLs. Canonical: you have full control over URLs and host the original data. The 3rd party could cite the original URL. Quality Pulling data from 3rd parties services could reduce its quality. For example, images could be degraded or downsized. Full control over the quality of assets on your own site. Ease of use, implementation and maintenance 3rd party platforms make it really easy for users to publish content and you can still benefit from that. For example, you can easily upload images from your phone. The complexity inherent to the PESOS approach includes developing an infrastructure to curate archival copies to your own domain. The POSSE strategy can be significantly more work for the site owner, especially if you want comparable ease of use to 3rd party platforms. A higher level of technical expertise and time investment is likely required.

The goal of this analysis was to understand the pros and cons of how I can own my own content on https://dri.es. While PESOS would be much easier to implement, I decided to go with POSSE. My next step is to figure out my "POSSE plan"; how to quickly and easily share status updates on my Drupal site, how to syndicate them to 3rd party services, how to re-organize my mailing list and RSS feed, and more. If you have any experience with implementing POSSE, feel free to share your takeaways in the comments.

Valuebound: How to Implement Faceted search with Solr in Drupal 8?

Mar, 02/06/2018 - 02:48

Sometimes we need to implement a search functionality that looks similar to some of the renowned e-commerce site search (like Amazon, Flipkart and so on) as per the category, types and all.  For this kind of search, Facet is a good option. So what exactly Faceted search is?

Facet is a module, in Drupal 8, that provides a facility to arrange all the search results as per the category. Basically, it is an arrangement of search results based on categories, content type on indexed terms and content type.

Why we use Facets?

There are various reasons a Facet can be used:

  • It provides a drill-down search facility.
  • It can be used with default search and Solr as well.
  • It shows a number of item count for each…

Roy Scholten: Core strengths

Lun, 02/05/2018 - 21:28
06 Feb 2018 Core strengths

The Designing Connected Content book has arrived. “Plan and model digital products for today and tomorrow.” I have yet to dive in but I see Drupal screenshots and lists of field types like entity reference, long text (formatted), boolean, number (float), etc.

Today a content strategist collegue asked me about that list builder thing in Drupal. Show items of type x, filtered by y, sorted by x and only show fields 1, 3 and 6 of each item. And is it available for Drupal 8 as well?

Yes, that’s 1. Field UI and 2. Views module, which are both part of the Drupal core package.

We take Drupal core features for granted that other systems are still struggling with. They are also features people struggle with in Drupal because of hard to use user interfaces. I would love to see research and design work happen around how we can improve Field UI and Views UI.

Tags book designing connected content drupalplanet content modeling

aleksip.net: Using Pattern Lab in Drupal 7 theme development

Lun, 02/05/2018 - 16:09
After working almost exclusively with the latest and greatest version of Drupal since 2015, I am now facing some Drupal 7 projects. I didn’t want to give up using atomic design and Pattern Lab, so I decided to create a .tpl.php PatternEngine for Pattern Lab.

Ixis.co.uk - Thoughts: Last Month in Drupal - January 2018

Lun, 02/05/2018 - 09:00
Finally, after what felt like months, January has come to an end. This means it is time for our monthly blog series, Last Month in Drupal. January has seen a plethora of Drupal news and here we pick out the best bits just for you.

Hook 42: Flip Flops and Drupal: Increasing Accessibility and Building Community

Dom, 02/04/2018 - 17:36

We’re stretching our legs, shaking off the snow, and heading to our first camp of 2018! AmyJune and Carie are on their way to Florida Drupal Camp to share their knowledge in "The Theme Park Capital of the World". They’re thrilled to have the opportunity to collaborate and learn with their peers.

Along with their sessions, they'll be helping with the Sunday Contribution Sprints!

DrupalEasy: Drupal 8 Development on Windows - Best Practices?

Sáb, 02/03/2018 - 17:34

Over the past several weeks, I've been working with three of the more well-known Docker-based local development environments that involve a Drupal focus: Docksal, DDEV, and Lando. The goal is to not only to figure out which one I prefer, but also to figure out which our two long-form online Drupal training classes should potentially standardize on.

Our classes are often comprised of folks from all different technical backgrounds, so it is important that we not only teach them tools that Drupal professionals use, but also something that folks of myriad of skill levels can easily consume. Perhaps most importantly, while the majority of our students are on Mac OS X, we still have a consistent number of students using Windows, so any solution we recommend should work similarly on all platforms.

As a Mac OS X user myself, it is important to me that I can instruct our Windows-based students without having to resort to a separate set of instructions. To that end, I have an actual Windows 10 Pro machine (not a virtual machine) that I've been using to evaluate these local development environment options. 

I've decided to focus on DDEV, Lando, and Docksal because I really like the idea of Docker-based containers; being able to customize your local development environments to each project has too many advantages to ignore. Also, as one of our classes is Pantheon-focused, Lando's Pantheon integration is a very important differentiator. 


I have a basic set of requirements that a local development environment should be able to handle. These requirements are probably focused more on our introductory Drupal Career Online course, but I'd like to be able to recommend the same solution for any of our courses.

  • Run Composer commands (including create-project). It doesn't matter to me if this command is run on the local OS or in a container, as long as it works with a minimum of fuss. The "create-project" command can be a bit tricky on Windows - keep reading to find out why.
  • Run Git commands both on the local OS and in the container. 
  • Be able to get up-and-running with a minimum of downloads. On Mac OS X this isn't much of an issue with Terminal, Git, and PHP preinstalled, but on Windows it is a different story.
  • Be able to get up-and-running with a minimum of "extra" configuration. Granted, once you're comfortable on the command line adding something to your local PATH isn't a big deal, but for folks new-ish to the command line, it can be a significant hurdle. 
  • Have a Linux-based command line interface (to use commands like cd, ls, cat, etc...)
  • Be able to easily (zero configuration) edit text files on the command line (nano or pico).
  • Be able to modify file permissions and ownership from the command line (chown and chmod).
  • Be able to run Drush, Drupal Console, and all of the other Drupal-y things that a professional developer should have.

I am very cognizant that my requirements are probably represent the lower-end of the Drupal skill-level spectrum, but I feel these requirements are a reasonable starting point.

Potential solution

Over the past few weeks, I think I've installed, uninstalled, and reinstalled various combinations of Lando, Docksal, and DDEV as well as various command line shells (Babun, Cmder, PuTTY, Cygwin) and the Windows Subsystem for Linux at least a dozen times on my Windows machine. All this in an effort to figure out what is the best combination of tools to satisfy the requirements. At the current moment, I'm circling around recommending Lando and Cmder on Windows (Lando requires Windows 10 Pro with Hyper-V enabled) - both are easily installed with no extra configuration necessary to get almost everything working. 


With just Lando and Cmder installed almost all of the requirements are met. I can use Git to clone a site down to my local, get it up and running in Lando and get to work.


One minor issue is that Cmder doesn't come with nano nor pico for editing text files from the command line. It does come with vim, however (which we all know has a steeper learning curve). I can probably mitigate this issue with a little bit of config to have students run a command to open text files in something like Notepad++ or teach some basic vim commands.

The other issue is a bit more serious. With only Lando and Cmder installed, there's no way to run "composer create-project". While Lando makes Composer available in the container, developers don't normally create the containers until they have a code base. This is a bit of a chicken-and-egg issue:

  1. We need Composer to get the new code base.
  2. We need the Lando container to be up-and-running to get Composer.
  3. We need a code base before we start Lando.
  4. (return to step 1 above)

So, I think I know what you're thinking: just install Composer. Well, this isn't as simple as it sounds, as Composer requires PHP, and as far as I can tell, installing PHP on a Windows machine isn't super-straight-forward. Granted, if the developer already has another AMP stack on their Windows machine, the Composer install can be configured to use the php.exe installed with it. 

Docksal actually has a command that allows a developer to run Composer without actually having a set of containers already initialized for the project using the "fin run-cli" command. This utilizes a standalone cli container and completely removes the need to install Composer on the local OS. 

Next steps

So, where does that leave us? I'm not 100% sure, but I wanted to put this out there and get some feedback. Are you a professional Drupal developer that uses Windows as your main OS? If so, what's your setup? Am I missing anything? 

While I often try to steer new Drupal developers towards Mac OS X or Linux, sometimes it is not possible due to corporate policies or even just personal preference. I'd love to be able to teach a solution that provides a professional-level Drupal developer experience to Windows users.

Drupal Association blog: Drupal User Research - Call for Interviews

Sáb, 02/03/2018 - 13:46

The Drupal Association is mapping Drupal’s customer lifecycle and defining the personas who have decision making authority throughout the adoption and user journeys. Our goal is to understand how to better serve each persona at DrupalCon and on Drupal.org, in turn growing Drupal adoption and more effectively helping those working on or with Drupal to become power users

To start this project, we need to interview different types of people working with Drupal.

Will you donate 45 minutes of your time to participate in a user research call?

We are looking for people in the following job functions who work with Drupal.

Job Functions:

  • CEO
  • CMO, VP marketing
  • CTO/CIO/ Director of engineering
  • Chief Information Marketing Office
  • Chief / Lead / Tech architect
  • Developer
  • Project manager
  • Marketing technologist
  • Content strategist
  • Content author / Content editor
  • Trainers of content editors
  • UX designer
  • Customer experience manager
  • Marketing campaign manager/director
  • Purchaser/procurement
If you are interested in participating in a user research call, please sign up here by February 16, 2018 and we will contact you.

Promet Source: Promet Source Receives 2018 AVA Digital Award for Martin County Florida Drupal Web Development

Vie, 02/02/2018 - 18:32
Promet Source has been named among the Gold level winners of the 2018 AVA Digital Awards for outstanding work on the Martin County Florida Drupal website development project in the government category.              

Acquia Lightning Blog: Using the Configuration Installer with Lightning

Vie, 02/02/2018 - 15:07
Using the Configuration Installer with Lightning Adam Balsam Fri, 02/02/2018 - 12:07

Installing a site with existing config has been a bit of a moving target in Drupal 8. At different times, I've recommended at least three different approaches. I won't go into too much detail, but basically we've used the following at times:

  • Manually change site UUIDs (Sloppy)
  • Use --config-dir option with drush site-install (Only supports minimal profile)
  • Use patch from Issue #2788777 (Config needs to be stored in profile directory)

You can read more about previous approaches here. The one thing that hasn't changed is the user story:

As a user I want to be able to install Drupal from a package of configuration that is maintained in git.

The issue that most closely addresses this user story is #1613424 "Allow a site to be installed from existing configuration". That issue is currently postponed on another thorny issue which involves the special way that Drupal treats dependencies of profiles. In the meantime, alexpott has provided a standalone install profile that handles installing a site from existing config. This is the Configuration installer profile.

It takes a minute to wrap your head around the concept because when you use the Configuration installer profile, you don't end up with a site running the Configuration installer profile. At the end of the install, your site will be running the profile that is defined in the config you provided the Config installer.

So for a new project, you would initially install using the profile of your choice. Then, once you have exported your config, you would use the Config installer for subsequent installs.

  • For ease of use, your settings file should not be writable by the installer and should not contain the install_profile key. If your settings file contains your profile, you'll get an exception when trying to run the install. And if it is writable, Drupal will write that value every time you do install.
  • The Config installer profile requires two patches in order to work properly with Drush 9.
  • Config must not have direct dependencies on a profile. Lightning 3.0.1 requires the patch in issue #2933445 to be compliant.
  1. For new sites, install using the profile or sub-profile of choice.
$ drush site-install lightning
  1. Ensure that the install_profile key is not present in your settings.php file. Drupal will write this value by default, but it is not required in Drupal >= 8.3.0. You can prevent Drupal from writing it by disallowing write access to the settings file. If the installer wrote the profile during initial installation, you can manually delete it. Then revoke write access:
$ chmod 444 docroot/sites/default/settings.php
  1. Define the following patches in your composer.json file if you are using config_installer < 1.6.0 and/or lightning < 3.0.2.
"patches": { "drupal/config_installer": { "2916090 - Support Drush 9": "https://www.drupal.org/files/issues/drush9-support-2916090-6.patch", "2935426 - Drush 9: Call to undefined function drush_generate_password": "https://www.drupal.org/files/issues/config_installer-drush_9_call_undefined_function_drush_generate_password-2935426-2.patch" }, "drupal/lightning_layout": { "2933445 - user.role.layout_manager has dependency on Lightning": "https://www.drupal.org/files/issues/2933445.patch" } },
  1. Add the Configuration installer profile to your codebase.
$ composer require drupal/config_installer
  1. Export your site's configuration.
$ drush config-export
  1. Use the Configuration installer profile in all subsequent site installs. The resulting install will run on the profile used in step 1.
$ drush site-install config_installer

drunken monkey: Some more (updated) tips for PhpStorm live templates

Vie, 02/02/2018 - 09:19

A few years ago I started using the PhpStorm IDE for PHP development, was immediately smitten and, after a bit of use, wrote a blog post with some tips I found for makig better use of the tools PhpStorm gives you.

In the four years since then there have been some new developments. Firstly, of course, Drupal 8 was finally released – and, consequently, the one complaint I had back in 2013 about the $MODULE$ variable only working in the module file itself became more of a problem. (Also, I added one more live template that's very useful for Drupal 8.)
But secondly, a few weeks ago PhpStorm finally added scripting support for live templates, so it's now possible to write more powerful templates that way – and fix the $MODULE$ variable.

The new di live template

In general, when writing OOP code for Drupal 8 (that is, for almost all Drupal 8 code) you should use dependency injection as much as possible. There's several different styles for doing that, I'm using one which uses setter methods and calls them in create() (instead of adding all injected objects to the constructor). This makes inheritance easier and keeps the constructor “cleaner” – and becomes much easier with a good live template:

   * The $NAME$.
   * @var $INTERFACE$|null
  protected $$$PROP_NAME$;

   * Retrieves the $NAME$.
   * @return $INTERFACE$
   *   The $NAME$.
  public function get$UC_PROP_NAME$() {

    return $this->$PROP_NAME$ ?: \Drupal::service('$SERVICE$');

   * Sets the $NAME$.
   * @param $INTERFACE$ $$$VAR_NAME$
   *   The new $NAME$.
   * @return $this
  public function set$UC_PROP_NAME$($INTERFACE$ $$$VAR_NAME$) {
    $this->$PROP_NAME$ = $$$VAR_NAME$;
    return $this;

Variable definitions:

Name Expression Skip if defined VAR_NAME N SERVICE N INTERFACE clipboard() Y NAME underscoresToSpaces(VAR_NAME) Y UC_NAME underscoresToCamelCase(VAR_NAME) Y UC_PROP_NAME capitalize(PROP_NAME) Y


  1. Copy the service interface's FQN to your clipboard.
  2. Put the service ID either into a secondary clipboard (e.g., middle mouse button on Linux) or remember it.
  3. Execute live template (at the position where you want the getter and setter).
  4. Input variable name (in snake_case), then input service name.
  5. Move the property definition and the create() line (temporarily stored as the first line of the getter in the template) to their appropriate places.
  6. In the code, alway use the getter method for accessing the service.
Fixing the $MODULE$ variable

Since the code for this is quite complex, we better just put it into a separate file. So, first download the script file and save it to some known location, then simply use the (absolute) path to the script file as the argument for groovyScript(), like this:

This can be used for all the live templates that contain a $MODULE$ variable (though it will, of course, be less useful for the procedural ones, than for the simple m template).

Palantir: Drupal ++

Jue, 02/01/2018 - 23:24
Drupal ++ brandt Thu, 02/01/2018 - 19:24 Ken Rickard Feb 2, 2018

Director of Professional Services Ken Rickard’s introduction to Drupal and how ++ flows through the community.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

2018 marks my 10th year at Palantir and the inaugural ++ Day gives me a great chance to reflect. For those of you who haven’t read George’s post yet:

++ has its origins in the C programming language, where it’s used as an operator to add one to the value of a particular variable. Over time, it’s become known as an informal shorthand for building and improving on past success.

I started working at Palantir after contributing to the Drupal project and launching some of the first newspaper industry websites on Drupal. And it’s in my experiences with Drupal – as a software project and a community – where the ++ ethos has had lasting influence.

My first contribution to the Drupal project was back at DrupalCon Vancouver in 2006. (So long ago, that it was actually called the Open Source CMS and Blogging Tools Summit, retroactively named as a DrupalCON later.) I was in a small group that was looking at the usability of the administrative interface in Drupal 4.7, which was in beta. At the time, all administrative actions were in one long list; a list that was getting ever-longer and harder to use.

That group includes Dries Buytaert, the Drupal project founder, Earl Miles, who authored VIews and (later) Panels, and Nedjo Rogers, an early and prolific contributor. Earl and I were new to the project, and I chose to be part of that group because we weren’t doing any programming: we were doing a card sort:

Card sorting is a method used to help design or evaluate the information architecture of a site. In a card sorting session, participants organize topics into categories that make sense to them and they may also help you label these groups. -- from Usability.gov

Now, at the time, I had been working with Drupal for almost two years but writing very little code. When I first started to evaluate CMS products, I couldn’t even write a PHP function (though I could write a stand-alone PHP script). So I joined the working group that seemed appropriate to my background, only to learn that the rest of the team were much more advanced programmers.

But a great thing happened. It didn’t matter. We were there to try to define a solution, not to code one. It was my first in-person open source event, and it changed the direction of my career.

I recall advocating for a User group of tasks to cover all the items related to user accounts: User management, registration settings, roles and permissions. (In Drupal 7 and 8, these items are under the People section of the interface.) The group liked the idea and it was implemented with the next beta release. And that was when I realized that I could contribute to making the software better, even though I wasn’t confident as a “developer.”

That confidence would come later, as working at Palantir allowed me the time and projects to focus and improve, iterating over code and concepts from Drupal 5 onward. (As I write this, I am working on the Drupal 8 version of a module I originally wrote in Drupal 5.)

More importantly, I learned a few other valuable lessons from that original working group in Vancouver, all of which reinforce the theme of ++ Day:

  • Make your work inviting to new people by giving them clear ways to contribute.
  • Engage in thoughtful, collaborative problem solving.
  • Recognize the value of what has come before while seeking to improve.
  • Change can come from unexpected places; be open to those opportunities.

I’m fortunate that I get to do what I like to do and make a career of it. I’m even more fortunate that I work on a team that reflects these values on a daily basis.

Happy ++ Day everyone!

We want to make your project a success.

Let's Chat.

Elevated Third: Submitted Sessions for DrupalCon Nashville

Jue, 02/01/2018 - 16:36
Submitted Sessions for DrupalCon Nashville Submitted Sessions for DrupalCon Nashville Tony Dryer Thu, 02/01/2018 - 11:36

At Elevated Third, everything is Drupal. We standardized a decade ago and have since attended DrupalCon yearly.

This year in Nashville we’re looking forward to sharing what we’ve learned in Drupal 8, Drupal biz, project management, and more. Check out the sessions we've submitted. 


Leveraging Maps for Scalable and Maintainable SASS

Tanner Langley

SASS is a relatively new language in the grand scheme of things. As many of us have transitioned from writing plain CSS to SASS, we still generally write our code the same way. Websites are becoming more complicated, and as such, we need more robust ways to write our CSS so that it is scalable and maintainable, even when the project grows.

In this session, I’ll discuss the idea of creating a framework in SASS to decouple the most complicated pieces of your code from the actual implementation. With this approach, you’ll still be able to use any CSS system, such as utility classes, BEM syntax or even just plain Drupal selectors. 

You may be interested in this session if:

  • You are new to SASS and would like to learn about what it’s capable of
  • You are experienced in SASS but feel like you still haven’t nailed down a system
  • You are a developer and are constantly frustrated that none of your programming skills carry over to SASS


The Circle of Trust: The Power of Agency Partnership

Zach Ettelman and Ayla Peacock

My best friend in high school was really good at math and horrible at writing. I was really good at English and terrible at math. To make a long story short, we were really good at cheating on tests. The dream team: what I lacked, she made up for and vice versa. We don’t cheat at Elevated Third, but we partner up. Last year we sent 4,000 emails to agencies who do what we don’t. The goal: to develop a trusted partner network to whom we can pass non-Drupal business; and when XYZ agency hears “Drupal website” from one of their clients, they think of us.

A partnership campaign like this one goes beyond email blasts. There are SEO link building opportunities, event sponsorship opportunities, and prospecting opportunities. In particular, Acquia has been one of our greatest allies in this metaphorical high school test-taking scenario.

In this session, we will cover the symbiotic sales and marketing relationships we’ve developed with Acquia and our other Agency partners. You’ll learn:

  • How agency partnerships contribute to new business goals
  • When the time is right to bring partners into the sales process
  • How to leverage SEO when developing co-marketing content
  • How to host co-branded events that lead to closed business
  • Strategies to kick-start your partnership campaign  


How to write an RFP for a Drupal website project

Zach Ettelman and Nelson Harris

Writing an RFP can be a daunting task, especially for services as complex and difficult to wrap your head around as a full website redesign in Drupal. With our years of experience reviewing RFPs and writing proposal responses, we have developed a set of conventions that you can use to make sure you’re putting out the best RFP possible in order to attract the right type of agency respondents. 

Every attendee will even get a free RFP template to use!


You wouldn’t choose the cheapest brain surgeon: A case for de-commoditizing Drupal

Nelson Harris and Joe Flores

Dries said it himself: the future of Drupal is ambitious digital experiences. The power of building ambitious digital experiences comes with great responsibility. We owe it to ourselves, our users, our clients, and the community, to decommoditize Drupal development services.

Regardless of your tenure in the Drupal community, you’ve undoubtedly heard people talk about how “hard” Drupal is, and the steep learning curve it carries. 

The truth is, Drupal development can be complex and “difficult”. We argue that’s a good thing, and that Drupal development is not a commodity, but rather a highly critical procedure to be performed by the skilled expert, with an emphasis on not cutting corners. Drupal has evolved beyond its place among the Wordpresses and Squarespaces of the world. It’s too complicated for building basic marketing sites, and the effort to reward ratio for a site like that just isn’t worth it. That’s because Drupal’s effort to reward ratio sweet spot is with more complex sites. It’s meant for ambitious digital experiences. 

So why, then, do so many people try to cut corners and haggle on price when developing a Drupal website? These negotiation tactics are a practice that is reserved for commodities. You wouldn’t shop around for the best price on brain surgery. On the contrary - if someone offered you the “lowest price”, this would be cause for alarm and concern. This procedure is a massive investment and failure has massive repercussions. In this session, we argue that Drupal development is the same. 


Once Upon A Timeline: Effective Storytelling with Clients & Teams

Lily Berman

At one point or another, we’ve all struggled with effective communication, whether it’s gaining trust from your internal teams or being able to bond quickly with clients. This interactive workshop will share some tips, tricks and activities to leverage the power of storytelling, helping you navigate those conversations. You will leave not only with strategies, but also specific action items to apply to your real world projects, clients, and teams.

Please bring an example of how you generally introduce yourself, a project (past or current) that could benefit from a clear purpose, and a conflict (past or current) you would like to see in a new way. Attendees with learn the theory behind three storytelling strategies, then will be given the opportunity to apply them to real-world situations at their seat. Examples volunteered from the audience will be used to deepen understanding of the theory, so it becomes more actionable for everyone. All disciplines are welcome.


Mic Check! How Life as an Activist Prepared Me for a Drupal Agency

Lily Berman

The skills of an activist and the skills of a Drupal PM are less disparate than they may seem. Activists motivate and coordinate large groups of people, often with differing ideas, without the resources agencies possess. Before becoming a Drupal project manager, Lily Berman (among other similar endeavors) led a political canvass office and a traveling nonprofit organization. She has slept on the sidewalk with Occupy Denver, given a speech with a crowd-powered “mic check” microphone in front of the UN, and has been a spokesperson for her nonprofit on Nevada Public Radio and NBC Nightly News.

This presentation will share stories and insights from the road, along with revealing tools and concepts that will benefit anyone working in a team. Attend this session to:

  • Learn how to effectively navigate differing opinions while ensuring your perspective is communicated persuasively, via lessons from a canvasser (learned while knocking doors in politically-divided Cincinnati)
  • Facilitate large meetings with ease, via tools and roles activists use to efficiently reach consensus with every voice heard (learned while living consensus-based decision making)
  • Build stronger, motivating relationships and inspire action with your clients and internal teams, via strategies activists use to amplify community around their cause (learned while acting a spokesperson for a grassroots nonprofit organization)


How the NFPA Is Bringing Paper Processes Online With Drupal 8

Nick Switzer and Aron Anderson

Topics we’ll cover include:

  • Why Drupal 8 is the right platform for building complex web apps that need to scale.
  • Leveraging an agile philosophy to respond quickly to change, collaborate across disciplines and stakeholder groups and get to a working product in as little amount of time as possible.
  • Balancing effective deliverables with shared understanding to produce working software that meets the organization’s needs.
  • Organizational hurdles to overcome when adding structure and bringing an established paper application process online.

Attendees will leave this session with an understanding of why Drupal 8 is a good fit for a complex web app, examples of processes used to execute a Drupal 8 project on time and on budget and some real-life lessons learned through launching and continually updating a project with thousands of active users.


Configuration Management - The Right Way

Nick Switzer

Drupal 8 has drastically changed the way developers think and work in Drupal. The Configuration Management Initiative (CMI) is one of the most impactful additions to the Drupal developer’s workflow toolbox, and is often either taken for granted by experienced developers or skipped over by those who are unfamiliar. Despite being extremely powerful and relatively easy to use, successfully integrating CMI into a stable development workflow can be an intimidating task. In this session, we’ll cover everything from the basics of what CMI is and how it works to a step-by-step example of how to implement CMI in a stable, scalable workflow.


The Power of Honest and Empathetic Communication

Kathy Weisbrodt and Kylie Forcinito

As a small agency, we are always striving to be more efficient, and maximize our communication both internally and externally. How can we work smarter not harder, and spend more time focused on understanding our client’s business problem? We chose to be empathetic and listen to what’s not necessarily said out loud from both the relationship and business perspective.  We use honesty in our communication backed by facts and expertise.

Join Kylie Forcinito, an accomplished senior account manager and veteran of the agency world, and Kathy Weisbrodt, Account Director with over 10 years of agency experience, to learn how they came together to ensure communications to their clients and their internal agency teams are honest and empathetic, while also driving projects forward to meet timelines, budgets and business goals, in a positive and supportive team environment - all disciplines are welcome!


Lessons Learned: Component-Based Design with Paragraphs

Anthony Simone

The ideas of Atomic Design and component based design allow one to create an established structure within which a large scale front end project can be built. The CMS space hasn’t always been the most friendly toward implementing these types of patterns. Whether it’s difficulty in creating a content architecture that models your front end design system within Drupal or the feeling of lack of control over generated markup, sometimes it can feel like an uphill battle.

The Paragraphs module gives us the tools to create much more well defined and structured component based architectures upon which modular front end systems can be built. The Paragraphs module, however, comes with no rules. As a site architect and front end developer, you must decide how to implement Paragraphs. There is definitely a lot of room for flexibility in implementation, but there are many best practices that can be followed to allow for a very clean, scalable, and extendable front end design system to be built within Drupal 8.


Listening to Your Users: How to Ditch Assumptions in Favor of Real Data

Jill Farley and Lauren Motl

Too often we fall back on our gut instincts or client insights when it comes to understanding end users. But there is a tangible cost to making assumptions. Which is why initial research before launch and ongoing testing post launch is critical to optimizing the usability of a site. In this session, Elevated Third will show you how we leverage analytics, user interviews and testing on real projects. Our case studies reveal how making data-informed UX decisions will improve site performance.

In this session you’ll learn:

  • Where to begin with tracking analytics
  • When and how to set up different types of user tests, polls and surveys 
  • When and how you can run successful User Interviews
  • How to scale your user research strategy using combinations of these methods so that they work for different types of projects
  • Tips on working alone or with a team to synthesize data and uncover patterns
  • How to use those patterns to make data-informed UX decisions


Designers and Developers: The Power of Shared Skills and a Common Language

Lauren Motl

There’s a reason the term “unicorn” was coined for the person who is both a talented designer and coder—it takes a special person to be equally skilled at both. But that shouldn’t stop the rest of us from skill sharing and finding a common language. 

Digital Designers who strive to understand the technical constraints of the medium they design for, and Developers who seek to understand not only what they’re trying to build but why, will ultimately find better solutions and bigger wins.

In this session, you’ll learn:

  • Why approaching design and development as convergent disciplines fosters powerful collaboration within project teams.
  • How backing your design decisions with technical knowledge can help you create stronger UX solutions and open up design possibilities.
  • How empathy for the end user can help Developers implement better products and websites
  • Tips on taking a more convergent approach to design and development


Pimp my CKEditor: How to add and create custom CKEditor plugins for D8 sites

Aubrie Hill

Component design has been a huge leap forward for content editors, giving great flexility to what an editor can create with minimal knowledge of HTML. As site builders, we can combine components with WYSIWYG editors and expand on these tools to make specifically the WYSIWYG editor work harder for a content editor’s precise needs while providing specific markup to match designs. 

Drupal 8 has adopted a custom version of CKEditor to be its core WYSIWYG editor and this move requires that CKEditor plugins be integrated into a site using a module. Site builders can then use any of the extensive plugins that the CKEditor community has developed or roll their own custom plugin to fit their particular needs. By creating a module, we can also leverage other parts of the site to be dynamically included in the plugin providing a content editor with a superior editing experience. 

Leave this session understanding how to:

  • Build a module that integrates a basic CKEditor plugin
  • Define plugin’s CKEDITOR.config options
  • Create a custom CKEditor plugin that incorporates a taxonomy


Cryptic Command: How to ask for and provide clear estimates

Nelson Harris and Nick Switzer

Estimating a Drupal project can often feel like a combination of black magic and mind-reading, but, with the right team and approach it can be a great way to start a collaborative and open relationship with a product owner or stakeholder team. There is no single way to guarantee an accurate estimate, but a combination of collaboration, brainstorming and clearly stating assumptions has helped us build an estimating process that is efficient, open and reliable.


A Beautiful Composition: Managing Drupal 8 with Composer

Eric Schmidt 

Composer is a dependency manager for PHP that assists with downloading, validating, and loading a project’s dependent packages. With the release of Drupal 8, Composer is now fully supported in Core, making your workflow, and your life, much easier. This talk will focus on the fundamentals of Composer and how they relate to a Drupal project workflow, including: installation, command line use, & versioning. Additionally, I will demonstrate how Elevated Third sets up Composer in new Drupal 8 installs, and how it effortlessly manages core/module installation, updates, & patching.


Making Data Accessible: The Power of Clean, Insightful, Actionable Analytics.

Nate Gengler

Data and Analytics are powerful tools to help us understand the complex interactions between our web apps and our users. If used correctly they can help us strategize content, improve user experience, and drive conversions.

The difficulty lies in bridging the gap between merely having analytics and actively using analytics to draw actionable insights. For many admins, marketers, copywriters, and even strategists, making sense of this web of datapoints and relationships is intimidating. My talk will outline a few ways to break down these barriers to entry and make data more accessible.

Attendees should walk away from this session with a better understanding of:

  • Some common tools for measurement, reporting, and analysis (Google Analytics, Google Data Studio, Hotjar)
  • Why Drupal makes the perfect partner for these analytics tools
  • How to use dashboards to hone in on whats important, and prioritize a few specific site metrics
  • Common applications for data analysis
  • The importance of pairing/validating data with qualitative research

Interested in Drupal 8?

Download our whitepaper

Acro Media: Drupal Commerce 2: Set up a Product Variation Type with Custom Fields

Jue, 02/01/2018 - 14:22

In part one and two of this Acro Media Tech Talk video series, we covered how you set up a new product attribute and used rendered fields, in Drupal Commerce 2. A product attribute is used to define options that customers would select when buying a product, such as colour. Rendered fields let the customer see the actual colour instead of just seeing the colour name.

The overall product in Drupal Commerce 2 consists of a product type, a product variation type, and product attributes. The product type defines the type of product that you're creating (i.e. hat). The product variation type is contained within the product type and defines the individual variations of the product, based on attributes (i.e. large blue hat).  In part three of this series, we'll move away from attributes and show you how you can configure your product variations type. A product variation type will always have a title, sku and price, but we'll take it a step further and add in some custom fields.

This entire video series, when complete, will show you how to set up a new product in Drupal Commerce 2, from start to finish. The video is captured using our Urban Hipster Commerce 2 demo site.

Next week we'll post part 4: Set up a Product Type with Custom Fields

Its important to note that this video was recorded before the official 2.0 release of Drupal Commerce and so you may see a few small differences between this video and the official release now available.

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

Flocon de toile | Freelance Drupal: Prevent access to untranslated pages with Drupal 8

Jue, 02/01/2018 - 12:00

It is not uncommon when a multilingual Drupal 8 project is implemented, that the pages translations are not ready at the time of production. If making a Drupal 8 multilingual site has become really easy to implement, there is now a fundamental difference with Drupal 7: it is impossible to disable a language. Either install a language, or delete it. This change is assumed, and voluntary, so as to not generate unnecessary complexity for questionable gain.

Specbee: Drupal SEO Made Easy - A Complete Guide

Jue, 02/01/2018 - 11:29
By now, you would have stumbled across thousands of blogs to discover that Drupal is the best Content Management System. This robust, flexible and dependable CMS platform is also well known for being an SEO friendly content management system with its latest version being the best by far. But for a Drupal website, is SEO necessary??

Agiledrop.com Blog: AGILEDROP: What can Drupal agencies expect in 2018

Jue, 02/01/2018 - 05:58
In 2017 Janne Kalliola and Michel van Velde conducted the Drupal Business Survey for the second time. By collecting responses from more than 200 Drupal agencies, they were able to come to the following conclusions: Drupal 8 has become the most popular version for new projects. Agencies started working on more complex projects. Drupal has lost against Wordpress (and others) in the low-end market. Smaller agencies have a challenge staying competitive in seizing bigger projects. Finding talent is continued to be a challenge.     SWOT analysis To try and foreseen into 2018 I am doing a… READ MORE

heykarthikwithu: Secure Website running on Apache with Let's Encrypt on Linux

Jue, 02/01/2018 - 04:37
Secure Website running on Apache with Let's Encrypt on Linux

Website security is generally most complicated and expensive task for every Linux admin. Let’s Encrypt is a free, automated, and open certificate authority that provides free X.509 certificates for Transport Layer Security encryption via an automated process. It's very complex process to install and add SSL certificate to a web server. Let's make it easier with the help of Let’s Encrypt. One can easily encrypt data of your website free of charge using Let’s Encrypt.

heykarthikwithu Thursday, 01 February 2018 - 12:07:21 IST

Lullabot: Drupal 8 Composer Best Practices

Mié, 01/31/2018 - 15:45

Whether you are familiar with Composer or not, using it to manage dependencies on a Drupal project entails its own unique set of best practices. In this article, we will start by getting a Composer-managed Drupal project set up, and highlight some common questions and issues you may have along the way.

Before we dive in, though, you may be asking yourself, “Why Composer? Can’t I just download Drupal and the modules I need without requiring another tool?” Yes you can, but you will quickly realize it’s not a simple task:

  1. Contributed modules or themes often depend on third-party libraries installed via Composer. Without using Composer for the project, you’ll need to manage these individually when downloading, which can be quite a chore.
  2. Some packages and modules only work with certain versions of PHP or Drupal. While Drupal core does help you identify these issues for modules and themes, it’s still a manual process that you’ll need to work through when choosing which versions to download.
  3. Some packages and modules conflict with other packages. You’ll need to read the composer.json files to find out which.
  4. When you upgrade a package or a version of PHP, you’ll need to do all the above over again.
  5. If you’re thinking you’ll use drush dl and friends, they’ve been removed in favor of Composer.

Dependency management is complicated, and it’s not going to get any easier. As Ryan Szrama put it , “if you’re not using a dependency manager [like Composer], then you’re the dependency manager, and you are unreliable.”

Where do I start?

To begin, it’s good to familiarize yourself with the fantastic documentation on Drupal.org . If you haven’t already, install Composer in your development environment. When getting started, it’s extremely important that your development environment is using the same version of PHP that the target production environment will use. Otherwise Composer may download packages that won’t work in production. (With larger development teams, using something like Vagrant or Docker for local development can help ensure compatibility between local development instances and the production stack, but that’s a separate topic).

To start with, you need to get Drupal core installed. If you are familiar with using starter-kits like Drupal Boilerplate in Drupal 7, there is a Composer template for Drupal projects called, well, drupal-project. It’s the recommended starting place for a Composer-based Drupal 8 installation. Before you create it—again—be sure you are using the production version of PHP. Once you’ve confirmed that, run:

$ composer create-project drupal-composer/drupal-project:8.x-dev \ example --stability dev --no-interaction

This will copy the drupal-project to the example directory, and download Drupal core and some handy packages. This is a good point to cd into the example directory, run git init , and to then create your initial commit for your project.

This also might be a good time to pop open the composer.json file that was created in there (which should look a lot like this). This file serves as your “recipe” for the project.

How do I download modules and themes?

If you are familiar with using drush dl in Drupal 7 to download contributed modules and themes, it can be a bit of a shift switching to a Composer workflow. There is a different syntax for selecting the version you’d like, and in some cases it’s best to not commit the actual downloaded files to your repository (more on that to follow).

For most instances, you can use composer require [vendor]/[packagename] to grab the package you’d like. Most Drupal modules and themes are hosted on a custom Composer repository, which drupal-project configures for us out of the box. That means we can use drupal as the vendor to download Drupal modules and themes that are maintained on drupal.org. If you aren’t using drupal-project, you may need to add the Drupal.org Composer repository yourself.

For example, if you were wanting to download the Devel module, you would run the following command:

$ composer require drupal/devel

For most cases, that would download the most recent stable version of the Devel module that is compatible with your version of Drupal and PHP. If you used drupal-project above, it would download the module to web/modules/contrib. If you want to change the download destination, you can alter the paths in your composer.json. Look for the installer-paths under extra and adjust to your liking.

Development Dependencies

The Devel module is a good example to use, as it brings up a few other things to note. For example, since the Devel module shouldn’t be used in a production environment, you may only want it to get downloaded on development environments. With Composer, you can achieve this by passing the --dev flag to the composer require command.

$ composer require --dev drupal/devel

This will ensure that the Devel module is available for your developers when they run composer install , but that it won’t ship with your production release (which should get built using composer install --no-dev ). This is just an example, and your project needs may differ, but the use of --dev to specify dependencies only needed during development is a recommended best practice.

As a side note, if you are committing your exported Drupal 8 configuration to code, you may want to use the Configuration Split module to ensure that the Devel module’s enabled status doesn’t get pushed to production by mistake in a release.

Nested Dependencies

Another thing to note is that the Devel module ships with its own composer.json file. Since we used Composer to download Devel, Composer will also read in Devel’s composer.json and download any dependencies that it may have. In this case (at the time of this writing), Devel doesn’t have any required dependencies, but if you were to use Composer to download, say Address module, it would pull in its additional dependencies as well, as Address module uses Composer to specify some additional dependencies .

Downloading specific versions

While it’s most often fine to omit declaring a specific version like we did above, there still may come a time when you need to narrow the range of possibilities a bit to get a package version that is compatible with your application.

Judging by the length of the Composer documentation on Versions and constraints, this is no small topic, and you should definitely read through that page to familiarize yourself with it. For most cases, you’ll want to use the caret constraint (e.g., composer require drupal/foo:^1.0 means the latest release in the 8.1 branch), but here’s some more details about versions and constraints:

  1. Read up on Semantic Versioning if you aren’t familiar with it. Basically, versions are in the x.y.z format, sometimes described as MAJOR.MINOR.PATCH , or BREAKING.FEATURE.FIX . Fixes increment the last number, new features increment the middle number, and refactors or rewrites that would break existing implementations increment the first number.
  2. Use a colon after the vendor/package name to specify a version or constraint, e.g. composer require drupal/foo:1.2.3 (which would require that exact version (1.2.3) of the foo package). If you’re used to drush syntax (8.x-1.2.3), the Composer syntax does not include the Drupal version (i.e., there's no 8.x).
  3. Don’t specify an exact version unless you have to. It’s better to use a constraint.
  4. The caret constraint (^): this will allow any new versions except BREAKING ones—in other words, the first number in the version cannot increase, but the others can. drupal/foo:^1.0 would allow anything greater than or equal to 1.0 but less than 2.0.x . If you need to specify a version, this is the recommended method.
  5. The tilde constraint (~): this is a bit more restrictive than the caret constraint. It means composer can download a higher version of the last digit specified only. For example, drupal/foo:~1.2 will allow anything greater than or equal to version 1.2 (i.e., 1.2.0, 1.3.0, 1.4.0,…,1.999.999), but it won’t allow that first 1 to increment to a 2.x release. Likewise, drupal/foo:~1.2.3 will allow anything from 1.2.3 to 1.2.999, but not 1.3.0.
  6. The other constraints are a little more self-explanatory. You can specify a version range with operators, a specific stability level (e.g., -stable or -dev ), or even specify wildcards with *.
What do I commit?

Now that we’ve got a project started using Composer, the next question you may have is, “What files should I commit to my repository?” The drupal-project will actually ship a default .gitignore file that will handle most of this for you. That said, there are a few things that may be of interest to you.

You may have noticed that after running some of the above commands, Composer created a composer.lock file in your repository. The composer.lock file is a very important file that you want to commit to your repository anytime it changes. When you require a new package, you may have omitted a version or a version constraint, but Composer downloaded a specific version. That exact version is recorded in the composer.lock file, and by committing it to your repository, you then ensure that anytime composer install is run on any other environment, the same exact code gets downloaded. That is very important from a project stability standpoint, as otherwise, Composer will download whatever new stable version is around based on what’s in composer.json.

Now that we understand more about what composer.lock is for, here’s a list of what to commit and what not to commit:

  1. Commit composer.json and composer.lock anytime they change.
  2. There’s no need to commit anything in ./vendor , Drupal core (./web/core), or contributed modules and themes (./web/modules/contrib or ./web/themes/contrib). In fact, it’s recommended not to, as that ensures the same code is used on all environments, and reduces the size of diffs. If you really want to (because of how your code gets deployed to production, for example), it is possible, you’ll just need to change the .gitignore, and always make sure the committed versions match the versions in composer.lock.
  3. Commit any other custom code and configuration as usual.
How do I keep things up to date?

Updating modules, themes, and libraries downloaded with Composer is similar to installing them. While you can run composer update to update all installed packages, it’s best to save that for the beginning of a sprint, and update individual projects as needed after that. This ensures you only update exactly what you need without risking introducing bugs from upstream dependencies. If you aren’t working in sprints, set up a regular time (weekly or monthly) to run composer update on the whole project.

To update the Devel module we installed earlier, you could run:

$ composer update --with-dependencies drupal/devel

You might be wondering what that --with-dependencies option is. If you run the update command without it, composer will update just the module, and not any packages required by that module. In most circumstances, it’s best to update the module’s dependencies as well, so get used to using --with-dependencies.

You can also update multiple packages separated by spaces:

$ composer update --with-dependencies drupal/foo drupal/bar

For a more aggressive approach, you can also use wildcards. For example, to update all drupal packages, you could run:

$ composer update --with-dependencies drupal/*

Once complete, be sure to commit the changes to composer.lock.

What about patches?

Inevitably, you’ll need to apply some patches to a Drupal module, theme, or possibly Drupal core. Since you aren’t committing the actual patched modules or themes with a Composer workflow, you’ll need some way to apply those patches consistently across all environments when they are downloaded. For this we recommend composer-patches. It uses a self-documenting syntax in composer.json to declare your patches. If you’re using drupal-project mentioned above, composer-patches will already be installed and ready to use. If not, adding it to your project is as simple as:

$ composer require cweagans/composer-patches

While it’s installing, take this time to go read the README.md on GitHub.

Once installed, you can patch a package by editing your composer.json . Continuing with our example of Devel module, let’s say you wanted to patch Devel with a patch from this issue. First step?—copy the path to the patch file you want to use. At the time of this writing, the most recent patch is https://www.drupal.org/files/issues/2860796-2.patch .

Once you have the path to the patch, add the patch to the extras section of your composer.json like so:

"extra": { "patches": { "drupal/devel": { "2860796: Create a branch of devel compatible with Media in core": "https://www.drupal.org/files/issues/2860796-2.patch" } } }

You can see that in the above example, we used the node id (2860796) and title of the Drupal.org issue as the key, but you may decide to also include the full URL to the issue and comment. It’s unfortunately not the easiest syntax to read, but it works. Consistency is key, so settle on a preferred format and stick to it.

Once the above has been added to composer.json, simply run composer update drupal/devel for the patch to get applied.

$ composer update drupal/devel Gathering patches for root package. Removing package drupal/devel so that it can be re-installed and re-patched. Deleting web/modules/contrib/devel - deleted > DrupalProject\composer\ScriptHandler::checkComposerVersion Loading composer repositories with package information Updating dependencies (including require-dev) Package operations: 1 install, 0 updates, 0 removals Gathering patches for root package. Gathering patches for dependencies. This might take a minute. - Installing drupal/devel (1.2.0): Loading from cache - Applying patches for drupal/devel https://www.drupal.org/files/issues/2860796-2.patch (2860796: Create a branch of devel compatible with Media in core)

And finally, commit the changes to both composer.json and composer.lock .

If any of your dependencies declare patches (for example, let’s say a module requires a patch to Drupal core to work properly), you’ll need to explicitly allow that in your composer.json. Here’s a quick one-liner for that:

$ composer config extra.enable-patching true How do I remove a module or theme?

Removing a module or theme using Composer is fairly straightforward. We can use composer remove for this:

$ composer remove drupal/devel

If you added drupal/devel with the --dev flag, you might get a prompt to confirm the removal from require-dev . If you want to avoid that prompt, you can use the --dev flag in your remove command as well:

$ composer remove --dev drupal/devel

Once it’s done, commit your composer.json and composer.lock file.

Anything else to watch out for? Removing patches

If you need to remove a module or theme that has patches, the patches don’t automatically get removed from the composer.json file. You can either remove them by hand in your editor, or run:

$ composer config --unset extra.patches.drupal/devel Lock hash warnings

On a related note, any time you manually edit composer.json in this way without a subsequent composer update, the hash in composer.lock will be out of date, throwing warnings. To fix that without changing the code you have installed, run composer update --lock. That will just update the hash in the lock file without updating anything else. Once complete, commit the composer.json and composer.lock.

PHP Versions…again

As mentioned early on, it’s very important with a Composer-based workflow that the various environments use the same major and minor release of PHP. If you aren’t using Vagrant or Docker for local development and are finding it difficult to standardize, you can enforce a specific PHP version for Composer to adhere to in composer.json.

$ composer config platform.php 7.1

Once added, don’t forget to update your lock file and commit the resulting composer.json and composer.lock .

$ composer update --lock Speeding things up

There are some Composer operations that can be slow. To speed things up, you can install Prestissimo, which will allow Composer to run operations in parallel. It’s best to do this globally:

$ composer global require hirak/prestissimo It’s not perfect

You will inevitably run into some frustrating issues with a Composer workflow that will cause you to question its wisdom. While there may be scenarios where it might make sense to abandon it for other options, you will bear the burden of managing the complexities of your project’s dependencies yourself. If you stick with Composer, the good news for you is that you are not alone, and these issues promise to improve over time because of that. Think of it as an investment in the long-term stability of your project.

Collage of JoAnn Falletta by Mark Dellas.