Mar 02 2018
Mar 02

Drupal is a very popular open source Web Content Management system. One of its key characteristics is that it owns both the back-end repository where content is stored and the front-end where content is rendered. In CMS parlance this is typically called a “coupled” CMS because the front-end and the back-end are coupled together.

Historically, the coupled nature of Drupal was a benefit most of the time because it facilitated a fast time-to-market. In many cases, customers could just install Drupal, define their content types, install or develop a theme, and they had a web site up-and-running that made it easy for non-technical content editors to manage the content of that web site.

But as architectural styles have shifted to “API-first” and Single Page Applications (SPAs) written in client-side frameworks like Angular and React and with many clients finding themselves distributing content to multiple channels beyond web, having a CMS that wants to own the front-end becomes more of a burden than a benefit, hence the rise of the “headless” or “de-coupled” CMS. Multiple SaaS vendors have sprung up over the last few years, creating a Content-as-a-Service market which I’ve blogged about before.

Drupal has been able to expose its content and other operations via a RESTful API for quite a while. But in those early days it was not quite as simple as it could be. If you have a team, for example, that just wants to model some content types, give their editors a nice interface for managing instances of those types, and then write a front-end that fetches that content via JSON, you still had to know a fair amount about Drupal to get everything working.

Last summer, Acquia, a company that provides enterprise support for Drupal headed up by Drupal founder, Dries Buytaert, released a new distribution of Drupal called Reservoir that implements the “headless CMS” use case. Reservoir is Drupal, but most of the pieces that concern the front-end have been removed. Reservoir also ships with a JSON API module that exposes your content in a standard way.

I was curious to see how well this worked so I grabbed the Reservoir Docker image and fired it up.

The first thing I did was create a few content types. Article is a demo type provided out-of-the-box. I added Job Posting and Team Member, two types you’d find on just about any corporate web site.

My Team Member type is simple. It has a Body field, which is HTML text, and a Headshot field, which is an image. My Job Posting type has a plain text Body field, a Date field for when the job was posted, and a Status field which has a constrained list of values (Open and Closed).

With my types in place I started creating content…

Something that jumped out at me here was that there is no way to search, filter, or sort content. That’s not going to work very well as the number of content items grows. I can hear my Drupal friends saying, “There’s a module for that!”, but that seems like something that should be out-of-the-box.

Next, I jumped over to the API tab and saw that there are RESTful endpoints for each of my content types that allow me to fetch a list of nodes of a given type, specific nodes, and the relationships a node has to other nodes in the repository. POST, PATCH, and DELETE methods are also supported, so this is not just a read-only API.

Reservoir uses OAuth to secure the API, so to actually test it out, I grabbed the “Demo app” client UUID, then went into Postman and did a POST against the /oauth/token endpoint. That returned an access token and a refresh token. I grabbed the access token and stuck it in the authorization header for future requests.

Here’s an example response for a specific “team member” object.

My first observation is that the JSON is pretty verbose for such a simple object. If I were to use this today I’d probably write a Spring Boot app that simplifies the API responses further. As a front-end developer, I’d really prefer for the JSON that comes back to be much more succinct. The front-end may not need to know about the node’s revision history, for example.

Another reason I might want my front-end to call a simplified API layer rather than call Drupal directly is to aggregate multiple calls. For example, in the response above, you’ll notice that the team member’s headshot is returned as part of a relationship. You can’t get the URL to the headshot from the Team Member JSON.

If you follow the field_headshot “related” link, you’ll get the JSON object representing the headshot:

?

The related headshot JSON shown above has the actual URL to the headshot image. It’s not the end of the world to have to make two HTTP calls for every team member, but as a front-end developer, I’d prefer to get a team member object that has exactly what I need in a single response.

One of the things that might help improve this is support for GraphQL. Reservoir says it plans to support GraphQL, but in the version that ships on the Docker image, if you try to enable it, you get a message that it is still under development. There is a GraphQL Drupal module so I’m sure this is coming to Reservoir soon.

Many of my clients are predominantly Java shops–they are often reluctant to adopt technology that would require new additions to their toolchain, like PHP. And they don’t always have an interest in hiring or developing Drupal talent. Containers running highly-specialized Drupal distributions, like Reservoir, could eventually make both of these concerns less of an issue.

In addition to Acquia Reservoir, there is another de-coupled Drupal Distribution called Contenta, so if you like the idea of running headless Drupal, you might take a look at both and see which is a better fit.

Mar 02 2018
Mar 02

Happy Friday Everyone! On the eve of the Drupal Drive-in, happening tomorrow in Charlotte North Carolina, we welcome Mark Shropshire to the show to talk about his favorite topic, Drupal Security!

Mar 01 2018
Mar 01

We are organizing the biggest Drupal event in Europe in 2018 with a group of community volunteers in collaboration with the Drupal eV (German Drupal Association) and the Drupal Europe Foundation. We’d like to update you on our progress and turn to you for input.

Mark your calendars for September 10–14, 2018 when Drupal Europe will be held in the beautiful Darmstadtium in Darmstadt, Germany. This is a great venue for the conference and only a 20 minutes’ drive from Frankfurt Airport. We just had our second walkthrough last week discussing details with the venue and were impressed.

Photo by Baddy Breidert @baddysonja

Buy your Early Supporter ticket now!

We are now selling Early supporter tickets for 380 EUR (including VAT). Only 300 of these tickets are available, and only for a limited time. Buy now at https://www.drupaleurope.org/#tickets

A new logo

Thanks to all designers we worked with who came up with such great ideas for our branding! We are delighted to release our final logo proudly crafted by sixeleven. Drupal Europe stickers (pictured here) will be available at various Drupal events where our team shows up in the coming months.

Latest on the conference schedule

We are continually looking at how to structure the biggest Drupal event in Europe, and based on exploratory discussions with community members, we believe we are on the right track.

First of all we strongly believe contribution is at the heart of the Drupal project. Figures show that over 44% of Drupal contributors are in Europe. Therefore, in our programme we want to give you more time to contribute by making both Monday and Friday contribution days (formerly called sprints). Mentors will be available on both days to help those new to Drupal contribution.

We are structuring the rest of the event between Tuesday and Thursday on the successful summit model that has worked well at the start of DrupalCons and other regional events. Topics will include government, education, publishing, technology, and community. We are looking for sponsors for each to make possible to put them on.

And the great news is that your single Drupal Europe ticket will give you access to all these workshops, panels and discussions.

We want to hear from you

Although we have plenty of ideas, we realize that this is your conference.

DrupalCON Amsterdam Group photo

Please help us understand you, our audience, better by completing our survey. It should only take 8 minutes or so and still give us lots of valuable insight. While not all questions are mandatory, we added a few open questions to get to know you better.

Thank you, and please share our survey with all your Drupal friends and colleagues to help us make Drupal Europe a success.

See you in September!

Feb 27 2018
Feb 27

Background

When I was tasked with integrating QuickBooks accounting software with an existing Commerce 2.x installation, instead of asking questions a normal Drupal developer would, I was asking myself one question, what exactly is QuickBooks? Though I’m a bit embarrassed, I’m not going to shy away from admitting that I have not ever had an opportunity to explore or be exposed to the QuickBooks accounting software. So, doing an integration first required me to do some research on QuickBooks.

quickbooks-enterprise-logoFor the unaware (which I doubt there are any), QuickBooks is an accounting software used by businesses to manage sales and expenses and keep track of daily business transactions. It’s often used to invoice customers, pay bills, generate reports, and for tax filing purposes.While there are many applications like it, QuickBooks is thought of as one of the better options in its class. This fully-developed software takes care of all the different aspects of accounting. Thus, quite a few small to medium-scale businesses use QuickBooks because it makes life easy for them. However, if you’re doing business online, the process becomes a little trickier.

For a lot of customers who have an online store, a big pain for them is syncing their sale transactions like order, customer, tax and payment data into QuickBooks for bookkeeping. Basically, how do you transfer over your online transactions to QuickBooks?

We’ve had customers in the past who just assign a staff to sit and enter the days transactions, manually, at the end of each day. When you have hundreds of orders a day, especially, like during the holidays, this can be a huge headache. Not only are you wasting time and money by entering the duplicate data but you’re also exposing yourself to human errors. Because, at the end of the day, all this data is used for filing taxes, generating invoices, re-ordering products, etc., and any error in the data can wreak havoc.

So, out of this dilemma, quite a few Drupal modules came up which paved the way to integrating Commerce/Ubercart transactions into QuickBooks. But most of them are for Drupal 7. How do we integrate a Drupal 8 site running Commerce 2.x into QuickBooks? Essentially, that was my task. It was an excellent learning experience and I’m hoping that I can shed some light on the procedure for syncing your commerce data into QuickBooks.

Setup Drupal Commerce 2 to sync with QuickBooks Enterprise

Our job today will be trying to integrate a Drupal 8 Commerce 2 installation with QuickBooks Desktop. Before we start, I’d like to thank everyone who created the commerce_qb_webconnect module for all their awesome work and especially, Lucas Hedding (heddn), for supporting me in this endeavor.

Essentially, commerce_qb_webconnect, under the hood, uses migrate to export from D8 to a SOAP service destination. This also means that we have more flexibility, because any of the means to work and interact with a migration lets us interact and alter the exported details of a QuickBooks export as well.

The initial setup is as follows (I’m assuming that you already have been using QuickBooks Enterprise Desktop):

  1. Download and install QuickBooks Enterprise Desktop (we used the 2017 Retail version)
    • Note: QuickBooks Desktop, currently, only works on the Windows operating system. Also, be very careful about which version you are purchasing. Make sure you select the correct country version based on where you’re doing business because each version is fitted to a specific country and its tax system, and unfortunately, you cannot just switch countries in the software.
    • Setup all your accounting details on QuickBooks
    • Go to Payments and click on the PMT. Method select list and add the following payment methods depending on the payment gateways enabled on your site (these are the gateways on my test site):
      - Example
      - Default
  2. Download and install QuickBooks Web Connector 2.2.0.80
  3. Download the Drupal module commerce_qb_webconnect

    $ composer require drupal/commerce_qb_webconnectAt the time of this writing, the module has an 8.x-2.0 alpha version out and it contains most of the functionality required to get the commerce data into QuickBooks.

  4. Go to your Drupal installation
    • Note: If it's a local installation, make sure the url of the site starts with http://localhost (yes it has to have the words localhost, it’s hardcoded). Else, if it's a public site, you have to make sure it has an https certificate.
  5. Go to /admin/people and add the password for **quickbooks_user ** in Drupal and note that password as we’ll be using it in the Web Connector application.
  6. Go to /admin/commerce/config/commerce_quickbooks_enterprise/qwc and make sure your config looks like this:

    quickbooks-integration-01

  7. Now, Download QWC file (click that button).
  8. Open QuickBooks Web Connector and click on 'Add an application' and upload the .qwc file.
  9. Click 'Yes' to all the prompts and your file should be successfully added.
  10. Now, go to /admin/commerce/config/commerce_quickbooks_enterprise/quickbooksadmin and add the following configs and leave everything else as it is:

    quickbooks-integration-02

  11. Make sure to replace the Income, COGS, and Assets accounts with the appropriate ones matching your accounting information.

Syncing the Data with QuickBooks Enterprise

  1. Assuming you have create some products on your site, add a product to the cart, finish checkout and complete the order.
  2. Go to /admin/reports/dblog and notice you'll see messages like: "Added Invoice Order to export queue!"
  3. Now, go to the Web Connector and select the application we just uploaded with the .qwc file and hit 'Update Selected'. Make sure you enter the same password that we saved earlier (See setup step 5) for the password field.

    quickbooks-integration-03

  4. The order (invoice/sales receipt), product, payment, and customer will automatically be imported to your QuickBooks Desktop.
  5. Check QuickBooks Desktop to verify they have been added by clicking on 'Customer' and finding the name on the order there and then 'Recent Transactions' and then, Invoice/Sales Receipt. You can see the product in the 'Item' section. You can see the payment in the 'Payment' section by clicking on the 'Received From' select list and selecting the name on the order.

    quickbooks-integration-04-441335-edited-494921-edited

    And voila! If everything worked, you should see all the details from the new transaction synced in your QuickBooks Enterprise Desktop. The need for wasting time and money on manual entry and chances of user errors all vanish by integrating QuickBooks with your online Drupal 8 Commerce 2 store(s).

More from Acro Media

Need a hand?

Would you like QuickBooks integrated into your Drupal Commerce website, but need a hand doing it? We've done it many times and would love to help.

Contact Acro Media Today!

Feb 27 2018
Feb 27

The ability to create and maintain redirects on a website is vital for long-term success.

Once your site has a lot of content, you may need to do a content audit. This will require merging or deleting pages which are no longer important. To maintain the traffic from these deleted or merged pages, you’ll need to create URL redirects. Now I understand this isn’t the most exciting part of site building but it’s important to get it right.

The module which will handle all of this is perfectly named; Redirect.

The Redirect module lets you create and manage redirects using a simple user interface. Just define a source and destination and you’re good to go. You can also track 404 errors, using a sub-module, so if you have a page indexed in Google with a broken path then it’ll be logged and a redirect can be easily created.

In this tutorial, you’ll learn how to:

  1. Create a redirect
  2. Track broken paths
  3. Add domain level redirections
  4. Import redirects via a CSV

Learn how to automate the generation of URL aliases using Pathauto in Drupal 8.

Getting Started

Before we begin, make sure you download and install the Redirect module.

If you use Composer, run the following:

$ composer require drupal/redirect

Or Drush,

$ drush dl redirect

Create a Redirect

Once you have installed the module creating a redirect is very easy.

1. Go to Configuration and click on “URL redirects”.

2. Click on “Add redirect”, enter in a Path (old path) and then select a To (new path).

The To field is an autocomplete field which you can use to lookup content on the site. But you can also add an external URL into the field.

3. From the “Redirect status” drop-down box, you can select which status will be used. Most of the time it’ll be a 301 or 302. Once you’re finished click on Save.

4. You’ll be redirected back to the Redirect page where you can manage existing redirects and create new ones.

Track Broken Paths

The Redirect module ships with a handy sub-module called Redirect 404.

The sub-module logs all the 404s and displays them all with a count in the “Fix 404 pages” page in “URL redirects”. When dealing with redirects, half the battle is figuring out which paths need to be redirected. This sub-module will log all 404s and add a button called “Add redirect” which you can use to create the redirect.

This sub-module could cause performance issues if your site gets a lot of traffic so test accordingly.

Domain Level Redirects

Another sub-module, which Redirect comes with is called “Redirect Domain”, it allows you to create domain level redirects.

A good use of this is when you want to redirect a whole domain, i.e., old-domain.com to new-domain.com. You can create a rule which will redirect anything from old-domain.com/* to new-domain.com, without manually creating redirects.

Import Redirects

Creating redirects manually won’t cut it if you need to add more than 20. If you have a spreadsheet full of redirects then it’s best to look at using Path redirect import.

The module lets you import redirects using a CSV file. All you need to do is prepare everything in a spreadsheet then once you’re ready, export the sheet as a CSV and import it into Drupal using the module.

The format of the CSV is pretty simple:

From,To,Redirect,Language
hello-world,node/1,301,en

From and To are the only required columns. Redirect and Language are optional.

Run CSV Import

Once you’ve installed Path redirect import, go to Configuration, “URL Redirects” and click on the Import tab.

Select a file using the CSV File upload field and click on Import. Once the import is complete you’ll see a message telling you which redirects imported and which didn’t.

The reason the redirects in the above image were bypassed (not imported) is because the page did not exist. When preparing your CSV file make sure the paths and nodes actually exist. For example, if you’re creating a redirect to node/123 and that page doesn’t exist then the module won’t import it in.

Update Existing Redirects

When importing, if you want to update existing redirects then all you need to do is check the “Override existing sources” checkbox when importing.

Global Redirect merged into Redirect Module

The functionality of the Global Redirect module has been merged into Redirect for Drupal 8.  This is great because it means there’s one less module to install.

The Global Redirect settings can be configured by going to the Settings page with “URL redirects”.

Summary

Redirect is one of the must-have modules which is installed on most Drupal sites. But you can use it for more than just managing historical links. Another good use-case is to create vanity URLs. For example, you could create a redirect path domain.com/d8, that’ll redirect to another page within your site. This is especially useful when adding URLs into a presentation, the shorter the URL the more memorable it is.

Ivan Zugec

About Ivan Zugec

Ivan is the founder of Web Wash and spends most of his time consulting and writing about Drupal. He's been working with Drupal for 10 years and has successfully completed several large Drupal projects in Australia.

Feb 21 2018
Feb 21

Drupal Commerce 2 comes with a payment gateway system that allows for all kinds of payment methods to be added into your ecommerce site. Many of the standards you're used to seeing, Authorize.net, PayPal, Stripe, etc., are already good to go. On top of that, Commerce 2 has a fantastic API making it easy for developers to connect new gateway plugins.

What if you also want to allow your customers to pick up their order in-store? Or maybe you want to accept email money transfers or some other manual payment method. No worries! Drupal Commerce 2 is so adaptive that setting up these methods is also easy to do.

In this Acro Media Tech Talk video, we user our Urban Hipster Commerce 2 demo site to show how you can add, and manage, your payment gateways. 

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 differences between this video and the current release. The documentation is also evolving over time.

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.

Visit Our Drupal Commerce 2 Demo Site

More from Acro Media
Drupal modules in this demo

Contact us and learn more about our custom ecommerce solutions

Feb 21 2018
Feb 21

Selected sessions for Drupalcon Nashville have just been announced! Mediacurrrent will be presenting seven sessions and hosting a training workshop. 

From exploring new horizons in decoupled Drupal to fresh perspectives on improving editorial UX and achieving GDPR compliance, check out what the Mediacurrent team has in store for Drupalcon 2018:
 

Speakers: Matt Davis, Director of Emerging Technology at Mediacurrent and Jeremy Dickens, Senior Drupal Developer at The Weather Company / IBM
Session Track: Horizons

During the course of an ongoing decoupling project for weather.com, the team found that the lack of page configurability was a distinct pain point for site administrators and product owners. To meet this challenge, the weather.com team built Project Moonracer, a Drupal 8-based solution that allowed for the direct modification of page configuration on a completely decoupled front-end by developing a unique set of data models to move page configuration back into the hands of the site owners.  

Takeaways:

  • Gain a greater understanding of the decoupled UI problem space as a whole
  • See specific API and UI considerations and lessons learned from our experience
  • Catch a glimpse into some possible futures of editorial interfaces in an increasingly decoupled world

Speaker: Bob Kepford, Lead Drupal Architect at Mediacurrent
Session Track: Back End Development 

Wouldn’t it be nice if you could type one command that booted your vagrant box, started displaying watchdog logs, set up the correct Drush alias, and provided easy access to your remote servers? Or maybe you use tools like Grunt, Gulp, or Sass. What if you could launch all of your tools for a project with one command? In this session, attendees will see how to use the terminal every day to get work done efficiently and effectively

You’ll learn:

  • How to use free command line applications to get work done.
  • How to better use the command line tools you already know.
  • How to customize your command line to behave the way you want it to. I guarantee attendees will walk away with at least one new tip, trick, or tool.

Speaker: Jay Callicott, VP of Technical Operations at Mediacurrent 
Session Track: Site Building 

If you have ever googled to find “top Drupal modules” you probably have read Mediacurrent’s popular, long-running blog series on the top modules for Drupal, authored by our own Jay Callicott. In this session, follow him on a leisurely stroll through the best modules that Drupal 8 has to offer as Jay presents an updated list of his top picks. Like a guided tour of the Italian countryside, you can sit back and enjoy as your guide discusses the benefits of each module. By the end of this session, you will have been introduced to at least a few modules that will challenge the boundaries of your next project.

Speakers: Mediacurrent's Dawn Aly, VP of Digital Strategy and Mark Shropshire, Open Source Security Lead
Session Track: Business

Data security legislation like the GDPR (enforcement begins May 28th, 2018) allows users to control how and if their personal data is used by companies. This shift in control fundamentally changes how companies can collect, store, and use information about prospects and customers. While understanding and implementing privacy related regulation in web projects is a necessity, related knowledge and skill sets become a real business differentiator and a key part of a user’s privacy experience (PX).

Key Topics:

  • Practical interpretation of the GDPR 
  • How to determine if you are at risk for compliance 
  • Repeatable process for assessing security risks in Drupal websites 
  • Security by design
  • Impact to data, analytics, and personalization strategies 

Speakers: Kevin Basarab, Director of Development at Mediacurrent and Mike Priscella, Engineering Manager at Thrillist/ Group Nine Media. 
Session Track: Ambitious Digital Experiences 

In this session, we'll dive into how Group Nine Media (parent company of Thrillist.com, TheDodo.com, and others) are evolving the Drupal 8 editorial user experience and contributing that back to the community. We'll not only look into their use case but also explore what modules and options are out there for improving editorial UX without custom development work.

  • How is design/UX reversing to focus on the editorial experience?
  • What contrib modules currently enhance the editorial experience?
  • How can a better editorial experience be beneficial to your client? 

Speakers: Mediacurrent Senior Front End Developer Mario Hernandez; Cristina Chumillas, Designer and Frontend Developer at Ymbra; Lauri Eskola, Drupal Developer at Druid Oy
Session Track: Core Conversations 

The Out-of-the-Box initiative team is working on improving the first-time user experience of Drupal. The team is creating a new installation profile with the main goal of demonstrating how powerful Drupal is for creating beautiful websites for real life use cases.

The alpha version for The Out of the Box initiative has been committed to Drupal 8.6.x. But, what is it and what will it bring to core?
 

Speakers: A panel of community organizers, including Mediacurrent Senior Developer April Sides 
Session Track: Building Community

This conversation is a space for camp organizers (and attendees) to discuss all things event planning, from venue selection and budgeting to session programming and swag. 

Training Presenters: Mediacurrent Senior Front End Developers Mario Hernandez and Eric Huffman

With the component-based approach becoming the standard for Drupal 8 theming, we’re beginning to see some slick front end environments show up in Drupal themes. The promise that talented front enders with little Drupal knowledge can jump right in is much closer to reality.  However, before diving into this new front end bliss there are still some gotchas, plus lots of baked in goodies Drupal provides that one will need to have a handle on before getting started.

This training will focus on the UI_Patterns module, which although still in Release Candidate state, it already solves many problems originated from the Drupal integration process.

Additional Resources
Drupalcon Baltimore 2017 - SEO, I18N, and I18N SEO| Blog 
Drupalcon: Not Just for Developers| Blog 
The Real Value of Drupalcon | Blog 

Feb 19 2018
Feb 19

It took a while before I could write a new edition, I was just busy with the production of customer projects. Here again with a brand new version, what struck me in module updates in the past month:

1. D8 Editor Advanced link

A popular module that extends the standard editor in Drupal 8 with additional options for managing links. You can now add the following attributes:

  • title
  • class
  • id
  • target
  • rel

2. Password strength

Default password checks are stupid and annoying for the user: they can check the entered password meets certain rules, such as the number of characters and varying types herein (symbols, numbers, capital letters etc.).

This is a stupid way of checking because the password ‘Welcome123’ is accepted, while it is easy to guess.

This module enables a secure password policy by “pattern-matching” and “entropy calculation”. Almost every type of password is accepted, as long as it has sufficient entropy.

Source

How it works

Instead of checking strict rules, this module calculates the expected time a brute force attack needs to retrieve the password. This is calculated based on underlying patterns:

  • Words that appear in a standard dictionary, common first and surnames and other default passwords.
  • Words from a dictionary, but written in Leet / 1337. For example, where the “e” is written as a three and “a” like an @.
  • A standard sequence of letters like “abcdef”, “qwerty” or “123456”
  • Dates or years.

This module has been around since 2007, I wonder why I only encounter this now :) It is currently available in alpha for Drupal 8 and stable for Drupal 7 available — it is supported by Acquia and Card.

So if you want people to not have to bother to look for a password such as “one special character, 1 upper case and at least 8 characters’, then this module offers a solution.

3. Better Field Descriptions

In order to give content managers issues, it is possible to write an explanation of all content fields that they import. But the standard explanation in a field in the backend of Drupal are often irrelevant, to not apply these generic texts in the implemented *user story* of the installation concerned.

After installing this module you can:

  • Content managers have their own explanation text per field.
  • Set where it stands: above or below the field.
  • The explanatory style that you like.

4. Better login

Want to make the standard Drupal login screen better? Then install this module and you are good to go: through template overrides you can then do the required further tuning of the layout of the login screen.

5. Ridiculously Responsive Social Sharing Buttons

Another social sharing module, but as you see in the title: these are terribly responsive. The icons are SVG based and you need no external services such as AddThis.

Advantage: you’re less dependent and have your data in hand, downside: you have less functionality- such as comprehensive statistics.

6. Flush Cache

If you are not using Drush or Drupal console works then you can Drupal caches flush via “the ‘Flush all caches” button in the Drupal backend. But in a production environment, you will almost never flush all caches, it can cause severe performance problems.

This module solves that problem: install it and you have more control over the caches you want to flush.

7. Multiple Selects

Have your Drupal content management easier with ‘multiple selects’ administration, this image seems to me to speak for itself:

8. Neutral paths

If you are running a multilingual Drupal website, visitors can see the content in one language: the currently active language. Sometimes you would like to see pages in another language. In addition: content managers / Drupal administrators usually want English and not the backend *default language*, in our case, often Dutch.

Issue tracking for example, much easier if the backend is in English: Drupal documentation and support in English is much more available than in Dutch.

This module ensures that you can visit other pages in another language than the default. And can navigate the backend in English, while frontend is in another language.

9. Password Reset Landing Page (PRLR)

Drupal core includes a ‘password’ function: If you have forgotten your password then you can request a one-time login link that is automatically mailed to you.

If you click on the login link, you will see a screen with a login button. Once you click the ‘login’ button you are logged in and you are redirected to your profile page — that’s it.

You are in this situation where your password is lost / forgotten. You are not required to change your password. This is not usually done, so people often endlessly request login links.

This module solves this: the screen where you end up after clicking on the login link not only contains a login button, but also a function to change your password immediately.

10. Auto Purge Users

The user list in Drupal is usually not or hardly ever administered. If people have long been inactive or have not completed their registration, the account can usually be removed to avoid overhead and security issues.

This module does it for you automatically, it checks inactivity below a point and blocks users if they meet:

  • Certain time inactive.
  • Account never activated after registration.
  • Not been logged in for a period of time.

Not a popular module, but in the case of an example Drupal social intranet it can come in handy.

11. Vertical Tabs Config

Want to influence the order of the Drupal tabs? Or do you want some tabs to not show all of your content manager? To keep tabs simple and usable you can install this module: select which tabs to show and in what order.

Modules with similar functions: Simplify and Hide vertical tabs.

12. Custom Search

The default Drupal search is fine, but really standard: you have few options to tune the engine. After installing this module, changes that you can then include are:

  • Change the default label in the search box.
  • Set a default text in the search box.
  • Tune ‘Advanced Search’.
  • Change the text on the “submit button”.

And much more, see module page:

13. Persistent Login

Drupal 8 core does not have a ‘remember password’ function when you log in. You can remain automatically logged for some time, but that is based on a PHP session. This module does not, you can also:

  • How long users can stay logged in.
  • How many places a person can be logged in at once.
  • Select certain pages that the user must log in again at. These are usually pages where more sensitive information is available.
  • Allow the user to delete all his logins themself.

14. Realistic Dummy Content

Wisdom

Using the Devel module you can automatically generate content so you can see if your modules / themes work well. But it gives an unrealistic picture of the end result, this module generates more realistic images and texts.

15. Password Policy

Although I am a fan of the aforementioned ‘Password strength’ module, this can also be useful if you want to make a specific password policy on your Drupal website.

16. Mass Password Reset

This module, we often use to implement Drupal social intranet: previously, all users and content created by an administrator on a test environment, without it people were informed through e-mail.

Once the social intranet went live, we sent all users at once an email with a login link via this module; the system was live!

Wrap Up

So far that’s what I noticed last month in Drupal modules, stay tuned for more fat Drupal content!

Source header image

Feb 15 2018
Feb 15

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. Parts three and four then to set up a product variation type and a product type, both with custom fields. This completes our new product configuration.

In part five, the last of this series, we'll finally get to try out the new product! We'll add a product to the store as if we are a store administrators (end user) who is creating content. We'll try out all of the fields and properties we've configured, make a product, and view it on the site. Afterwards, we'll cover how an administrator can then go in and edit the product to make content changes.

This entire video series, parts one through five, 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.

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.

Visit Our Drupal Commerce 2 Demo Site

More from Acro Media
Drupal modules used in this video

Contact us and learn more about our custom ecommerce solutions

Feb 15 2018
Feb 15

Last fall at BADCamp it was exciting to see that a component-driven approach to building Drupal 8 themes is becoming the standard. Many people are doing great things to advance this approach, including reducing duplication and simplifying data structures. In the day-long front end summit, and in many sessions and BOFs during BADCamp, great tips were shared for making the most of helper modules, such as the UI Patterns module, as well as techniques that make the most of Pattern Lab, KSS, and other front end systems.

While Drupalers are rejoicing at these exciting advances allowing newfound front end freedoms, there are still a few hoops to be aware of in order to make the most of Drupal, especially for a newcomer who might be eager to shove aside a lot of what Drupal provides. Some of these things, like contextual links, are nice-to-haves that can make life easier for content administrators. However, other things that are easily dismissed in a component-driven approach, like letting Drupal fully render fields, can cause headaches further on if they’re ignored, and make life difficult when it comes to keeping your front end forward-compatible with Drupal.
 

A Quick Recap of the Component-Driven Approach

At its basic level, the component-driven approach to Drupal theming means:

  1. Breaking your site’s interface down into independent components.
  2. Organizing those components into a system of reusable parts (i.e., the Atomic Design philosophy).
  3. Build out those parts however you see fit in a standalone presentation platform that supports twig (i.e., a KSS, or Pattern Lab style guide), with the pieces of those components that can change set up as variables in the twig files.

These component twig files that you use to build your system of reusable parts essentially serve as replacements for the templates in your Drupal theme (field.html.twig, block.html.twig, node.html.twig, etc.) You’ll still need the Drupal templates -- for now, see the UI Patterns module note at the end -- but they only serve as the “presenter” that helps map values from Drupal to the appropriate variables in your component template. The biggest payoffs with this approach are:

  1. Build things how you like them! You’re in control of the markup, and don’t necessarily have to be a seasoned Drupal developer to dive in.
  2. Back end setup, and front end build out can happen at the same time.
  3. A more organized, and structured presentation layer that’s not strictly tied to Drupal, and could potentially be repurposed for other platforms.

For a deeper dive into the components-driven approach, be sure to check out Mario Hernandez’s blog post series on integrating components into Drupal: Part 1, Part 2, and Part 3.

So if you’re not following a component-driven approach already, I’m sure you can see why it’s becoming popular. However, before diving in, here are a few things to consider to help you keep your approach forward-compatible with Drupal, and hopefully avoid headaches.
 

When It Comes To Fields, Let Drupal Do Its Thing

As we know, the default field markup in Drupal 8 is abstracted to account for field labels, and multiple values. This means that by default in Drupal even a simple, single value text field is going to render with multiple layers of <div>s wrapping the value of the field. However, let’s say you have a callout component in your style guide that includes an optional subtitle field. You’d probably mark that up with just a single, semantic element, like this:
 

{% if subtitle %}
 <h3 class=”callout__subtitle”>{{ subtitle }}</h3>
{% endif %}


And let’s say on the Drupal side of things you’re going use a custom block type for adding callout components to your site. Therefore, in the block--callout.html.twig template that serves as the “presenter” for mapping Drupal values to the component template, you’d have something like this:
 

{% include ‘@custom_theme/callout/callout.twig’ with {
  ...
  ‘subtitle’: content.field_subtitle
  ...
} %}


Since we’re letting Drupal render the subtitle field in our block template, we’d end up with all the default field markup inside our <h3>, which isn’t what we want at all.

While the quickest solution may be to pull out the value of the subtitle field from the render array for the field, and pass that to the component template...
 

‘subtitle’: content.field_subtitle.0['#context].value 


...this can come back to bite you later because of the way Drupal 8 handles caching. One option that’s more cache-friendly is to use the Twig Field Value module. This module gives you custom filters that help you safely pluck the value you need from the render array for the field:
 

‘subtitle’: content.field_subtitle|field_value


This is better, but we’re still shoving aside how Drupal adds attributes to the field markup. We’d only have our custom class on the <h3> for the subtitle, with no way for modules in the Drupal ecosystem to inject their classes or other attributes. As some of the “Outside-In” initiatives in Drupal start to mature this will become increasingly important if you want to take advantage of them. What follows are some options for how you can make your components more “loyally” accommodate Drupal.
 

Follow Drupal’s Lead For Field Markup

First, you could markup your component templates with additional wrappers that include only your classes, which would apply styling to the semantic element included in the variable output of your component template. Understandably, this could lead to a bit more bloated styling and markup, plus require you to include markup in the sample data that your style guide uses. Example:

Component markup:

{% if subtitle %}
  <div class=”callout__subtitle-wrapper”>
    {{ subtitle }}
  </div>
{% endif %}

Component placeholder data in the style guide:

{
  “subtitle”: “<h3 class=\”callout__subtitle\”>Subtitle Text</h3>”
}

In this case, when the component is implemented on the Drupal side of things, you would create a custom field template for the subtitle field, where you would change the markup to use only a single <h3>, plus add the “callout__subtitle” class via the Drupal addClass() function.

Drupal field template for the subtitle field in our “callout” custom block type:
 

<h3{{ attributes.addClass(‘callout__subtitle’) }}>
  {%- for item in items -%}
    {{ item.content }}
  {%- endfor -%}
</h3>

But Wait, I Want Control Of My Markup!

The previous option somewhat defeats the purpose of the markup freedom you get with a component driven approach, so you may want to instead consider leaving the component markup nice and lean, and just use a <span> tag for the subtitle field where the Drupal-specific attributes can be applied.

Component markup:

{% if subtitle %}
  <h3 class=”callout__subtitle”>
    {{ subtitle }}
  </h3>
{% endif %}

Component placeholder data in the style guide:

{
  “subtitle”: “Subtitle Text”
}

Drupal field template for the subtitle field in our “callout” custom block type:

<span{{ attributes }}>
  {%- for item in items -%}
    {{ item.content }}
  {%- endfor -%}
</span>

This works pretty nicely, but you may find that those Drupal attributes really need to be output where they were intended: the main wrapper for the field.
 

Twig Embed To The Rescue

A good middle ground for keeping your markup lean, but still loyally accommodating Drupal attributes, is to use twig embed blocks in your component template. This means you could put whatever you want inside the embed block declaration for the subtitle field in the component template, and on the Drupal side when the callout component is integrated via a twig embed, we simply swap that subtitle block with something else. Example:

Component markup:

{% block callout_subtitle %}
{% if subtitle %}
  <h3 class=”callout__subtitle”>
    {{ subtitle }}
  </h3>
{% endif %}
{% endblock %}

Component placeholder data in the style guide:

{
  “subtitle”: “Subtitle Text”
}

Drupal block template for integrating a callout component:

{% embed ‘@custom_theme/callout/callout.twig’ with {
  ...
  ‘subtitle’: content.field_subtitle
  ...
} %}
  {% block callout_subtitle %}
    {{ subtitle }}
  {% endblock %}
{% endembed %}

Drupal field template for the subtitle field in our “callout” custom block type:

<h3{{ attributes.addClass(‘callout__subtitle’) }}>
  {%- for item in items -%}
    {{ item.content }}
  {%- endfor -%}
</h3>

Accommodate Attributes All The Way Up

Now that we’ve established some options for accommodating Drupal at the field level, let’s take a look at how to accommodate Drupal in the block template for our callout component example.

One key Drupal feature that’s extremely helpful for content administrators is contextual links. To make these work in our callout component example we’ll need to accommodate the Drupal attributes variable on the main wrapper of the component template, plus include the title_prefix/title_suffix variables. These are what Drupal needs to inject the contextual links into a template.

Since the attributes variable can include class, id, and data attributes in one variable, we need to make sure we only combine Drupal’s classes with ours, and let the other attributes render without Drupal classes. This can be accomplished on the main wrapper of our callout component template:

<div class=”callout {{ attributes ? attributes.class }}”{{ attributes ? attributes|without(‘class’) }}>

Note that the ‘without’ twig filter in this example is a Drupal-specific filter, so for your style guide you’ll want to make sure you’re using one that supports Drupal’s custom filters (both KSS node, and Pattern Lab have configuration options that support Drupal twig filters.)

The other thing you’ll want to include to make sure contextual links get injected are the title_prefix/title_suffix variables. You typically will want to include this around the markup for the main title of the component:

{{ title_prefix }}
<h3 class=”callout__title”>
  {{ title }}
</h3>
{{ title_suffix }}

Make Sure Empty Means Empty

You may recall when first discussing the subtitle for our callout component it was mentioned that it would be an optional field, and in our component template we include an ‘if’ statement to check for a populated subtitle before outputting its related markup. One thing to keep in mind when letting Drupal fully render fields is that even though no content may have been entered for the subtitle on the Drupal side, your component may still read the value of the rendered field as not being empty, and proceed with outputting the markup inside the if statement. This is especially problematic when you have twig debug turned on in your theme.

A reliable way to avoid false positives when checking for empty fields is to check the results of a field after applying the render and trim filters. Example:

‘subtitle’ = content.field_subtitle|render|trim is not empty ? content.field_subtitle


Leave No Content Unrendered

Finally, one last step we’ll want to take in our “presenter” template, is to make sure we allow Drupal to go ahead and do its render thing on the main content variable of the block, even though we’re only interested passing specific field values to our component template. This is again is to help avoid headaches with how caching is handled (read more about this here: https://www.drupal.org/docs/8/api/render-api/cacheability-of-render-arrays). We also need to make sure that we exclude the fields we passed over to our component template since we don’t want them to actually be output in the Drupal template. Example:

{{ content|without(‘field_title’, ‘field_subtitle’, ‘body’) }}


What The Future Holds

As mentioned in the beginning there is also UI Patterns module that many are embracing for a component-driven approach to Drupal site building. The benefit of this module is that it eliminates the need for the “presenter” template when integrating your components.

For now, though, if you find yourself in a position where your Drupal templates are having to serve as the presenter for your components, make sure to consider these ways of keeping things as forward-compatible as possible with Drupal, so that you can take advantage of new Drupal initiatives as their rolled out, and save yourself some headaches later on.

Additional Resources
5 Advantages of Component Driven Theming | Video
Building Components: Breaking it Down | Blog
5 Aspects of Component Driven Back End Development with Drupal 7 | VIdeo

Feb 13 2018
Feb 13

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. In part three we set up a product variation type with custom fields. 

In part four of this series, we'll complete our overall product configuration by setting up a product type. The product type defines the type of product that you're creating (i.e. hat, shirt, shoe). This is what your store administrators will see when they add a new product to their catalog. By default, a product type will consist of a title, body, and variation type. We'll add some additional custom fields for things like taxonomy reference (for categorization), short description, specifications, product review, etc. 

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.

View part 5: How to Add and Modify Product Content

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.

Visit Our Drupal Commerce 2 Demo Site

More from Acro Media
Drupal modules used in this video

Contact us and learn more about our custom ecommerce solutions

Feb 13 2018
Feb 13

On a recent project, I had to create a custom page which displays content by the logged in user, think of it as a “My articles” or “My blogs” page. I knew how to do it by writing code but I thought I’d try it with Views and see how far I could get without writing any custom code. Long story short, I was able to do it all by using just the Views module.

In this tutorial, you’ll learn how to create a page which will appear as a tab (local task) on the user profile page.

Getting Started

For once there are no extra modules to download and install. In Drupal 8, Views ships with core and will be automatically installed if you installed Drupal using the Standard installation profile.

If it’s not already installed, go to Extend and install Views and “Views UI”.

Create User Profile Page

The first bit of work we need to do is create an actual Views page.

This page will display a table of articles which is owned by the user, we’ll call it “My articles” and the URI to the page will be /user/%user/my-articles the %user argument will be the user ID which will be used by the contextual filter.

The owner of the content is defined by the user added to the “Authored by” field on the content edit page.

1. Go to Structure, Views and click on “Add view”.

2. Fill in the “Add view” form with the values defined in Table 1.0.

Table 1.0: Add view

Option Value View name My Articles Machine name my_articles Show Content (default) Of Type Article Create a page Checked Page title My Articles Path user/%user/my-articles Display format Table

3. If you go to /user/%user/my-articles replace %user with any number, it should return a table of articles.

Create Contextual Filter

The %user argument getting passed through the URI is not being used at this point. Let’s now add a contextual filter which will use the argument and only display articles which are authored by the user ID.

1. While on the Views edit page, click on Advanced then Add next to Contextual filters.

2. Search for “Authored by” in the Content category and click on Add.

3. Select the “Provide default value” radio button and choose “User Id from route context”

4. Further down the page:

  1. Check “Specify validation criteria”.
  2. Select “User ID” from Validator.
  3. Check “Validate user has access to the User”.
  4. Under “Access operation to check” select Edit.

5. Click on Apply to save the contextual filter, then click on Save to save the view.

Now if you go to the page, /user/%user/my-articles make sure you change %user with an actual user ID, you should only see their articles.

Page Access Control

Please make sure you’ve checked “Validate user has access to the User” and have chosen Edit under “Access operation to check”.

This means that only users who have edit access can access the page. This would be users accessing their own accounts or site administrators who can edit other user accounts.

If you do not then any user who knows the URI /user/%user/my-articles could go directly to it and see which articles are owned by the user.

Display Page as Tab (Local Task)

At this point, we’ve created the page and added a contextual filter to only display articles owned by the user.

Now let’s create a menu for the page so it’s accessible via a tab on the user profile page.

1. While on the views edit page, click on “No menu” link in the “Page settings” section.

2. In the “Page: Menu item entry” window, complete the following:

  1. Select “Menu tab” from Type.
  2. Add “My articles” to “Menu link title”.
  3. Select “<User account menu>” from Parent. This is important if you don’t do this then the tab won’t appear.
  4. Add 5 to weight.

3. Now if you go to the “My articles” page it should go from this:

To this:

If you can’t see the tabs but have configured it properly then try rebuilding the site cache. Go to Configuration, Performance and click on “Clear all caches”.

Summary

The ability to create these types of pages is where Views really shines. Often a client will ask for a content specific page such as a “My blog” or “My articles” page and Views makes it very easy to create these types of pages.

FAQs

Q: “My Articles” tab is not appearing.

First, make sure you’ve chosen “<User account menu>” from the Parent drop-down. Second, try rebuilding the site cache (go to Configuration, Performance and click on “Clear all caches”) and see if that fixes it.

Ivan Zugec

About Ivan Zugec

Ivan is the founder of Web Wash and spends most of his time consulting and writing about Drupal. He's been working with Drupal for 10 years and has successfully completed several large Drupal projects in Australia.

Feb 12 2018
Feb 12

We have had a tradition since 2005. Every new year we have a posting on the predictions for the year ahead for our beloved open source CMS and community. Sometimes this posting went up in december, sometimes in January. But never in February.

Time to start a new tradition, predict the year ahead from February on :-)

Leave a comment if you do think that blogging will get hip again, RSS will gain new ground. What will the roll of the Drupal Association be in the new year? Where will the next DrupalCon be? Will the community grow and in what direction? API first, customer first, mobile first?

Polish your crystal ball and tell us what the future of Drupal wil be.

If you need some inspiration, take a look at 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015.2016 and
2017.

And yes, this posting was once month late. Apologies. Feel free to predict when the new prediction posting will go up on d.o :-)

So do post your predictions at https://www.drupal.org/forum/general/news-and-announcements/2018-02-11/predictions-for-2018.

Feb 12 2018
Feb 12
Login or get out!

Currently we are busy constructing the production of a realtime messaging platform in Drupal and NodeJS, look at it as a ‘WhatsApp for Business’. This Drupal system works like a web app; logging in is mandatory. How do you make sure that logged out visitors must log in to Drupal 8 before they are allowed to continue?

Drupal has many out-of-the-box functionalities, as well as a powerful API, but because it has so many functions many tracks are standardly available for anonymous visitors. We’d want to make all paths unreachable, until you log in.

That means that visitors always will be redirected to the login screen as long as they aren’t logged in. You wouldn’t want an anonymous user reaching internal news on the homepage.

Redirect URL in Drupal 8

Basically, we want all url’s / paths be made unavailable for non-logged in visitors, except explicitly specified pages like:

  • Login (/user)
  • Forgot password (/user/password)
  • Login link (user/reset/login)

in Drupal 7 you could use the module Logintoboggan for that purpose. You could also easily work around it in hook_init() or hook_boot() in a custom Drupal 7 module.

Quest

This was quite a puzzle, and we soon found some examples as well as exceptions. Everytime it didn’t work how we wanted it to. This example was the most useful.

Implementation in Drupal 8

Eventually, we got it working with the help of following code in a custom Drupal 8 module:

services.yml

put this file in your module root, and format yourmodulename.services.yml:

RedirectAnonymousSubscriber.php

Put the file RedirectAnonymousSubscriber.php in folder /src/EventSubscriber/ and do your custom thing:

This code builds on symfony’s EventSubscriber, the framework on which Drupal8 has been built.

Wrap up

Alright, that’s it. I hope the information as described will help you to always redirect visitors to the login page. Questions or feedback? Let me know!

Feb 06 2018
Feb 06

Because Drupal has so many options and so much flexibility, it can be a bit intimidating to newcomers. It doesn't show you examples of what it can do, and it kind of seems to do nothing by default. We realized people needed to be shown just how cool it really is, so we built a demo site to do just that.

The setup

We focused on making it only with out-of-the-box stuff, restricting ourselves to the features and functionality that exist within Drupal Commerce ecosystem itself. No custom code or modifications other than normal theming. That's right: Using only what's available out there now, we came up with a pretty amazing ecommerce site, if we do say so ourselves.

One caveat: we did make a custom theme for the demo, which you'll probably want to do anyway. There are the default Drupal themes, but most people are going to want to create a custom one. But that's a relatively simple task for a front-end developer; you don't need a back-end developer as well.

All the other setup can be done through basic Drupal UI point-and-click configuration. If you're somewhat savvy with configuring Drupal, you can do it all yourself in a very short time, and produce a truly phenomenal site.

Sometimes you need some guidance

Many people wonder how it could possibly be so easy. We've been getting a lot of questions like, "How did you build this big amazing catalog?" And the truth is we didn't actually do that much. We just enabled and configured the functionality that was already available. Drupal has this great Search API (and associated modules, Solr and Facets) that lets you do a ton of search customizations for anything that's stored in Drupal (blog articles, users, products, whatever), so all you have to do is tweak the configurations and you get this amazing catalog.

It's not that hard, but it's not that intuitive either; you just need a little guidance and direction. Sometimes just seeing an example is enough to make you realize how easy it can be. And that's exactly what the demo provides. It features a checkout, tax configurations, some shipping options, and even a sample payment system. You can click around and check it out without fear of breaking things, the database resets every night.

When you go to the demo site initially, a popup is preseted with a bunch of guided tours, but you are of course free to ignore that and just play around with it yourself. We're also releasing a bunch of tutorial videos to help you. We also have a resources page that shows a lot of the different features you can check out.

Plus, all the source code for the demo, including the custom theme, is available on GitHub. Within the repo is a full database dump so you can set up the entire thing yourself locally (see the README.md). AND one of the Commerce module maintainers, Bojan Živanović, is taking some of the content and configuration from the demo and turning it into an installable demo store module.

It's seriously awesome. Check it out!

Chat with us

If you'd like a personalized tour to discuss how Drupal Commerce fits into your omnichannel solution, give us a shout. We're happy to show and tell.

Contact Us

Feb 06 2018
Feb 06

Webform allows you to create powerful forms in Drupal without writing any custom code. One feature I want to show you today is predefined options.

If this is the first time you’ve heard of the module and want to learn more check out our two part series on using Webform.

Predefined options ease the creation of forms by offering common lists such as days, months, time zones, titles, etc…

For example, if you want to add a select list where users choose a country, instead of manually entering in all countries yourself, use the predefined one that comes with the module.

Webform comes with around 30 predefined lists which can be added to radio buttons, checkboxes, select list and menus. You can also create your own.

If you have a website that will use the same set of options on multiple forms, look at creating a predefined options list to save time.

In this tutorial, you’ll learn how to create and use predefined options.

Getting Started

This is part of the Webform module, so I’m going to assume you have it installed.

If you’ve never installed it check out our “Getting Started with Webform in Drupal 8” tutorial.

Use a Predefined Option

Let’s now look at using one of the predefined options in a select element. Let’s assume you need to create a select element with days as the options, Monday, Tuesday, etc…

1. From the Webforms page, go to the Build page of any form by clicking on Build.

2. Then click on “Add element”, search for “select” and click on “Add element” on the Select row.

2018-02-02_22-14-10.png

3. Enter in a title for the element, you could call it Day.

4. From the Options drop-down, select Days and then Save.

2018-02-02_22-16-21

5. If you view the form, you should see a drop-down called Day with days as the options.

2018-02-02_22-19-10.png

You just saved yourself the effort of manually filling out the days.

Manage Predefined Options

To manage all the predefined options go to Structure, Webforms, Configuration and then click on Options.

2018-02-02_14-16-48.png

From this page, you can view all the options create custom options and modify existing ones.

Let’s now modify the Days options so that Monday is the first day.

1. Click on Edit on the Days row.

2. Reorder the options so that Sunday is at the bottom then click on Save.

2018-02-02_22-29-27.png

3. Now if you view the form, Monday should be the first option.

Take note, if you’re using the same predefined option on multiple elements and change the options (like we just did), then the change will appear on all elements.

Create Predefined Options

Creating your own predefined options is very easy.

1. While on the Options page, click on “Add options”.

2. Give your options a label and some values, then click on Save at the bottom of the page.

3. Select your predefined options from the Options drop-down on a select or checkbox element and you’re done.

Summary

The editors and marketers who use Webform to create custom forms will love this functionality. Out-of-the-box it comes with a bunch of common options such as days, months, “time zones”, “country codes” and more. On top of that you can create your own custom options which’ll save you a lot of time in the long run.

Ivan Zugec

About Ivan Zugec

Ivan is the founder of Web Wash and spends most of his time consulting and writing about Drupal. He's been working with Drupal for 10 years and has successfully completed several large Drupal projects in Australia.

Feb 01 2018
Feb 01

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.

View 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.

Visit Our Drupal Commerce 2 Demo Site

More from Acro Media
Drupal modules used in this video

Contact us and learn more about our custom ecommerce solutions

Feb 01 2018
Feb 01
February 1st, 2018

Paragraphs is a powerful Drupal module that makes gives editors more flexibility in how they design and layout the content of their pages. However, they are special in that they make no sense without a host entity. If we talk about Paragraphs, it goes without saying that they are to be attached to other entities.
In Drupal 8, individual migrations are built around an entity type. That means we implement a single migration for each entity type. Sometimes we draw relationships between the element being imported and an already imported one of a different type, but we never handle the migration of both simultaneously.
Migrating Paragraphs needs to be done in at least two steps: 1) migrating entities of type Paragraph, and 2) migrating entities referencing imported Paragraph entities.

Migration of Paragraph entities

You can migrate Paragraph entities in a way very similar to the way of migrating every other entity type into Drupal 8. However, a very important caveat is making sure to use the right destination plugin, provided by the Entity Reference Revisions module:

destination: plugin: ‘entity_reference_revisions:paragraph’ default_bundle: paragraph_type destination:plugin:entity_reference_revisions:paragraphdefault_bundle:paragraph_type

This is critical because you can be tempted to use something more common like entity:paragraph which would make sense given that Paragraphs are entities. However, you didn’t configure your Paragraph reference field as a conventional Entity Reference one, but as an Entity reference revisions field, so you need to use an appropriate plugin.

An example of the core of a migration of Paragraph entities:

source: plugin: url data_fetcher_plugin: http data_parser_plugin: json urls: 'feed.url/endpoint' ids: id: type: integer item_selector: '/elements' fields: - name: id label: Id selector: /element_id - name: content label: Content selector: /element_content process: field_paragraph_type_content/value: content destination: plugin: 'entity_reference_revisions:paragraph' default_bundle: paragraph_type migration_dependencies: { } plugin:urldata_fetcher_plugin:httpdata_parser_plugin:jsonurls:'feed.url/endpoint'    type:integeritem_selector:'/elements'    name:id    label:Id    selector:/element_id    name:content    label:Content    selector:/element_contentfield_paragraph_type_content/value:contentdestination:plugin:'entity_reference_revisions:paragraph'default_bundle:paragraph_typemigration_dependencies:{  }

To give some context, this assumes the feed being consumed has a root level with an elements array filled with content arrays with properties like element_id and element_content, and we want to convert those content arrays into Paragraphs of type paragraph_type in Drupal, with the field_paragraph_type_content field storing the text that came from the element_content property.

Migration of the host entity type

Having imported the Paragraph entities already, we then need to import the host entities, attaching the appropriate Paragraphs to each one’s field_paragraph_type_content field. Typically this is accomplished by using the migration_lookup process plugin (formerly migration).

Every time an entity is imported, a row is created in the mapping table for that migration, with both the ID the entity has in the external source and the internal one it got after being imported. This way the migration keeps a correlation between both states of the data, for updating and other purposes.

The migration_lookup plugin takes an ID from an external source and tries to find an internal entity whose ID is linked to the external one in the mapping table, returning its ID in that case. After that, the entity reference field will be populated with that ID, effectively establishing a link between the entities in the Drupal side.

In the example below, the migration_lookup returns entity IDs and creates references to other Drupal entities through the field_event_schools field:

field_event_schools: plugin: iterator source: event_school process: target_id: plugin: migration_lookup migration: schools source: school_id field_event_schools:  plugin:iterator  source:event_school  process:    target_id:      plugin:migration_lookup      migration:schools      source:school_id

However, while references to nodes or terms basically consist of the ID of the referenced entity, when using the entity_reference_revisions destination plugin (as we did to import the Paragraph entities), two IDs are stored per entity. One is the entity ID and the other is the entity revision ID. That means the return of the migration_lookup processor is not an integer, but an array of them.

process: field_paragraph_type_content: plugin: iterator source: elements process: temporary_ids: plugin: migration_lookup migration: paragraphs_migration source: element_id target_id: plugin: extract source: '@temporary_ids' index: - 0 target_revision_id: plugin: extract source: '@temporary_ids' index: - 1 field_paragraph_type_content:  plugin:iterator  source:elements  process:    temporary_ids:      plugin:migration_lookup      migration:paragraphs_migration      source:element_id    target_id:      plugin:extract      source:'@temporary_ids'      index:        -0    target_revision_id:      plugin:extract      source:'@temporary_ids'      index:        -1

What we do then is, instead of just returning an array (it wouldn’t work obviously), use the extract process plugin with it to get the integer IDs needed to create an effective reference.

Summary

In summary, it’s important to remember that migrating Paragraphs is a two-step process at minimum. First, you must migrate entities of type Paragraph. Then you must migrate entities referencing those imported Paragraph entities.

More on Drupal 8

Top 5 Reasons to Migrate Your Site to Drupal 8

Creating your Emulsify 2.0 Starter Kit with Drush

Web Chef Joel Travieso
Joel Travieso

Joel focuses on the backend and architecture of web projects seeking to constantly improve by considering the latest developments of the art.

Web Chef Dev Experts
Development

Blog posts about backend engineering, frontend code work, programming tricks and tips, systems architecture, apps, APIs, microservices, and the technical side of Four Kitchens.

Read more Development
Jan 31 2018
Jan 31

Illustration of person scratching head at fork in the road

This is the first part in a series on how not to ruin your life on your next Drupal project. Sound extreme? Well, if you’ve ever suffered the crushing defeat of working your tail off on a lengthy project only to sit there at the end after launch feeling like you just came out of the opening night of Star Wars: The Phantom Menace (ie: severely disappointed and a bit confused), then you know that it is indeed extreme. We spend a majority of our day at work and when it’s not rewarding or energy-giving, it’s a real drag.

So what is the formula? Well, a blog post isn’t going to solve all your problems - but - there are certainly key approaches that we have taken that have helped us avoid catastrophe time and time again. Translation? We’ve managed an extremely high customer satisfaction rate for over two decades. What’s been happening here seems to be working so we pay a lot of attention to what it is exactly that we are doing and assess why we think it’s working. If you want a high-level bird's-eye view, check out our process page. We are going to get a bit downer and dirtier here though.

Ultimately, we want you to go home to your family at the end of the day saying “GUESS WHAT I DID AT WORK TODAY EVERYONE!!” (like we do) instead of “Can we just order pizza and go to bed at 7?”.

 We’ve identified 3 essential components to kicking a project off right, the first of which will be covered in this post. They are the following:

  1. Aggressive and Invested Requirements Gathering
  2. Relentless Ideation
  3. Atomic Preparation

So let’s start with Aggressive and Invested Requirements Gathering. We spent a lot of time thinking about this and I realized it comes down to the adjectives. Everyone knows (mostly) about requirements gathering, but it’s a minefield of unasked questions, unanswered questions, misconceptions, forgetfulness, and chaos. The solution? Take ownership of this baby from the beginning and treat it like it’s your project - it’s your passion - and do what it takes to nail it down. Getting answers that make your life easier, despite your suspicions that the client is maybe not thinking it through, doesn’t help anyone. Take no shortcuts and care about everything.

“Take ownership of this baby from the beginning.”

Here are 3 specific goals:

Assess priorities (theirs and yours!)

Priorities are key because we can easily get hung up on things that ultimately aren’t that important. On the flip side, there are things that are tremendously important to one of the two parties, and hence, it must be important to both. So the client says I care most about X, then Y, then Z. In your head you’re thinking “Yikes, Z has a huge unknown element that I’d like to solve quickly to understand the implications.” So talk about it. Repeat their priorities back to them and state your own and find that happy middle ground where you can pursue the project in an efficient and effective way while also focusing on what matters. It sounds simple, but unspoken expectations or concerns are a plague in project management.

Determining constraints (time, money, features, personnel)

I still love the age-old project management triangle that says that for any given project, you can choose 1 of the 3 key priorities in a project: time, money or features. This means that you can’t simply dictate the budget and the schedule and also expect a very rigid set of requirements. The problem is that despite even stating this, there is a lot of pressure from the client to set the expectation on all three and that simply isn’t possible. So it’s critical early on to sort out what the real constraints are. Ok, you would like this to stay under $50k. Is that a hard cap or could you go over if you felt it was worth it? So you want this launched by January 1st. Is that more of a clean-sounding date or is this tied to a fiscal year, or some other real deadline? Ok, so you want features X, Y and Z. Which of those would be deal breakers to not have? This kind of questioning is very helpful because early on in the build phase, you can make intelligent decisions about how and when to collaborate with the client since you know the significance of obstacles or changes of directions that impact these things.

The last thing I’m throwing on top of this triangle is the concept of personnel. We’ve found that knowing who your stakeholders are, who your end users are, who your editors and admins are - early on - is critical. I’ve literally had meetings where we’re deep into requirements and then I meet the person who has veto power over everything and the thing goes sideways. We’ve learned as well that there is a repeating sales cycle when new stakeholders arrive because convincing the last three people doesn’t mean you’ve convinced the next three. I’ve also had times where a stakeholder makes some critical decisions, but then after talking to the people “on the ground”, I find that he was simply just wrong on some of the day-to-day operations. It’s good to talk to everyone, but also find out each person’s role in the big picture. Often times we’ve found ourselves advocating on behalf of lower level employees who often bring up important and practical issues that decision-makers are often overlooking. It’s a delicate balance, but if the system isn’t welcomed and adopted well by it’s primary users, the project will sink even if the ones writing the checks are getting what they think they want.

Reading between the lines

This is tied to the item above in a lot of ways, but stands on it’s own as an important point. When you’ve done this long enough, you learn that most of what is asked for by a potential client is not always really the point. Often there is a hidden goal or motivation that has led to the formation of a feature request. Even if that request perfectly solves the need, it’s still important to discover that need because it can affect the implementation and guide the specifics. For example, if a request is made to let users download an export of tracking data, but you dig and find out that actually they’re just using this tool to turnaround and upload it into a remote system and it’s a bit of a pain, maybe building a web service is better where their system can talk directly to ours and users can step out of the daily grind. 

Conclusion

So in summary - gathering requirements the same way you date someone you’re thinking of marrying. Care about it and pursue it as if it’s the most important thing you’ve got going with an end goal of a lifetime of happiness.

Up Next: Running a Drupal project the right way: Part 2 - Relentless Ideation 

Free offer, talk to a seasoned Drupal expert.

Jan 31 2018
Jan 31

Illustration of person scratching head at fork in the road

This is the first part in a series on how not to ruin your life on your next Drupal project. Sound extreme? Well, if you’ve ever suffered the crushing defeat of working your tail off on a lengthy project only to sit there at the end after launch feeling like you just came out of the opening night of Star Wars: The Phantom Menace (ie: severely disappointed and a bit confused), then you know that it is indeed extreme. We spend a majority of our day at work and when it’s not rewarding or energy-giving, it’s a real drag.

So what is the formula? Well, a blog post isn’t going to solve all your problems - but - there are certainly key approaches that we have taken that have helped us avoid catastrophe time and time again. Translation? We’ve managed an extremely high customer satisfaction rate for over two decades. What’s been happening here seems to be working so we pay a lot of attention to what it is exactly that we are doing and assess why we think it’s working. If you want a high-level bird's-eye view, check out our process page. We are going to get a bit downer and dirtier here though.

Ultimately, we want you to go home to your family at the end of the day saying “GUESS WHAT I DID AT WORK TODAY EVERYONE!!” (like we do) instead of “Can we just order pizza and go to bed at 7?”.

 We’ve identified 3 essential components to kicking a project off right, the first of which will be covered in this post. They are the following:

  1. Aggressive and Invested Requirements Gathering
  2. Relentless Ideation
  3. Atomic Preparation

So let’s start with Aggressive and Invested Requirements Gathering. We spent a lot of time thinking about this and I realized it comes down to the adjectives. Everyone knows (mostly) about requirements gathering, but it’s a minefield of unasked questions, unanswered questions, misconceptions, forgetfulness, and chaos. The solution? Take ownership of this baby from the beginning and treat it like it’s your project - it’s your passion - and do what it takes to nail it down. Getting answers that make your life easier, despite your suspicions that the client is maybe not thinking it through, doesn’t help anyone. Take no shortcuts and care about everything.

“Take ownership of this baby from the beginning.”

Here are 3 specific goals:

Assess priorities (theirs and yours!)

Priorities are key because we can easily get hung up on things that ultimately aren’t that important. On the flip side, there are things that are tremendously important to one of the two parties, and hence, it must be important to both. So the client says I care most about X, then Y, then Z. In your head you’re thinking “Yikes, Z has a huge unknown element that I’d like to solve quickly to understand the implications.” So talk about it. Repeat their priorities back to them and state your own and find that happy middle ground where you can pursue the project in an efficient and effective way while also focusing on what matters. It sounds simple, but unspoken expectations or concerns are a plague in project management.

Determining constraints (time, money, features, personnel)

I still love the age-old project management triangle that says that for any given project, you can choose 1 of the 3 key priorities in a project: time, money or features. This means that you can’t simply dictate the budget and the schedule and also expect a very rigid set of requirements. The problem is that despite even stating this, there is a lot of pressure from the client to set the expectation on all three and that simply isn’t possible. So it’s critical early on to sort out what the real constraints are. Ok, you would like this to stay under $50k. Is that a hard cap or could you go over if you felt it was worth it? So you want this launched by January 1st. Is that more of a clean-sounding date or is this tied to a fiscal year, or some other real deadline? Ok, so you want features X, Y and Z. Which of those would be deal breakers to not have? This kind of questioning is very helpful because early on in the build phase, you can make intelligent decisions about how and when to collaborate with the client since you know the significance of obstacles or changes of directions that impact these things.

The last thing I’m throwing on top of this triangle is the concept of personnel. We’ve found that knowing who your stakeholders are, who your end users are, who your editors and admins are - early on - is critical. I’ve literally had meetings where we’re deep into requirements and then I meet the person who has veto power over everything and the thing goes sideways. We’ve learned as well that there is a repeating sales cycle when new stakeholders arrive because convincing the last three people doesn’t mean you’ve convinced the next three. I’ve also had times where a stakeholder makes some critical decisions, but then after talking to the people “on the ground”, I find that he was simply just wrong on some of the day-to-day operations. It’s good to talk to everyone, but also find out each person’s role in the big picture. Often times we’ve found ourselves advocating on behalf of lower level employees who often bring up important and practical issues that decision-makers are often overlooking. It’s a delicate balance, but if the system isn’t welcomed and adopted well by it’s primary users, the project will sink even if the ones writing the checks are getting what they think they want.

Reading between the lines

This is tied to the item above in a lot of ways, but stands on it’s own as an important point. When you’ve done this long enough, you learn that most of what is asked for by a potential client is not always really the point. Often there is a hidden goal or motivation that has led to the formation of a feature request. Even if that request perfectly solves the need, it’s still important to discover that need because it can affect the implementation and guide the specifics. For example, if a request is made to let users download an export of tracking data, but you dig and find out that actually they’re just using this tool to turnaround and upload it into a remote system and it’s a bit of a pain, maybe building a web service is better where their system can talk directly to ours and users can step out of the daily grind. 

Conclusion

So in summary - gathering requirements the same way you date someone you’re thinking of marrying. Care about it and pursue it as if it’s the most important thing you’ve got going with an end goal of a lifetime of happiness.

Up Next: Running a Drupal project the right way: Part 2 - Relentless Ideation 

Free offer, talk to a seasoned Drupal expert.

Jan 30 2018
Jan 30

Sprint Date: January 11 & 12, 2018

I knew it was going to be a good few days of sprinting when the first of our team (Vicki Spagnolo) pinged the group in IRC saying she was getting started. You see, this was a virtual sprint and Vicki, being in New Zealand, starts well before the rest of us. The excitement she had going into the sprint was contagious.

Bright and early, we had our first stand-up call on Google Hangouts. We discussed all of the tasks for the next few days and dove right into working on code. A lot of the benefit of a sprint is having others around with focus to review code, so we did a lot of reviews of each other's work. Lots of issues made it from “Needs Review” to “Reviewed and Tested by the Community” (RTBC), and we had several Core committers hanging out to assist us. Special thanks to Gabor Hojtsoy, Lee Rowlands and Jess Myrbo for all their commits over the 2 day sprint.

Some progress stats. We went into the sprint with 3 Core migrate modules that weren't marked as stable. The Migrate API module went stable during the sprint. The Migrate Drupal User Interface module had one blocking issues resolved, leaving a single blocker remaining (UPDATE: this has been resolved, too). Finally, the big one, the Migrate Drupal module itself has only a few limited blockers remaining, all related to i18n/multilingual use cases.

A great benefit of sprinting with a group is that we had people available who can provide guidance and direction on architecture. With the group, we landed on a good plan of action for all the remaining i18n/multilingual issues. We opened the sprint and saw significant progress on the first step in that plan. It isn't RTBC yet, but it should go soon. After which, we have to leverage the building blocks it provides for the remaining i18n/multilingual issues.

Yes, it's down to just a few issues. Once they are wrapped up (and we saw great progress, so I'm hoping soon), all of Migrate Drupal will go stable. I also expect that the Migrate Drupal UI module will go stable at the same time.

Summary:

  • 5 Critical blockers across the entire Migrate sub-system.
  • Migrate API module went stable! Only two more to go.
  • 25 issues worked on; all with significant progress seen during the sprint.
  • 15 commits, of which 10 were serious improvements in API documentation.
  • Remaining release blockers can be found here. Filter issue priority to ‘critical’. Feel free to jump in and help!

Modules involved:

Special thanks:

A huge thanks to all the sprinter: GaborHojtsy (Gabor Hojtsy), heddn (Lucas Hedding), xjm (Jess Mybro), larowlan (Lee Rowlands), masipila (Markus Sipilä), maxocub (Maxime Turcotte), phenaproxima (Adam Hoenich), quietone (Vicki Spagnolo).

Another big thanks to all the corporate sponsors: Acquia, Acro Media and Savoir-Faire Linux.

Migrate your site!

Do you have an ecommerce site that you want to migrate to Drupal 8, but not sure how? We can help! Contact us to discuss your migration with one of our experts, no strings attached.

Contact Acro Media Today!

Jan 30 2018
Jan 30

If you’re planning to use Bootstrap on your Drupal 8 site, the first obvious thing to do is download and set up the Bootstrap theme. Then, during the site building process, there will come the point where you need to create a few layouts. These layouts could be used for content types with Display Suite, or for custom pages using Panels.

Implementing layouts using the Bootstrap grid system is simple thanks to the Bootstrap Layouts module.

Read our “Getting Started with Bootstrap in Drupal 8” tutorial to learn how to use Bootstrap in Drupal 8.

Bootstrap Layouts is a module that ships a bunch of prebuilt layouts using the grid system in Bootstrap. Best of all, these layouts can be used between Display Suite and Panels, or any module which supports the Layout Discovery module.

The layouts are configurable through Drupal’s administrative UI. For example, you can adjust the width of a two column layout by choosing grid CSS classes from a multi-select field.

All this can be done without overriding a template or writing a custom preprocess hook.

In this tutorial, you’ll learn how to use Bootstrap Layouts with two popular modules: Display Suite and Panels.

Getting Started

Before we begin, go download and install the Bootstrap Layouts theme.

If you use Composer, run the following:

$ composer require drupal/bootstrap_layouts

Or Drush,

$ drush dl bootstrap_layouts

Other Requirements

First, make sure you’re using Bootstrap on your Drupal site. This could be via the Bootstrap theme or another theme which implements Bootstrap.

Read our “Getting Started with Bootstrap in Drupal 8” tutorial to learn how to use Bootstrap in Drupal 8.

Second, you’ll need to use it via a module which implements layouts using the Layout Discovery module. So far, two popular modules which use it are Display Suite and Panels.

Implement Layout using Display Suite

To implement this using Display Suite go ahead and install the module.

If you’re new to Display Suite then read our “Using Display Suite in Drupal 8: How to Customize Content Pages” tutorial with a video.

1. Go to the “Manage display” page of a content type. You can access it by going to Structure, “Content types” and click on “Manage display” from the Operations drop-down.

2. From the “Layout for article in default” tab, select a layout under Bootstrap.

3. Once selected you should see a preview of the layout.

Don’t forget to click on Save.

Change Column Width

One thing I love about Bootstrap Layouts is that you can change the column width without overriding the template.

The preview of layout shows it as having two columns, each 50% wide. Or in “Bootstrap speak”, 6 columns wide. You can change the width of the column by choosing a different class from the Classes select box from a region tab.

Implement Layout using Panels

Now that you know how to configure Bootstrap layouts using Display Suite, let’s look at using it with Panels and Page Manager.

If you’ve never used Panels or Page Manager, then check out our tutorial “How to Build Custom Pages Using Page Manager and Panels in Drupal 8“.

I’m going to assume you’ve already created a Panels page and will be switching the layout to one of Bootstrap Layouts’.

1. Go to Structure, Pages and edit an existing page.

2. Go to the Layouts section in the variant.

3. From the Layout drop-down select a Bootstrap layout, then click on “Change Layout”.

4. After clicking on “Change Layout” another link will appear below Layout on the left called “Layout Regions”. From this page you must add the existing blocks into the new regions. Once completed click on “Update and save”.

I must admit, it’s easy to miss this new page, but it’s a required step to changing layouts.

5. Now you should see a new link below Layout called “Layout Settings”.

From this page you can change the layout settings such as the grid CSS classes for each region. Same as when using Display Suite.

Summary

Bootstrap Layouts makes it really easy to build layouts because it comes with many prebuilt. But the most impressive feature is the ability to change the grid classes from the interface without having to override a template.

FAQs

Q: After clicking on “Change Layout” in Panels for a second time I get an error “You must select a different layout if you wish to change layouts.”. But nothing changes.

After clicking on “Change Layout” a new link will appear called “Layout Regions” below Layouts. You must reassign blocks into the new layout regions. This new link can easily be missed after clicking “Change Layout.

Ivan Zugec

About Ivan Zugec

Ivan is the founder of Web Wash and spends most of his time consulting and writing about Drupal. He's been working with Drupal for 10 years and has successfully completed several large Drupal projects in Australia.

Jan 27 2018
Jan 27

In 2018 there will not be a DrupalCon Europe organized by the Drupal Association, but it was loud and clear that the European Drupal community needs an opportunity to meet, connect and share.

A group of Drupal community volunteers took it upon themselves to put together an event, and to avoid confusion with the official DrupalCon, the “Drupal Europe” name was chosen. Drupal Europe is organised by this group in collaboration with the German Drupal Association and will be held on the week of September 10–14, 2018 in the beautiful Darmstadtium in Darmstadt, Germany, only 20 minutes drive from Frankfurt Airport.

In the enthusiasm of trying to fill in this huge gap, our team unfortunately did not consider all important conflicts that the dates of the event would incur for attendees and partly scheduled over religious holidays.

Photo by Estée Janssens on Unsplash

It was not our intention to exclude anyone from this event based on their religion. We’d like to sincerely apologize for this conflict. This was an honest mistake and clearly shows that we still have a lot to learn as event organizers. It also highlights the unfortunate lack of diversity in the organization team that we’d love to improve.

While we immediately reacted to concerns regarding the dates following the news, we spent considerable time preparing this announcement to understand the nature of the religious holidays involved at least after the fact, in hopes that we can adjust the programming as much as we can. The interfaith calendar told us some dates, but talking to people practicing those religions helped us understand the details better. Many people assume we’ll just use the regular DrupalCon schedule, however we’d like to experiment with some adventurous approaches. While we hoped to finalize the schedule structure by now to show exactly what is the impact of our scheduling mistake, we did not yet manage to get there. All we can promise at this point is we’ll take the conflicts into account as much as possible when setting up the schedule and ticket pricing.

If you are taking a longer holiday to spend with family, no internal program shuffling will help. In that case, we suggest other great international community events like DrupalCamp London (early March), Frontend United (early June), Drupal Developer Days (early July), IronCamp (second half of October as far as we heard).

The Drupal Europe organising team,

Adam Evertsson (AdamEvertsson)
Baddy Breidert (baddysonja)
Bert Boerland (bertboerland)
Billy Wardrop (billywardrop)
David Pacassi Torrico (dpacassi)
Floris van Geel (idevit)
Gábor Hojtsy (gábor-hojtsy)
Ivo Radulovski (ivoradulovski)
Janne Kalliola (jannekalliola)
Lars S. Linnet (lslinnet)
Levi Govaerts (legovaer)
Luís Algarvio (lpalgarvio)
Meike Jung (hexabinaer)
Marc Dinse (dernetzjaeger)
Stefan Auditor (sanduhrs)

Jan 25 2018
Jan 25

[embedded content]

In part one of this Acro Media Tech Talk video series, we covered how you set up a new product attribute in Drupal Commerce 2. A product attribute is used to define options that customers would select when buying a product. For example, a hat might have various sizes (small, medium, large) and colours available. These are attributes.

In part two, we'll now take a colour attribute that was set up in part one, but change it into a "rendered attribute". By default, the customer would select the option by seeing the name of the colour. A rendered attribute lets us instead show a colour swatch. So, instead of seeing the word "blue", the customer would see the actual colour. Cool!

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.

View part 3: Set up a Product Variation 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.

Visit Our Drupal Commerce 2 Demo Site

More from Acro Media
Drupal modules used in this video

Contact us and learn more about our custom ecommerce solutions

Jan 23 2018
Jan 23

Bootstrap is a front-end framework for building websites. It ships prebuilt CSS and JavaScript components that make building sites fast. It comes with all sorts of common components that every website needs such as a grid system, buttons, drop-down, responsive form elements, carousel (of course) and so much more. As a developer I don’t want to spend time styling yet another button. I just want to know which CSS class to add to an <a> tag so it looks like a button and I’m good to go.

One complaint about Bootstrap is you can spot it a mile away because a lot of developers use the default look-and-feel. When you see the famous Jumbotron you know it’s a Bootstrap site. But with a little bit of effort you can make your site look unique.

Now, another good reason to use Bootstrap is when you’re working with an agency who will design the site but has no Drupal expertize. If they can supply HTML wireframes using Bootstrap then it’s much easier to implement them into Drupal. Yes, in the perfect world it’ll be great to receive a fully built Drupal theme which can be enabled and that’s it. But in reality, most design agencies, unless they specialize in Drupal, don’t know it and this is where Bootstrap can help.

By using Bootstrap, it’ll be easier to work with designers and design agencies because you can discuss things using Bootstrap terminology. For example, a designer may ask, “can we have a sidebar on the right which is 3 columns wide”? Or, they may ask, “make this button on the blog listing page small”.

If you have experience using Bootstrap you should know what I mentioned above.

Luckily for us building a Drupal site using Bootstrap is easy thanks to the Bootstrap theme.

In this tutorial, you learn the following:

  1. Bootstrap theme configuration
  2. Create a Bootstrap sub-theme
  3. Compile Bootstrap locally using Sass

What About Bootstrap 4?

The Bootstrap theme as of this writing only supports Bootstrap 3. For details look at #2554199 in the issue queue.

Other Bootstrap Based Themes

Another theme you should evaluate is the Radix theme. If you know of any other Bootstrap based themes please leave a comment.

Getting Started

Before we can begin, go download the Bootstrap theme from drupal.org.

If you use Composer, run the following:

$ composer require drupal/bootstrap

Or Drush,

$ drush dl bootstrap

Configuring Bootstrap Theme

Before we jump into the advanced topic of sub-theming or compiling Sass. Let’s first look at what the theme offers out-of-the-box. In this section, we’ll look at some of the theme options.

The level of configuration in a Drupal theme varies a lot, however, the Bootstrap theme has a healthy amount of options. Enough to give you flexibility but not too much that you’re overwhelmed or confused.

Once you’ve downloaded the theme go to Appearance and click on “Install and set as default” on the Bootstrap theme.

Hover over 'Install and set as default'

Once installed click on “Settings”.

Bootstrap Settings

From the “Override Global Settings” you can configure common Drupal options such as the logo or favicon. If you’ve configured a Drupal theme in the past this should look familiar.

Override Global Settings options in Bootstrap

The vertical tabs under “Bootstrap Settings” is where you can configure specific Bootstrap options, let’s look at a few.

Fluid container

The “Fluid container” option,  which can be accessed by going to General then Container, this option adds the container-fluid class which’ll display the main region at full width. By default, the main region has a width of 1200px.

For more details check out the Containers section.

Images

While still under General, click on the Images field-set. This option let’s you configure how images will be handled.

Leave “Responsive Images” checked. This adds an img-responsive class to images making them responsive. It adds a max-width:100% so images are resized when viewed on mobile.

The “Default image shape” drop-down allows you to choose a different style for images which is done via CSS. I always leave this set to “None”.

For more details check out the Images section.

Advanced

Let’s now jump down to the “Advanced” section.

In this section, you can configure if Bootstrap will be served from a CDN and which version you want to use.

Theme

From the “Theme” drop-down you can choose a different theme. Most of the options come from Bootswatch.

So your Bootstrap site could go from this:

To this:

Tip: After I selected a theme I had to rebuild the site cache. Go to Configuration, Performance and click on “Clear all caches”. By the way, I chose Slate if you’re wondering.

Loading Bootstrap via a CDN is quick to setup, but hard to customize. If you’re planning to use a CSS processor such as Sass or Less then you’ll need to store Bootstrap locally and compile it.

We didn’t cover every option under “Bootstrap settings”, just the main ones. The rest you can figure out on your own.

Create Bootstrap Sub-theme

So far we’ve looked at changing options within the theme which is great for testing, but if you’re going to use Bootstrap on a proper project then it’s recommended you create a sub-theme.

Why Sub-theme?

When you create a sub-theme, the Bootstrap theme will be the “base theme” which means your sub-theme will automatically inherit all templates and assets such as the CSS and JavaScript.

Your sub-theme will automatically use any template from the base theme unless it’s overridden. If you want to modify the page.html.twig then simply copy it from Bootstrap into your sub-theme templates directory and customize. Drupal will automatically pickup the page.html.twig in your sub-theme instead of the one in Bootstrap.

You should never modify the Bootstrap theme. This way you can keep the Bootstrap theme up-to-date.

If you want to learn more about sub-themes in general. Check out the Creating a Drupal 8 sub-theme, or sub-theme of sub-theme documentation page.

Bootstrap Sub-themes

The way you create a sub-theme can vary. Some themes offer a Drush command to create a sub-theme while others offer starter kits which you just copy and change a few file names.

Bootstrap comes with three starter kits: CDN, Less and Sass. You can see them by going into the starterkits folder in the theme.

If you’re happy with Bootstrap being served over a CDN then choose the CDN kit. If you want to compile Bootstrap using Less or Sass (CSS pre-processors) then choose the corresponding starter kit.

There’s a lot of benefits in compiling Bootstrap CSS locally. You can customize it further and modify the variables which lets you change the colors, headings, fonts and more.

Step 1: Create Sub-theme

Let’s now create a sub-theme using the Sass starter kit. Why Sass? Well that’s my CSS pre-processor of choice. But the following steps can be applied to the other starter kits.

1. Go into the Bootstrap theme and copy the sass folder from starterkits and then paste the folder into /themes/custom.

2. Rename the folder from sass to bootstrap_sass (you can rename it to whatever you want). Once copied and renamed, the path to the sub-theme should be /themes/custom/bootstrap_sass.

Are you required to add sub-themes into a custom folder? No, it’s just best practice when it comes to managing sub-themes.

Your themes folder should look something like this:

3. In the bootstrap_sass sub-theme, replace all instances of THEMENAME in the file name to bootstrap_sass.

Look for the following files:

  • THEMENAME.libraries.yml   => bootstrap_sass.libraries.yml
  • THEMENAME.starterkit.yml => bootstrap_sass.info.yml (NOTE: make sure you change starterkit to info)
  • THEMENAME.theme            => bootstrap_sass.theme
  • /config/install/THEMENAME.settings.yml => bootstrap_sass.settings.yml
  • /config/schema/THEMENAME.schema.yml => bootstrap_sass.schema.yml

4. Now we need to open up a few files and perform a find and replace on the string THEMENAME.

Open the following files:

  • bootstrap_sass.info.yml: Give your sub-theme a name such as “Bootstrap Sass” and find all THEMENAME and replace them with bootstrap_sass.
  • /config/schema/bootstrap_sass.schema.yml: Find all instances of THEMENAME and replace with bootstrap_sass.

Step 2: Download Bootstrap

In the above section we just copied a folder and did a find and replace in the THEMENAME string. Now we need to download the actual Bootstrap library and compile the Sass.

1. Go to the Bootstrap Getting Started page and download the Sass version.

2. Extract the downloaded file into bootstrap_sass, once extracted the path should be bootstrap_sass/bootstrap. You may have to rename the folder after it’s extracted.

3. Now we need to copy over the variables in Bootstrap into our Sass files. This will allow us to override the variables without having to modify the actual Bootstrap library.

Go to bootstrap_sass/bootstrap/assets/stylesheets/bootstrap/_variables.scss and copy the variables into bootstrap_sass/scss/_default-variables.scss. Paste them just below the $icon-font-path variable.

Sass allows you to override variables. When we compile our Sass files, it’ll use the variables in _default-variables.scss instead of the default _variables.scss that ships with the library.

Step 3: Compile Sass using laravel-mix

The final piece to complete this sub-theme is to compile Sass. I won’t go into details on how to install and configure Sass, that’ll be a whole tutorial or two on it’s own. Instead, I’ll show you one of many ways to compile Sass. We’ll use laravel-mix which is a wrapper on top of webpack. Before you begin make sure you download and install Node.js.

Want to use Yarn instead? Look at this issue on GitHub.

1. Go into the sub-theme directory and create a package.json, you can do this by running the following command:

$ npm init

Just follow the prompts. Once complete you should see /themes/custom/bootstrap_sass/package.json.

2. Then install laravel-mix with the following command:

$ npm install laravel-mix

3. In the sub-theme create another file called webpack.mix.js and add the following to it:

let mix = require('laravel-mix');

mix.sass('scss/style.scss', 'css/');
mix.options({
  processCssUrls: false
});

The code above is pretty straightforward, it’ll tell laravel-mix to compile scss/styles.scss into the css directory. Once compiled there will be a single file styles.css and the path will be css/styles.css.

4. Open up package.json and replace the scripts section with the one below:

"scripts": {
  "dev": "NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js",
  "watch": "NODE_ENV=development node_modules/webpack/bin/webpack.js --watch --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js",
  "hot": "NODE_ENV=development webpack-dev-server --inline --hot --config=node_modules/laravel-mix/setup/webpack.config.js",
  "production": "NODE_ENV=production node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js"
},

This adds NPM scripts which you’ll need to use to compile the Sass. You’ll need to run these commands from within the sub-theme.

The two important scripts are:

$ npm run watch

Use this script to automatically compile when a file is changed. This should be used locally while developing a site.

$ npm run production

This script should be run when you’re ready to deploy to production. It’ll uglify the CSS and JavaScript file to reduce the size.

Summary

I hope now you have a better understanding on how to use Bootstrap in your next Drupal project. From a developer’s perspective, it’s great because you can focus on building the site without dealing with small design issues such styling a button. The Bootstrap theme has a good mix of configuration and flexibility. You can use the theme to quickly spin up a website, however, it’ll look very Bootstrappy. Or you can still use it if you want to fully customize the look-and-feel by compiling it yourself.

Other Bootstrap Modules for Drupal 8

There’s a whole bunch of modules which help you use Bootstrap in other parts of Drupal. There’s a page on drupal.org called Bootstrap related modules which lists them out. The two modules I always use with Bootstrap in Drupal 8 is Bootstrap Layouts and Bootstrap Paragraphs.

Bootstrap Layouts lets you configure a layout using its grid system in Panels and Display Suite. Bootstrap Paragraphs ships a bunch of pre-built paragraph types for Bootstrap.

We’ll cover both modules in more detail in future tutorials.

FAQs

Q: I created a sub-theme but I can’t see it on the Appearance page?

Make sure you change THEMENAME.starterkit.yml to bootstrap_sass.info.yml, replace starterkit with info.

Q: I enabled my sub-theme but the site looks broken.

This can happen when you enable a sub-theme before the parent. The simple workaround is to uninstall your sub-theme and then install the Bootstrap theme first, then install the sub-theme.

Q: None of the JavaScript files are getting loaded?

First, make sure you renamed THEMENAME.libraries.yml to bootstrap_sass.libraries.yml. Then in bootstrap_sass.info.yml make sure you update the libraries sections.

From this:

libraries:
 - 'THEMENAME/global-styling'
 - 'THEMENAME/bootstrap-scripts'

To this:

libraries:
 - 'bootstrap_sass/global-styling'
 - 'bootstrap_sass/bootstrap-scripts'
Ivan Zugec

About Ivan Zugec

Ivan is the founder of Web Wash and spends most of his time consulting and writing about Drupal. He's been working with Drupal for 10 years and has successfully completed several large Drupal projects in Australia.

Jan 22 2018
Jan 22

Hello and welcome to my first blog post for Mediacurrent! Today’s post will be all about Docksal and how it can help you get up and running developing on Drupal 8 quickly and easily. This post was inspired by the great session I saw at DrupalCon 2017 and will explain how using Docksal will save you time getting up and running for a new Drupal development project. I’ll also talk about some of the technologies behind Docksal such as Docker and Oracle VM VirtualBox.
 

How does it work?

Docksal works by using Docker (a software container platform) and VirtualBox ( a general-purpose full virtualizer for x86 hardware) to create projects with a few simple commands. Instead of having many VMs (virtual machines) for all of the projects or websites that you work on, Docker allows a person to use a single VM instance for many websites.
 

Why Docksal?

So, why Docksal? Why not just use Docker, download Drupal, and get started on development that way? If you’re already quite familiar with the Docker and VirtualBox installation process and you want to customize all of that yourself, you could do just that, but if you don’t the main advantage of Docksal is less set-up to get started on developing code with Drupal.
 

Installation

By following the instructions on Docksal’s documentation, you can see that when using one of its supported OSes, Docksal is installed in two to three steps.

The main step to pay attention to is usually the same for each OS: “fin vm start”. Fin is a handy command line tool that comes with installing Docksal. It allows you to manage all the services related to the docker machine and virtual machine with easy commands.
 

Saving Time with Docksal: How to customize your stack

To save you time on your projects, Docksal comes with a default set of configurations (or in their language, a “ stack ”) that controls what services your project will use. Within the default stack, you’ll find values for the typical services needed to run a website, such as configurations for PHP, a web server, and a database server. The current configuration being used for your project’s stack can be found by running “fin config show”.

It’s important to note that you should not change the configuration found in the yaml files for the default stack (under ~/.docksal/stacks). If you want to customize your stack, you should instead use the “.docksal” directory in your project. These are created after running “fin start” in your project directory. Customization will allow you to add support for more services, such as Apache Solr, Varnish, Memcache, Selenium, Behat, XDebug, and many more. Since Docksal uses Docker containers, almost any service that can be found on Docker can be made to work with it. A list of some typical services and how to configure them to work with your project can be found under the “Tools and Integrations” section on Docksal’s documentation page.

Docksal currently only comes with two stacks: default and Acquia. The Acquia stack is for quickly getting started on development for an Acquia environment.

I hope this post has served as a helpful guide to jumpstarting a Drupal 8 project with Docksal. For more information on Docksal stacks, please see the following documentation.

Additional Resources
Better Local Development with Vagrant | Blog
Debugging Javascript Live in Chrome | Blog
How to Think About Drupal 8 | Blog

Jan 19 2018
Jan 19

In this five part Acro Media Tech Talk video series, we use our Urban Hipster Commerce 2 demo site to show you how to set up a new product in Drupal Commerce 2, from start to finish. This is the first video in the series, How to set up Product Attributes.

If you're creating a whole new product type from scratch, the first thing you want to do is setup any product attributes that your product needs. For example, a shirt product type may have a number of sizes (small, medium, large) and colours available to choose from. Size and colour are both product attributes. As a site administrator, you'll use the attributes to configure your product variations. As a customer, your'll use the attributes to pick the exact product that you want to purchase.

View part 2: Product Attributes using Rendered 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.

Visit Our Drupal Commerce 2 Demo Site

More from Acro Media
Drupal modules used in this video

Contact us and learn more about our custom ecommerce solutions

Jan 18 2018
Jan 18
January 18th, 2018

What are Spectre and Meltdown?

Have you noticed your servers or desktops are running slower than usual? Spectre and Meltdown can affect most devices we use daily. Cloud servers, desktops, laptops, and mobile devices. For more details go to: https://meltdownattack.com/

How does this affect performance?

We finally have some answers to how this is going to affect us. After Pantheon patched their servers they released an article showing the 10-30% negative performance impact that servers are going to have. For the whole article visit: https://status.pantheon.io/incidents/x9dmhz368xfz

I can say that I personally have noticed my laptop’s CPU is running at much higher percentages than before the update for similar tasks.
Security patches are still being released for many operating systems, but traditional desktop OSs appear to have been covered now. If you haven’t already, make sure your OS is up to date. Don’t forget to update the OS on your phone.

Next Steps?

So what can we do in the Drupal world? First, you should follow up with your hosting provider and verify they have patched your servers. Then you need to find ways to counteract the performance loss. If you are interested in performance recommendations, Four Kitchens offers both frontend and backend performance audits.

As a quick win, if you haven’t already, upgrade to PHP7 which should give you a performance boost around 30-50% on PHP processes. Now that you are more informed about what Spectre and Meltdown are, help with the performance effort by volunteering or sponsoring a developer on January 27, 2018 and January 28, 2018 for the Drupal Global Sprint Weekend 2018, specifically on performance related issues: https://groups.drupal.org/node/517797

Web Chef Chris Martin
Chris Martin

Chris Martin is a support engineer at Four Kitchens. When not maintaining websites he can be found building drones, computers, robots, and occasionally traveling to China.

Web Chef Dev Experts
Development

Blog posts about backend engineering, frontend code work, programming tricks and tips, systems architecture, apps, APIs, microservices, and the technical side of Four Kitchens.

Read more Development
Jan 12 2018
Jan 12

Drupalcamp 2018

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

As a Drupal development agency contributing to the software for the past 15 years, we’re always looking to support the growth of the community. One major investment we make is sponsoring Drupalcamp London for the past 6 years. I’m a big supporter of the London event and if anything sums up the weekend, I believe this quote from Paul Johnson does the job.


I genuinely think Drupalcamp London is amongst the best Drupal event in the world. The breadth of topics covered is unparalleled and the high quality of speakers is a real draw.

Paul Johnson, Drupal Director at CTI Digital.

  

CXO Day

This year I’m set to be attending the CXO day on Friday 2nd March, a day that focuses on what Drupal means to its end users. It’s a rare opportunity to learn from the experiences of others and to hear how business leaders have been utilising Drupal and Open Source technology in the past year. The event is attended by a variety of end users new and familiar with Drupal, leaders from digital agencies, and wider Drupal business community. Opportunities for networking spaces with attendees will also be a valuable addition to the day, an area I will be frequenting.

At the CXO day our client, Dave O’Carroll, Head of Digital at War Child UK will be discussing what CTI's rebuild of the charity’s website has done for their end user experience and ability to increase their impact across the digital sphere.

Who’s attending?

Our Drupal Director and Evangelist, Paul Johnson and I will be attending. It will be an extremely busy day so if you would like to meet please do get in contact. We'll be glad to share our knowledge of Drupal and discuss our experiences working with London.gov and RCOT.

Drupal newbies and veterans will also be attending the weekend along with agencies and businesses invested in the world of Drupal. The organisers conducted an interesting survey of the attendees last year, as you can see below a majority attend to learn and share their knowledge of Drupal.

CXO Drupalcamp attendees

Drupalcamp study into reason for attending Drupalcamp 2017

 

The CXO always sells out quickly, visit their website now to find out more and register to attend. See you there.

Register Now 

 

Jan 11 2018
Jan 11

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

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

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

Urban Hipster Commerce 2 Demo site

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

Visit Our Drupal Commerce 2 Demo Site

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

Contact us and learn more about our custom ecommerce solutions

Jan 09 2018
Jan 09

Drupal Commerce 2 comes with an easy to use Promotions sub-module built right in to its core. No add-on modules are needed anymore. The sub-module lets you add a variety of promotions to your eCommerce website, such as discounts off of an entire order, discounts based on the amount spent, product and category specific discounts, and more. The options are extremely versatile, usage statistics are available and coupon codes can easily be added to any promotion that has been created.

In this Acro Media Tech Talk video, we user our Urban Hipster Commerce 2 demo site to quickly show you how to add a 20% storewide discount through the Promotion sub-module UI. 

Its important to note that this video was recorded before the official 2.0 release of Drupal Commerce. The current state of the Promotions sub-module is even more robust than what you see here, and many excellent improvements have been (and continue to be) made.

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.

Visit Our Drupal Commerce 2 Demo Site

More from Acro Media
Drupal modules in this demo

Contact us and learn more about our custom ecommerce solutions

Jan 08 2018
Jan 08
The 2017 DrupalCamp Atlanta was held in Buckhead neighborhood in Atlanta Go to the profile of Zach Sines

Jan 8, 2018

DrupalCamp Atlanta is upon us again as we continue to inch closer to the finishing touches to the camp. The Atlanta Drupal Users Group (ADUG) team has been fast at work on getting the camp together, the website updated, the leadership team together to discuss programming and logistics… You would think we have it automated at this point! Well, some of the items are, such as some trusted vendors and some of the process, but every year we try to do something different to provide a better and fulfilling experience for our camp go-ers.

This year is no exception, with us changing our venue (much to the appreciation of the community, we’re sure!) to the Buckhead area and reverting to our 2015-style of camp that we found to be the best format (Friday and Saturday tracks AND training). With the new venue comes its own challenges, such as the layout of the facility to the positioning of sponsors. All these things need to be planned out way in advance. We need to understand the return on investment with an event like this, being we are a non-profit and have very limited resources.

In talking about resources, we wanted to put together some new “in-kind” contributions this year that can help us put on an event like this. These contributions are focused around the tangible things we need to pay for every year: t-shirts, bags, badges, lanyards, A/V, event catering, the location, the after-party, the speaker coordination and expenses, websites, graphic design, and the countless man-hours it takes to get all of this set up, delivered, and managed. We also decided to open the door to the community to really see how much an event like this costs. Below are some of the expenses we have this year that must be met:

  • Catering: $13,394.70
  • Video Recording: $1,800.00
  • A/V Onsite: $4,055.00
  • Keynote Speaker Travel: $1,200.00

These charges don’t include all of the event merchandise, website fees, documentation, or additional costs for random event items like signage and photography.

Historically, there have been many people involved in this effort. Since ADUG has been managing the event, there have been 5 or less people actually planning and executing on all of this with the help of day-of volunteers. This year, we are fortunate enough to have 7 people who have dedicated time and energy out of their normal lives to put this event on. So, how do we do it? How do we make this happen this year…a bigger, more expensive event?

By being fortunate enough to have so many people come from all over to attend the event. It makes it all worth it. We have so many people from so many backgrounds, cultures, and professions come to Atlanta to learn. The congregation of all of these folks for two days, sharing knowledge and helping the community is worth it all in the end. With the attendance comes registrations, a contribution to the community to put on this event. With us moving from Kennesaw State, where we called home for the past 3 years, our costs have almost doubled. Our hope this year is that we will have a much better attendance while also attracting more sponsors, which would help out tremendously.

Speaking of sponsors…they have been amazing. We can’t thank them enough for the help they give us in throwing these events. Mediacurrent, Sevaa Group, Paramount Software, Celebrate Drupal. They have been amazing in getting us up and running again this year by donating early. We definitely need more this year, and hope that we can reach more with lower cost sponsorships so it’s not always the largest companies that can get their names out there. We want the community to be involved so that they can contribute to hosting this event, getting their names out there, and being able to increase their networks as well. So, these in-kind contributions help with this gap while also being able to directly affect the outcome of the camp.

Want your company name on the lanyards everyone is wearing? What about your logo on the side of our bags? How about donating some cool stuff for our raffle and get a shout out?

These are some easy ways to get involved, get some great advertising to the community you serve, and to get involved in making this an amazing event.

ADUG

Jan 08 2018
Jan 08
Mediacurrent’s Dave Terry and Paul Chason Go to the profile of Kaleem Clarkson

Dec 19, 2016

I’ve been Drupaling for about 8 years and this was my first camp. I really enjoyed the sessions and learning from others. -2016 Attendee

Now that most of us have completed our holiday shopping, we would like to provide the gift of Drupal to the Atlanta and the world — wide Drupal community!

This year’s DrupalCamp Atlanta centered around Drupal 8 and the importance of giving back to open source projects. After the inspiring keynote, “Creating a Culture of Giving for Your Organization” by Mediacurrent’s Dave Terry and Paul Chason, it is our hope that more organizations and individuals make an intentional effort to give back. If you are interested in helping shape the Atlanta Drupal community, feel free to contact us.

DrupalCamp Atlanta 2016 session videos are now live at www.drupalcampatlanta.com. Thanks to Utzu Logigan and his Recall Act team for creating the best session videos on the planet once again.

This year’s training schedule was provided two great sessions: The Absolute Beginner’s Guide to Drupal 8 sponsored by OSTraining and Drupal 8 Theming and Templating by Evolving Web. Without people dedicated to spreading their advanced knowledge, we wouldn’t be able to provide this to you! Thank you OSTraining and Evolving Web!

We also want to thank our sponsors for the time and financial support of this camp, as we can’t make events like this work without them. Special thanks to Mediacurrent and Sevaa group for their help with the Keynote, Afterparty, and general assistance in making DCA a great event! We also had SiteGround, Pantheon, 3Ci, Lingotek, and Acquia as sponsors who we also want to thank for coming from so far to be a part of our event!

Additionally, the Drupal Association made it out to our event, promoting the good word of Drupal. Please donate, as we all benefit from a strong nationwide community. You can join the Drupal Association here.

Last but not least we would like to thank all of the session speakers. Without the willingness to give back to the community, camps like this could not be possible. Their efforts can go unnoticed to so many, and we want to make sure that we acknowledge them here:

Kelly Albrecht, Ed Allison, Kirsten Burgard, Paul Chason, Suzanne Dergacheva, Jitesh Doshi, Dan Hansen, Zack Hawkins, Jimmy Kriigel, Ishan Mahajan, Tom McCracken, Paul McKibben, Todd Nienkerk, Lisa Ridley, Scott Sawyer, Scot Self, Mark Shropshire, Jim Smith, Dave Terry, David Thompson, Cheyenne Throckmorton, Jason Want, Bull Weber.

Happy Holidays from the Atlanta Drupal Users Group to all of the 2016 DrupalCamp Atlanta presenters and attendees.

Enjoy the videos at www.drupalcampatlanta.com

ADUG — Board of Directors
Eric Sembrat
Zach Sines
Taylor Wright
Kaleem Clarkson

Jan 02 2018
Jan 02

In the Urban Hipster Drupal Commerce 2 demo site, the catalog is made of up of a number of products grouped by taxonomy terms. These terms (Women, Men, Hats, Special, Clearance etc.) are grouped into Vocabularies (Category, Brand, Artist, Special, etc.), which can be referenced within a product in order to categorize it. A product can be assigned to multiple terms in multiple vocabularies, which allows us to create a variety of cataloging options.

We already have the catalog functionality configured using Apache Solr. So, in this Acro Media Tech Talk video, we quickly cover how to add new taxonomy terms and then add a product to the new term. It's easy!

Also, it's important to not that ANY content can be organized in this way, not just products. News, blogs, resources, videos, images, you name it! If it's content, it can be organized and filtered with taxonomy and Solr.

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.

Visit Our Drupal Commerce 2 Demo Site

More from Acro Media
Drupal modules in this demo

Contact us and learn more about our custom ecommerce solutions

Dec 26 2017
Dec 26

Apache Solr is a powerful search engine used by many of the largest websites on the planet. It's highly customizable, allowing you to configure content catalogs and search results by any content datasource (such as title, brand, colour, price, keyword, taxonomy, etc.). You can also assign priority levels to each datasource so that your users are more likely to find the content that they're looking for right away.

Our Urban Hipster Drupal Commerce 2 demo site uses Solr for product catalog functionality and as a product search. In this Acro Media Tech Talk video, we'll show you how you can make a new datasources searchable to your users. 

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.

Visit Our Drupal Commerce 2 Demo Site

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

Contact us and learn more about our custom ecommerce solutions

Dec 22 2017
Dec 22

Designers mapping out a website.

Designers mapping out a website.

So your site isn’t working the way you want it to. Maybe it’s sluggish, or you’re not seeing the conversions you want, or customers are complaining. Before you drop a huge chunk of your budget on a complete rebuild, consider that there might be a simpler (and more affordable) solution to your website woes.

We see a lot of Drupal 7 and WordPress websites here at Kanopi Studios, and we often discover that it’s more cost-effective for our clients to simply update their sites rather than rebuilding them. Making targeted updates can allow you to focus on addressing a few key issues, while still leveraging the investment of time, energy and funds that went into your site’s foundation.

In this series, we’ll look at three key topics to consider:

1. How do you know when it’s time for a change?
2. Is your website optimally organized and designed to be user-friendly?
3. How strong is your technical foundation?

How do I know it’s time for a change?

Do any of these problems sound familiar?

  • Low conversion rates
  • Site pages take more than 3 seconds to load
  • Site doesn’t work well on mobile or other devices
  • Updating content is a difficult and frustrating process
  • Users struggle to find what they need on the site or have shared negative feedback
  • Site crashes when updating
  • Too many bugs
  • Building new features is difficult or may not even be possible
  • Site is not loading on https and triggers security warnings

If your answer to any of these is yes, it’s time to take action.

But first … is it really that important for me to address these issues?

Yes! A website that isn’t working optimally can dramatically affect your bottom line. An out-of-date or poorly designed website can:

  • Damage your credibility. If your website loads slowly, is crowded with clutter or is just plain not working, you are sending the message that your company is unprofessional.
  • Make you appear out of touch. A dated website tells your customers you are behind the technological times, or worse – you don’t care enough to stay up-to-date.
  • Cost you customers. Every customer who leaves your site in frustration due to broken links, complex forms, slow pages or confusing navigation is a customer you won’t get back. If your competitors offer similar services and have a stronger website experience, your loss will be their gain.

Decision time. If you want to avoid the damage that a dated website can cause, you’ll need to either rebuild your site or update it. If you’re ready to take action, we can help you find the best and most cost-effective approach.

There are two primary things to consider when maximizing your site’s ROI: your user’s needs and the technology that drives your site. If you can identify and fix problems in both of these categories, you can most likely avoid a costly rebuild.

Venn diagram showing optimum website health at the intersection of smart user experience and strong tech foundation.

Venn diagram showing optimum website health at the intersection of smart user experience and strong tech foundation.


Next, we’ll dive a bit deeper into tips to help you level up your user experience and update your website technology without starting over from scratch. Consider it the non-surgical, diagnostic approach to improving your website experience right where it needs it the most. 
Dec 22 2017
Dec 22

Now that you’ve decided that it’s time to take action to improve your website, It’s time to see if any user experience upgrades could help. Take a look through our list of issues below, and the tips to help resolve them.

Having a hard time converting leads or getting sales?

If you’re not sure why you’re not generating business from your website, it’s time to get serious about strategy. Here’s how:

  • Add a survey to your website to understand what users are looking for
  • Take a look at your analytics to understand where you are losing your users. If you don’t have analytics installed, get either Google Analytics or Tag Manager set up on your site.
  • Try an online user testing platform like Hotjar to help you go beyond standard analytics with heatmaps, visitor recordings, conversion funnels and more.
    Complete a User Experience & Conversion Optimization Audit with Kanopi Studios. We can make a whole range of insightful recommendations within your budget. Contact us to learn more.

Does your site take forever to load?

If it takes longer than three seconds, you have a problem.

  • Use Google PageSpeed or Pingdom to test your site’s speed, understand what might be slowing it down and take action to resolve any issues.
  • Make sure you have a reliable hosting company backing your site at the right level for the amount of traffic you receive.

Does your site work on mobile? Is it accessible?

It’s vital to make sure your site is accessible to everyone, no matter what device or screen size they are using. Here’s how to check:

  • Try using your site on a phone or a tablet. If you have to pinch or zoom to interact with the content, it’s time for a responsive design.
  • Make sure you can tab through all navigation and content on your site using only your keyboard, that all images have alt tags, and that you are able to use a voice browser to “read” your pages out loud. If not, you are missing key elements of accessibility.
  • Contact Kanopi Studios about an accessibility audit. We can help you identify the issues and build a plan for how to resolve them.

Is it frustrating – or impossible – to update content on your site?

If it’s a major undertaking to change even the simplest thing, something needs to happen.

  • Define your ideal workflow, then ask an expert to take a look and see how you can optimize the backend.
  • Consider the types of content that your site needs to support. Do you have templates in place that meet your needs? If not, it may be time to consider a bit of design and development time to build additional page types on your site.

Getting negative user feedback?

If the people visiting your site are taking the time to complain, chances are they might also take the time to help you make things better. Here’s how:

  • Collect feedback by sending out a survey, or document your customer service calls.
  • Always thank people for taking the time to help you improve.
  • Look for trends in the information you are receiving from users and build a plan to address any issues to help meet their needs

If none of the issues above apply, congratulations! Your user experience is likely more solid than many of the websites out there! But there are still more things to consider before committing to rebuilding your site. In our next post, we will walk you through a number of common technical issues and some helpful fixes for them.

Dec 22 2017
Dec 22

Website developers considering code.

Website developers considering code.

Now that you’ve considered your user experience, there are a number of possible technical fixes that might help resolve your website problems.

What version of Drupal or WordPress are you using?

  • WordPress 2, while old, may or may not require a rebuild. You might be able to get by with updating and refactoring.
  • If you’re using Drupal 7 or WordPress 3, a rebuild is likely not needed. 
  • However, if you are on Drupal 6, it is at the end of its life, which may make rebuilding more cost-effective and viable for the long term.

Does your site use a lot of custom code?

If so, what does that code do, and are you still using that functionality? Look for ways to streamline where possible.

Is your site’s code a nightmare?

Did you use a professional firm with a North American team? An offshore team? A freelance developer? Or an internal employee who no longer works at your company? It’s a good idea to get the code reviewed so that you can determine its quality and understand whether it will be easy to update or if you’d be better off starting from scratch. Contact Kanopi for a low-cost assessment.

Are you up to date with the latest security patches and updates?

Lapses can expose the site to hacks and backdoors. Often just updating your site and modules/plugins can solve many issues.

Want to learn more about how we can help you understand every aspect of your site and determine if you need to rebuild or update to help achieve your goals? Contact us to book a free 15-minute consultation. Click here to book a time.

Dec 20 2017
Dec 20

We are always striving for optimal Drupal contrib modules use. Yet, in some cases they won’t meet the required standards, desires, stability and/ or security. That’s when we develop tailor made codes; sometimes with the help of other modules’ snippets.

When we have to do tailor made development, we’ll always strive to make it generic, making it possible to produce a contrib module, which can be released on Drupal.org. We’ll always do this in consultation with the client.

Such an example is the just released module ‘Conditional Redirect’: some modules were close, but just didn’t meet the requirements.

Shield Drupal with a login

It’s about the following functionality: imagine you are producing a system in Drupal meant for internal use, like a kind of intranet or management app.

This system has to be globally available, but only accessible after people logged in. In that case you would want people who are not yet logged in linked to the login page.

As extra wish: certain pages do have to be publicly accessible and should be configured as exception.

Above is realized in the released module: after installation all logged out (anonymous) visitors will be redirected to the login page. Exceptions can be configured as well:

  • Content types;
  • Specific pages;
  • Specific menu links

Download the module here

Wrap up

Alright, that’s it for now. Questions or comments regarding this module? Let us know in the comments, or shoot an issue on the Drupal.org project page.

Joris Snoek | Founder @ Lucius Digital | #Amsterdam
Dec 20 2017
Dec 20
December 20th, 2017

One of the most common requests we get in regards to Emulsify is to show concrete examples of components. There is a lot of conceptual material out there on the benefits of component-driven development in Drupal 8—storing markup, CSS, and JavaScript together using some organizational pattern (à la Atomic Design), automating the creation of style guides (e.g., using Pattern Lab) and using Twig’s include, extends and embed functions to work those patterns into Drupal seamlessly. If you’re reading this article you’re likely already sold on the concept. It’s time for a concrete example!

In this tutorial, we’ll build a full site header containing a logo, a search form, and a menu – here’s the code if you’d like to follow along. We will use Emulsify, so pieces of this may be specific to Emulsify and we will try and note those where necessary. Otherwise, this example could, in theory, be extended to any Drupal 8 project using component-driven development.

Planning Your Component

The first step in component-driven development is planning. In fact, this may be the definitive phase in component-driven development. In order to build reusable systems, you have to break down the design into logical, reusable building blocks. In our case, we have 3 distinct components—what we would call in Atomic Design “molecules”—a logo, a search form, and a menu. In most component-driven development systems you would have a more granular level as well (“atoms” in Atomic Design). Emulsify ships with pre-built and highly flexible atoms for links, images, forms, and lists (and much more). This allows us to jump directly into project-specific molecules.

So, what is our plan? We are going to first create a molecule for each component, making use of the atoms listed above wherever possible. Then, we will build an organism for the larger site header component. On the Drupal side, we will map our logo component to the Site Branding block, the search form to the default Drupal search form block, the menu to the Main Navigation block and the site header to the header region template. Now that we have a plan, let’s get started on our first component—the logo.

The Logo Molecule

Emulsify automatically provides us with everything we need to print a logo – see components/_patterns/01-atoms/04-images/00-image/image.twig. Although it is an image atom, it has an optional img_url variable that will wrap the image in a link if present. So, in this case, we don’t even have to create the logo component. We merely need a variant of the image component, which is easy to do in Pattern Lab by duplicating components/_patterns/01-atoms/04-images/00-image/image.yml and renaming it as components/_patterns/01-atoms/04-images/00-image/image~logo.yml (see Pattern Lab documentation).

Next, we change the variables in the image~logo.yml as needed and add a new image_link_base_class variable, naming it whatever we like for styling purposes. For those who are working in a new installation of Emulsify alongside this tutorial, you will notice this file already exists! Emulsify ships with a ready-made logo component. This means we can immediately jump into mapping our new logo component in Drupal.

Connecting the Logo Component to Drupal

Although you could just write static markup for the logo, let’s use the branding block in Drupal (the block that supplies the theme logo or one uploaded via the Appearance Settings page). These instructions assume you have a local Drupal development environment complete with Twig debugging enabled. Add the Site Branding block to your header region in the Drupal administrative UI to see your branding block on your page. Inspect the element to find the template file in play.

In our case there are two templates—the outer site branding block file and the inner image file. It is best to use the file that contains the most relevant information for your component. Seeing as we need variables like image alt and image src to map to our component, the most relevant file would be the image file itself. Since Emulsify uses Stable as a base theme, let’s check there first for a template file to use. Stable uses core/themes/stable/templates/field/image.html.twig to print images, so we copy that file down to its matching directory in Emulsify creating templates/fields/image.html.twig (this is the template for all image fields, so you may have to be more specific with this filename). Any time you add a new template file, clear the cache registry to make sure that Drupal recognizes the new file. Now the goal in component-driven development is to have markup in components that simply maps to Drupal templates, so let’s replace the default contents of the image.html.twig file above ( <img{{ attributes }}> ) with the following:

{% include "@atoms/04-images/00-image/image.twig" with { img_url: "/", img_src: attributes.src, img_alt: attributes.alt, image_blockname: "logo", image_link_base_class: "logo", } %} {%include"@atoms/04-images/00-image/image.twig"with{  img_url:"/",  img_src:attributes.src,  img_alt:attributes.alt,  image_blockname:"logo",  image_link_base_class:"logo",

We’re using the Twig include statement to use our markup from our original component and pass a mixture of static (url, BEM classes) and dynamic (img alt and src) content to the component. To figure out what Drupal variables to use for dynamic content, see first the “Available variables” section at the top of the Drupal Twig file you’re using and then use the Devel module and the kint function to debug the variables themselves. Also, if you’re new to seeing the BEM class variables (Emulsify-specific), see our recent post on why/how we use these variables (and the BEM function) to pass in BEM classes to Pattern Lab and the Drupal Attributes object. Basically, this include statement above will print out:

<a class="logo" href="https://www.fourkitchens.com/"> <img class="logo__img" src=”/themes/emulsify/logo.svg" alt="Home"> </a> <aclass="logo"href="/">    <imgclass="logo__img"src=/themes/emulsify/logo.svg" alt="Home">

We should now see our branding block using our custom component markup! Let’s move on to the next molecule—the search form.

The Search Form Molecule

Component-driven development, particularly the division of components into controlled, separate atomic units, is not always perfect. But the beauty of Pattern Lab (and Emulsify) is that there is a lot of flexibility in how you markup a component. If the ideal approach of using a Twig function to include other smaller elements isn’t possible (or is too time consuming), simply write custom HTML for the component as needed for the situation! One area where we lean into this flexibility is in dealing with Drupal’s form markup. Let’s take a look at how you could handle the search block. First, let’s create a form molecule in Pattern Lab.

Form Wrapper

Create a directory in components/_patterns/02-molecules entitled “search-form” with a search-form.twig file with the following contents (markup tweaked from core/themes/stable/templates/form/form.html.twig):

<form {{ bem('search')}}> {% if children %} {{ children }} {% else %} <div class="search__item"> <input title="Enter the terms you wish to search for." size="15" maxlength="128" class="form-search"> </div> <div class="form-actions"> <input type="submit" value="Search" class="form-item__textfield button js-form-submit form-submit"> </div> {% endif %} </form> <form{{bem('search')}}>  {%ifchildren%}    {{children}}  {%else%}    <divclass="search__item">      <inputtitle="Enter the terms you wish to search for."size="15"maxlength="128"class="form-search">    </div>    <divclass="form-actions">      <inputtype="submit"value="Search"class="form-item__textfield button js-form-submit form-submit">    </div>  {%endif%}

In this file (code here) we’re doing a check for the Drupal-specific variable “children” in order to pass one thing to Drupal and another to Pattern Lab. We want to make the markup as similar as possible between the two, so I’ve copied the relevant parts of the markup by inspecting the default Drupal search form in the browser. As you can see there are two classes we need on the Drupal side. The first is on the outer <form>  wrapper, so we will need a matching Drupal template to inherit that. Many templates in Drupal will have suggestions by default, but the form template is a great example of one that doesn’t. However, adding a new template suggestion is a minor task, so let’s add the following code to emulsify.theme:

/** * Implements hook_theme_suggestions_HOOK_alter() for form templates. */ function emulsify_theme_suggestions_form_alter(array &$suggestions, array $variables) { if ($variables['element']['#form_id'] == 'search_block_form') { $suggestions[] = 'form__search_block_form'; } } * Implements hook_theme_suggestions_HOOK_alter() for form templates.functionemulsify_theme_suggestions_form_alter(array&$suggestions,array$variables){  if($variables['element']['#form_id']=='search_block_form'){    $suggestions[]='form__search_block_form';

After clearing the cache registry, you should see the new suggestion, so we can now add the file templates/form/form--search-block-form.html.twig. In that file, let’s write:
{% include "@molecules/search-form/search-form.twig" %} {%include"@molecules/search-form/search-form.twig"%}

The Form Element

We have only the “search__item” class left, for which we follow a similar process. Let’s create the file components/_patterns/02-molecules/search-form/_search-form-element.twig, copying the contents from core/themes/stable/templates/form/form-element.html.twig and making small tweaks like so:

{% set classes = [ 'js-form-item', 'search__item', 'js-form-type-' ~ type|clean_class, 'search__item--' ~ name|clean_class, 'js-form-item-' ~ name|clean_class, title_display not in ['after', 'before'] ? 'form-no-label', disabled == 'disabled' ? 'form-disabled', errors ? 'form-item--error', ] %} {% set description_classes = [ 'description', description_display == 'invisible' ? 'visually-hidden', ] %} <div {{ attributes.addClass(classes) }}> {% if label_display in ['before', 'invisible'] %} {{ label }} {% endif %} {% if prefix is not empty %} <span class="field-prefix">{{ prefix }}</span> {% endif %} {% if description_display == 'before' and description.content %} <div{{ description.attributes }}> {{ description.content }} </div> {% endif %} {{ children }} {% if suffix is not empty %} <span class="field-suffix">{{ suffix }}</span> {% endif %} {% if label_display == 'after' %} {{ label }} {% endif %} {% if errors %} <div class="form-item--error-message"> {{ errors }} </div> {% endif %} {% if description_display in ['after', 'invisible'] and description.content %} <div{{ description.attributes.addClass(description_classes) }}> {{ description.content }} </div> {% endif %} </div>   setclasses=[    'js-form-item',    'search__item',    'js-form-type-'~type|clean_class,    'search__item--'~name|clean_class,    'js-form-item-'~name|clean_class,    title_displaynotin['after','before']?'form-no-label',    disabled=='disabled'?'form-disabled',    errors?'form-item--error',  setdescription_classes=[    'description',    description_display=='invisible'?'visually-hidden',<div{{attributes.addClass(classes)}}>  {%iflabel_displayin['before','invisible']%}    {{label}}  {%endif%}  {%ifprefixisnotempty%}    <spanclass="field-prefix">{{prefix}}</span>  {%endif%}  {%ifdescription_display=='before'anddescription.content%}    <div{{description.attributes}}>      {{description.content}}    </div>  {%endif%}  {{children}}  {%ifsuffixisnotempty%}    <spanclass="field-suffix">{{suffix}}</span>  {%endif%}  {%iflabel_display=='after'%}    {{label}}  {%endif%}  {%iferrors%}    <divclass="form-item--error-message">      {{errors}}    </div>  {%endif%}  {%ifdescription_displayin['after','invisible']anddescription.content%}    <div{{description.attributes.addClass(description_classes)}}>      {{description.content}}    </div>  {%endif%}

This file will not be needed in Pattern Lab, which is why we’ve used the underscore at the beginning of the name. This tells Pattern Lab to not display the file in the style guide. Now we need this markup in Drupal, so let’s add a new template suggestion in emulsify.theme like so:

/** * Implements hook_theme_suggestions_HOOK_alter() for form element templates. */ function emulsify_theme_suggestions_form_element_alter(array &$suggestions, array $variables) { if ($variables['element']['#type'] == 'search') { $suggestions[] = 'form_element__search_block_form'; } }   * Implements hook_theme_suggestions_HOOK_alter() for form element templates.functionemulsify_theme_suggestions_form_element_alter(array&$suggestions,array$variables){    if($variables['element']['#type']=='search'){      $suggestions[]='form_element__search_block_form';

And now let’s add the file templates/form/form-element--search-block-form.html.twig with the following code:

{% include "@molecules/search-form/_search-form-element.twig" %} {%include"@molecules/search-form/_search-form-element.twig"%}

We now have the basic pieces for styling our search form in Pattern Lab and Drupal. This was not the fastest element to theme in a component-driven way, but it is a good example of complex concepts that will help when necessary. We hope to make creating form components a little easier in future releases of Emulsify, similar to what we’ve done in v2 with menus. And speaking of menus…

The Main Menu

In Emulsify 2, we have made it a bit easier to work with another complex piece of Twig in Drupal 8, which is the menu system. The files that do the heavy-lifting here are components/_patterns/02-molecules/menus/_menu.twig  and components/_patterns/02-molecules/menus/_menu-item.twig  (included in the first file). We also already have an example of a main menu component in the directory

themes/emulsify/components/_patterns/02-molecules/menus/main-menu themes/emulsify/components/_patterns/02-molecules/menus/main-menu

which is already connected in the Drupal template

templates/navigation/menu--main.html.twig templates/navigation/menu--main.html.twig

Obviously, you can use this as-is or tweak the code to fit your situation, but let’s break down the key pieces which could help you define your own menu.

Menu Markup

Ignoring the code for the menu toggle inside the file, the key piece from themes/emulsify/components/_patterns/02-molecules/menus/main-menu/main-menu.twig is the include statement:

<nav id="main-nav" class="main-nav"> {% include "@molecules/menus/_menu.twig" with { menu_class: 'main-menu' } %} </nav> <navid="main-nav"class="main-nav">  {%include"@molecules/menus/_menu.twig"with{    menu_class:'main-menu'

This will use all the code from the original heavy-lifting files while passing in the class we need for styling. For an example of how to stub out component data for Pattern Lab, see components/_patterns/02-molecules/menus/main-menu/main-menu.yml. This component also shows you how you can have your styling and javascript live alongside your component markup in the same directory. Finally, you can see a more simple example of using a menu like this in the components/_patterns/02-molecules/menus/inline-menu component. For now, let’s move on to placing our components into a header organism.

The Header Organism

Now that we have our three molecule components built, let’s create a wrapper component for our site header. Emulsify ships with an empty component for this at components/_patterns/03-organisms/site/site-header. In our usage we want to change the markup in components/_patterns/03-organisms/site/site-header/site-header.twig to:

<header class="header"> <div class="header__logo"> {% block logo %} {% include "@atoms/04-images/00-image/image.twig" %} {% endblock %} </div> <div class="header__search"> {% block search %} {% include "@molecules/search-form/search-form.twig" %} {% endblock %} </div> <div class="header__menu"> {% block menu %} {% include "@molecules/menus/main-menu/main-menu.twig" %} {% endblock %} </div> </header> <headerclass="header">  <divclass="header__logo">    {%blocklogo%}      {%include"@atoms/04-images/00-image/image.twig"%}    {%endblock%}  </div>  <divclass="header__search">    {%blocksearch%}      {%include"@molecules/search-form/search-form.twig"%}    {%endblock%}  </div>  <divclass="header__menu">    {%blockmenu%}      {%include"@molecules/menus/main-menu/main-menu.twig"%}    {%endblock%}  </div>

Notice the use of Twig blocks. These will help us provide default data for Pattern Lab while giving us the flexibility to replace those with our component templates on the Drupal side. To populate the default data for Pattern Lab, simply create components/_patterns/03-organisms/site/site-header/site-header.yml and copy over the data from components/_patterns/01-atoms/04-images/00-image/image~logo.yml and components/_patterns/02-molecules/menus/main-menu/main-menu.yml. You should now see your component printed in Pattern Lab.

Header in Drupal

To print the header organism in Drupal, let’s work with the templates/layout/region--header.html.twig file, replacing the default contents with:

{% extends "@organisms/site/site-header/site-header.twig" %} {% block logo %} {{ elements.emulsify_branding }} {% endblock %} {% block search %} {{ elements.emulsify_search }} {% endblock %} {% block menu %} {{ elements.emulsify_main_menu }} {% endblock %} {%extends"@organisms/site/site-header/site-header.twig"%}{%blocklogo%}  {{elements.emulsify_branding }}{%endblock%}{%blocksearch%}  {{elements.emulsify_search }}{%endblock%}{%blockmenu%}  {{elements.emulsify_main_menu }}{%endblock%}

Here, we’re using the Twig extends statement to be able to use the Twig blocks we created in the component. You can also use the more robust embed statement when you need to pass variables like so:

{% embed "@organisms/site/site-header/site-header.twig" with { variable: "something", } %} {% block logo %} {{ elements.emulsify_branding }} {% endblock %} {% block search %} {{ elements.emulsify_search }} {% endblock %} {% block menu %} {{ elements.emulsify_main_menu }} {% endblock %} {% endembed %} {%embed"@organisms/site/site-header/site-header.twig"with{  variable:"something",  {%blocklogo%}    {{elements.emulsify_branding }}  {%endblock%}  {%blocksearch%}    {{elements.emulsify_search }}  {%endblock%}  {%blockmenu%}    {{elements.emulsify_main_menu }}  {%endblock%}{%endembed%}

For our purposes, we can simply use the extends statement. You’ll notice that we are using the elements variable. This variable is currently not listed in the Stable region template at the top, but is extremely useful in printing the blocks that are currently in that region. Finally, if you’ve added the file, be sure and clear the cache registry—otherwise, you should now see your full header in Drupal.

Final Thoughts

Component-driven development is not without trials, but I hope we have touched on some of the more difficult ones in this article to speed you on your journey. If you would like to view the branch of Emulsify where we built this site header component, you can see that here. Feel free to sift through and reverse-engineer the code to figure out how to build your own component-driven Drupal project!

This fifth episode concludes our five-part video-blog series for Emulsify 2.x. Thanks for following our Emulsify 2.x tutorials. Miss a post? Read the full series here.

Pt 1: Installing Emulsify | Pt 2: Creating your Emulsify 2.0 Starter Kit with Drush | Pt 3: BEM Twig Function | Pt 4: DRY Twig Approach

Just need the videos? Watch them all on our channel.

Download Emulsify

Web Chef Evan Willhite
Evan Willhite

Evan Willhite is a frontend engineer at Four Kitchens who thrives on creating delightful digital experiences for users, clients, and fellow engineers. He enjoys running, hot chicken, playing music, and being a homebody with his family.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web