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

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 work "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

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

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.

Dec 19 2017
Dec 19

 

The term "omnichannel" has been around for a long time, but in a lot of cases it was just a buzzword.

We talk sometimes about omnichannel being online and in store, but in reality, it refers to all the channels that are available to your customers. That's call-in orders, customer service, catalog orders, integrations with other fulfillment partners like Amazon or eBay—those are all channels through which you sell products.

Omnichannel is about having all those channels work together. So if Joe buys something online, for instance, he should be able to return it to the physical store, and the customer service rep in the store should be able to see his updated account history, because everything should sync up.

In the early days, basic omnichannel really just meant that if the product showed on the website, it was also in the store. But these days, omnichannel is also about customizing the experience for each channel.

So if Joe is on the app, it should automatically pick his closest store. It should show him what aisle or section the item is located in and whether its in stock. On the other hand, if Joe is buying online, he doesn't care what aisle it's in, he just wants to know how long it will take to get the item shipped to him. So you have to tailor the experience to each type of channel, but the systems all need to mesh together.

What can you expect from the omnichannel experience from most platforms?

You will generally get rudimentary stock syncing. That means that whether you sell items online or in store, you will know how many you have and when you're out of stock. But even that has variations. Do you know your inventory status in real time? Every hour? Or does it only sync nightly? That can make a big difference.

With most platforms, you're not going to get features like the ability to inform the customer where the item is located in the store. Only a few retailers do that because it's very difficult and requires a lot of extra work. You need to know that data, for one thing. So even if the platform supports that, that doesn't mean that you actually track the precise location of every single product in your store.

What's different with Drupal?

With Drupal, syncing is simple because we can use the same platform for everything: we have a point of sale, we have a web platform, and we can automatically do pushes to different channels like Amazon and eBay. We have real-time stock and shipping.

Then we can add more customizations. We can allow for your customers to start an order online and finish it in store, for instance. Or if they go into the store and find it's not in stock, the clerk can put in an order—but instead of it getting shipped to the store and the customer having to come and pick it up, the clerk can simply turn it into an online order and have the item shipped to the customer. This is the kind of stuff we can mostly do out of the box, but there's usually a bit of customization work to make it a smooth flow.

What's the deal with add-ons?

Drupal is well set up for omnichannel, but keep in mind that there can be problems any time you integrate with other systems. Payment gateways are usually not a problem, but you can run into issues if you have to pass data to some warehouse fulfillment system and it can't provide real-time stock info back. So Drupal can keep track of stock, but if they knock over a pallet in the warehouse, or they get a new shipment but take a while to put it in, that can be slow to update. So the caveat here is that you can be let down by other parts of your system.

Chat with us

If you'd like to how Drupal Commerce fits into your omnichannel solution, give us a shout. We're here to help.

Contact Us

Dec 13 2017
Jay
Dec 13

In this day and age, it is rare to find a truly "standalone" website. The web as a whole was fundamentally built upon a concept of having different sites connecting together. At first, this was just done with hyperlinks from one page to another, but those simple days are long gone. Almost every website in this day and age has some integration with other websites or web services, and fortunately, Drupal is the perfect tool for creating a well-integrated website.

Analytics

Analytics are among the most basic integrations. Tools such as New Relic and Google Analytics can be leveraged on almost every website, and they are invaluable tools for website owners to learn how people are actually using the site and, therefore, how the site can be improved.

Using an analytics tool is often as simple as adding a tiny bit of code to each page on each site, and doing that is as simple with a Drupal site as it is with any other site. Where Drupal shines in this regard is in how easy it makes more complicated use of some such tools. For instance, the Google Analytics module not only makes it easy to add Google Analytics to the site, it also provides an immense number of configuration options so that you can tailor your use of Google Analytics specifically for your site. And where there isn't a module, there are other options: Web hosting company Pantheon provides free access to New Relic Pro for every Drupal site built on their platform, and using it is only a few clicks away.

Brainstorm your next development project with an Ashday Drupal expert! Request your free session today. 

Searching with Solr

For how common it is, searching can be a surprisingly difficult feature to implement. Many sites have a built-in "site search" feature to help with browsing the site, but building such a thing - especially with the quality of search results that people have come to expect from search engines such as Google - isn't an easy thing to do.

By default, Drupal includes a Search module which can be used for simpler sites, but a more robust solution is often needed for more complex sites. There are many options available, but at Ashday, we tend to use Solr when we need to add search functionality to a website. With a Solr integration, the site stores information that somebody might want to search for on a Solr server, and then when somebody searches the site, it lets Solr do the searching. Since Solr is well-optimized for searching large amounts of content quickly, this can give both faster and more relevant results than an entirely custom search. There are some pre-packaged Drupal solutions for searching with Solr, such as the Search API Solr Search module, but if that doesn't quite suit a site's needs, then a custom Solr integration can be built using Solarium instead. One great advantage Drupal 8 has over Drupal 7 is the ease with which it is possible to make use of code "libraries" such as Solarium.

Data Management

Everyone has different data management needs. Sometimes, Drupal's standard content and user management is all that is needed, and this works quite well for many standalone sites.

However, many websites aren't standalone. They share their data with other things - perhaps, the site is tied together with a custom mobile app, or it is part of a whole suite of related websites. In either case, there are two main options: Either Drupal is at the center of the system, managing the data itself, or it connects to some other site that's fulfilling that role.

Using Drupal at the core of interconnected systems such as this has not always been easy, but Drupal 8 has made it much simpler. Out-of-the-box, Drupal 8 contains a number of features and modules designed to make this use a breeze. This also enables the use of "headless Drupal", where Drupal is used for data management only, with other software connecting to it even on the main website.

Also common, is Drupal being used to display and manipulate data stored elsewhere, and for this there often isn't an out-of-the-box solution, due to the sheer number of different possible things that Drupal might be integrated with. No two integrations are quite alike. Where Drupal shines, here, is in the tools it provides developers with. A mixture of Drupal, custom code, and integration-specific libraries can be leveraged quite effectively by a skilled developer to meet whatever needs a site may have.

eSignatures with HelloSign

While things like analytics, searching, and data management are all common tasks that are used by many sites, sometimes an integration is more specialized. One example of this is integrating with HelloSign or other eSignature services. This sort of integration is rare enough that no ready-to-use Drupal solution typically exists, but it is also important enough to the sites that use it that the integration has to be done right. 

Back when we were using Drupal 7, we created a Drupal module for this particular integration, which can now be used by other Drupal 7 sites which need to receive digital signatures from users. Now that Drupal 8 is out, we're looking forward to working on another project that needs a HelloSign integration so that we can update the module and take advantage of Drupal 8's new features.

Customer Engagement

In our experience, most customer engagement tools work great with Drupal! Often, a company's Drupal website is the main way people interact with the company online. As such, it is the perfect place to do collect potential leads and to keep in touch with people. For companies with separate CRM systems, Drupal provides all of the tools necessary to send data on from Drupal to that system. If somebody update their Drupal user account, or fills out a form, the relevant information can also be sent to wherever it needs to go.

What's more, Drupal can be leveraged to help keep in touch with customers directly. While Drupal itself can send emails, this often isn't the ideal setup. Instead, Drupal can be used to create the emails, using the content and customer data that it has, and then it can send that email off to a separate service to send it. That service - perhaps the mailing features available from Knowledge Marketing - can then actually send that email out and manage things like email lists and subscriptions. Although Drupal could be used for such things, using Drupal alongside a specialized tool designed specifically for email management can create a much more flexible system at a fraction of the cost.

Conclusion

Although Drupal isn't perfectly able to do everything on its own (what system can?), the ease with which it can be integrated with other tools more than makes up for it. At Ashday, we've created countless Drupal integrations - some of them used by many of our sites, some by just a single site - and they are some of our favorite projects to work on.

Offer for a free consultation with an Ashday expert

Dec 06 2017
Jay
Dec 06

Illustrations showing a person signing a document from their tablet

As more and more companies make the leap to having entirely-digital communications with their customers or clients, some things have a tendency to stay on paper.  One common thing which lags behind the rest of the digitization process is the signing of legally binding documents... but no more. Now, services such as HelloSign are able to fill this void, and thanks to the HelloSign API, Drupal websites can fully leverage that service to make this important task easier both for you and for your customers.

Why HelloSign?

One common question about eSignature services is simple: Why use one at all?

Using eSignatures can be a great time- and paper-saver compared to conventional document signing. With eSignatures, you can still print a hardcopy if you want, but it's not strictly necessary to do so... no more needing to keep a painstakingly organized file cabinet! It's also just what people have come to expect. If somebody is signing up for access to a web application, for instance, needing to print and send in a document feels archaic by comparison. For these reasons and more, the benefits of eSignatures seems clear.

But, why use a service for it? Can't you just add a checkbox to the registration page of your website that says "I agree"? Well, perhaps, but depending on your use-case that isn't always a suitable solution. Imagine, for instance, that the thing being signed is an apartment rental agreement. When somebody fills out a document like that, you want a signed PDF at the end... something for your own records, and something that the renter can refer to later to review the terms, so an eSigned document if much better than simply recording that somebody clicked a button.

Furthermore, you also need the signature to be legally binding. Unless you want to navigate all of the laws to figure out how to make an eSignature be just as binding as a physical signature, using a service that has already figured out all of those details is a fantastic solution.

At Ashday, we like HelloSign because, in addition to meeting all of these needs and having many other useful features, we can use the robust HelloSign API to integrate the eSignature process directly into websites that need it.

Interested in a smooth, hassle-free HelloSign Integration?  Request your free consultation with an Ashday Drupal expert today. 

Drupal 7 Integration: Overview

Our first HelloSign integration was with a Drupal 7 site, and with that, we created and released the initial version of our HelloSign module for Drupal. This module can be used by any Drupal 7 website to facilitate the integration of HelloSign with that site.

Since this is an integration, somebody using the module still needs to have a HelloSign account that includes access to the HelloSign API and, for the best user experience, its embedded signing feature. What this module does is help get your Drupal 7 site connected to your HelloSign account and provide some useful tools for creating and managing eSignature requests.

The way the module works is simple. Once it is enabled on your site, there will be a page available on your site to enter your HelloSign API credentials. This page also has a useful "Test Mode" option to toggle whether eSignatures on the site should be "real" or just tests, which is very useful for when you are making changes to your eSignature functionality and want to be sure that it all works before people start signing any legally binding documents.

Once the HelloSIgn connection has been established, you're ready to actually use the module. Some Drupal modules create a full-fledged user interface for interacting with them, but since eSignatures can be used for so many different things, we didn't want to make any wrong assumptions about what people would want to do with the module. As such, what this module provides is a set of useful PHP functions that greatly simplify the creation of a HelloSign integration, rather than building a whole UI that might not work for all sites.

Drupal 7 Integration: The Details

If you hire a company like Ashday to build your website, of if you have software engineers at your company, they'll be the ones using the module to create an integration with the HelloSign API. In this case, you can probably skip this section. If, on the other hand, you're writing the code yourself, then this section is for you! The module's README has more details, but this should give a good overview of the overall process for using the module to integrate with the HelloSign API.

The heart of the module is the PHP function hellosign_generate_esignature_request(). All this function needs is the location of the PDF file to be signed, the names and email addresses of everyone who should sign it, a title for the document being signed, and a subject line for any emails sent regarding the eSignature. You can also create the eSignature in either "email" or "embedded" mode; we'll use "embedded" mode, since that usually makes for a better user experience. With this information, the function connects to the HelloSign API and starts the eSignature process. Assuming that all goes well, the function returns the ID of the signature request as well as information about the individual signatures needed. The request ID can then later be used by other functions to do other things related to the eSignature, such as cancelling the request, and the signature information can be used to move on to the next step: Building a page where the user can actually sign the document.

Perhaps surprisingly, this is one of the easiest parts of the integration.  The module includes a function called hellosign_get_embed_url(); give it the ID of a particular signature that you want, and it will return the URL for an iframe which you can include on whatever page you want users to go to to sign their documents.

Now, this is a Drupal 7 module, and what would a Drupal 7 module be without hooks? This module provides a single, vital hook: hook_process_hellosign_callback().  Any implementations of this hook that you create will get called whenever HelloSign notifies the site about a signature request being updated. This way, your site can know when a document gets signed or completed, and can do anything that it needs to. Need to save a copy of the signed document to your own server? The module has that covered as well. Just use hellosign_fetch_esignature_document() to get exactly the file you need, and then save it wherever you want in the file system.

Finally, if you need other, more advanced features of the HelloSign API, the module ultimately uses the HelloSign PHP SDK, so you can leverage anything you need from that even if the Drupal module doesn't specifically include functions for it. In theory, you could even create a HelloSign integration using just the SDK, but the Drupal module handles many common eSignature needs without ever needing to delve into a much more complicated utility like the SDK.

What's Next: Drupal 8

Of course, at this point, Drupal 7 is old news, and Drupal 8 is what all the cool kids are talking about. Well, don't worry: We're currently working on a new version of our HelloSign module for use on Drupal 8 sites. We've been using Drupal 8 for more than two years now (since before it's first official release!) and at this point we're pretty comfortable with the Drupal 8 way of doing things, so it's high time we brought the HelloSign module up to date. Since Drupal 8 is a much more robust and object-oriented system than Drupal 7, we're fully leveraging that to improve the structure of the module. This makes it both more flexibile to use and easier to add new features to as new needs crop up. Expect another blog post once the module is ready for use, and you can see all the improvements for yourself.

We're looking forward to building HelloSign integrations in Drupal 8 sites ... stay tuned.  

Free offer, talk to a seasoned Drupal expert.

Dec 06 2017
Dec 06

 

When you look at a product online, you might think you're looking at a single product (say a T-shirt). But as far as an ecommerce site is concerned, you're really looking at a grouping of products, because that T-shirt comes in four different colors and three different sizes (4 x 3 = 12 products with individual SKUs). And that is just a basic product example. More options mean even more SKUs.

What does "in stock" mean?

If you show a catalog listing of a product (the T-shirt), and some of the variations (sizes) are in stock while others are out of stock, is the product itself in stock? Most of the time, yes. But it can be a grey area. If you only have XXL shirts left, that's kind of an out-of- stock item. If you were in a retail store, you'd likely dump those few shirts in a clearance bin. You're not going to advertise that you have all these shirts when in fact you only have one size.

Stock seems like a simple yes-we-have-it or no-we're-out kind of thing, but there's more to it than that. If you don't have it, when can you get it? Is it something that gets custom ordered anyway and people aren't going to care if they have to wait two or three or four weeks for it? Then it can always be in stock, because you can always get it. Is it a thing that if you don't have it today, having it three days from now is useless? Then you really don't have it in stock.

You need to decide on these kinds of things so you can configure your Drupal Commerce site appropriately. If you only have a couple of XXL shirts left, you could set them up as their own clearance product and sell them that way, for instance.

Blending with Drupal Commerce POS

When you integrate the Drupal Commerce POS system, those two XXL shirts are the only ones remaining for your in-store customers, so you never have to worry about orders going through that you can't fulfill. You do need to worry about irritating your customers, though—if they see a product on your site as in-stock and the go to your brick and mortar store only to realize you don't actually have it, they're going to get annoyed.

So with that in mind, you have to think about the messaging you present to your customers online. If something is out of stock but you can get it in three to five days, for instance, maybe you want to communicate that. Or if it's a one-off and you will never have it in stock again, you need to let your customers know.

Introducing transactional stock

Something new in Commerce 2 is the concept of transactional stock. So you don't just have a product in stock: you have two that have been purchased and are about to be sent out, you have six sitting in inventory, and you have five on order. And maybe you have a pending return that you can eventually sell, but not until the return is complete. As far as your fulfillment people are concerned, you only have six. But your customer service and inventory management people know about the ones that are coming, and can adapt accordingly.

TL:DR: Stock in Commerce 2 is transactional and flexible.

Chat with us

If you'd like to know more about Drupal Commerce 2, online stock management or anything else ecommerce related, give us a shout. We'd love to help you out.

Contact Us 

Nov 30 2017
Nov 30

Docker and Vagrant logos

Docker and Vagrant logos

If you work on multiple projects at once, or need to collaborate with other developers (as many of us do), then getting your development environment up and running quickly can be crucial to your ability to make efficient progress.

For the past few years, the best tool to help you do that was Vagrant. Vagrant interacts with Virtual Machines. One of it’s greatest features is that most of the configuration can happen in a vagrantfile, which can then be committed to your project. This allows developers to easily clone a project and get a development environment up and running without any special configuration.

Now Docker is the new kid on the playground. Docker provides the ability to have thin containers which focus on a specific service, whether that’s MySQL, Nginx, Apache, or testing applications like Behat, and Selenium. So now we have smaller containers, without the same overhead as that of a traditional Virtual Machine.

Sounds great, right? Well yes, but now your existing tools may need to interact with Docker. Or maybe you’ve run into a need for both Docker and Vagrant to co-exist with each other, depending on your needs. The good news is that there is a solid way of making this happen!

In this post I’ll walk you through installing Docksal and setting it up so that Docker can work side by side with Vagrant. All of the following steps have been tested on macOS going through a command line.

Installing and Configuring

We’ll start with the basics.

Step 1: Installing Docksal

The first step is making sure you install Docksal. To do this, you can use the handy one-liner below.

curl -fsSL get.docksal.io | sh

This line of code will install the Docksal command fin and, if needed, will install Virtualbox. That means there’s no need to go out and install Docker ahead of time. Note: If you already have Vagrant and Virtualbox installed it may be best for you to shut down all VMs as the installation can sometimes hang in the process.

Step 2: Create the Projects Folder to House Development

Next, we have to configure the directory that the Docksal VM mounts for use with Docker. By default, Docksal will attempt to mount just the /Users directory. The problem with this is that if you have a Vagrant VM mounted anywhere within the the same same folder hierarchy then it will cause an error. So, you’ll need to tell Docksal to mount a folder deeper within the structure that isn’t already being mounted.

mkdir -p ~/projects/docksal

For this example, we will place a folder within our user’s home directory labeled projects. Sometimes this folder will already exist. If so, you could just change into that directory.

Create a Docksal directory to house all of the Docksal projects. The name of this folder is arbitrary. For this example we will use a simple name. This folder’s main purpose is to hold all of your Docksal projects. This is also the data that will get mounted to your projects when they are started.

Step 3: Configuring Mounted Path

Once we have created the folder hierarchy for our projects, we have to tell Docksal what folder to mount into the VM, so we’ll have to add the following line to our global docksal.env file which is located in ~/.docksal/docksal.env

DOCKSAL_NFS_PATH=~/projects/docksal

To speed up this process, use the following one-line command:

echo "DOCKSAL_NFS_PATH=~/projects/docksal" >> ~/.docksal/docksal.env

Step 4: Start Virtual Machine

After we’ve added the DOCKSAL_NFS_PATH line, now comes the process of starting our VM. Running the vm start command will make sure that the VM is running. The following command can be run from any folder in a terminal window.

fin vm start

It should result with a similar response:

Starting "docksal"...
(docksal) Check network to re-create if needed...
(docksal) Waiting for an IP...
Machine "docksal" was started.
Waiting for SSH to be available...
Detecting the provisioner...
Started machines may have new IP addresses. You may need to re-run the `docker-machine env` command.
Enabling automatic *.docksal DNS resolver...
Clearing DNS cache...
Configuring NFS shares...
NFS shares are already configured
Mounting NFS shares...
Starting nfs client utilities.
Mounting local /Users/example/project/docksal/ to /Users/example/project/docksal/
Importing ssh keys...
Identity added: id_rsa (id_rsa)

If you happen to get the following message:

Machine "docksal" is already running.

then a restart may be necessary, which can be done using the this command:

fin vm restart

Upon a successful restart, you should see a similar response:

Stopping "docksal"...
Machine "docksal" was stopped.
Starting "docksal"...
(docksal) Check network to re-create if needed...
(docksal) Waiting for an IP...
Machine "docksal" was started.
Waiting for SSH to be available...
Detecting the provisioner...
Started machines may have new IP addresses. You may need to re-run the `docker-machine env` command.
Enabling automatic *.docksal DNS resolver...
Clearing DNS cache...
Configuring NFS shares...
NFS shares are already configured
Mounting NFS shares...
Starting nfs client utilities.
Mounting local /Users/example/project/docksal/ to /Users/example/project/docksal/
Importing ssh keys...
Identity added: id_rsa (id_rsa)

Want to learn more? Contact us.

Testing Configuration

Step 1: Start Docksal Setup

Now comes the fun part where we get to test our new configuration. Was it successful? Let’s see if our work has paid off and get our first Docksal project up and running.

Start by navigating to the project folder that was created in the previous steps.

cd ~/projects/docksal

Then we will clone a basic Drupal 8 project that has Docksal configured,

git clone https://github.com/kanopi/drupal8-composer-docksal drupal8

and change into that project we just downloaded:

cd drupal8

Now, initialize the project

fin init

If you previously had Docksal installed and the following error appears on your screen,

Minimal fin version required is: 1.22.0
Please run fin update and try again

then run the update command for the latest version of Docksal:

fin update

In this project, we have a basic initalize command that will use composer to download all of the libraries. Don’t have composer? Don’t worry, composer will get installed in the container. Drush then runs the site-install command.

Want to know if this command worked properly? Did you get results like this? If so, great!

Step 1 Initializing stack...
Removing containers...
Removing drupal8_web_1 ... done
Removing drupal8_db_1 ... done
Removing drupal8_cli_1 ... done
Removing network drupal8_default
Removing volume drupal8_project_root
Volume docksal_ssh_agent is external, skipping
Starting services...
Creating network "drupal8_default" with the default driver
Creating volume "drupal8_project_root" with local driver
Creating drupal8_cli_1 ...
Creating drupal8_cli_1
Creating drupal8_db_1 ...
Creating drupal8_cli_1 ... done
Creating drupal8_db_1 ... done
Creating drupal8_web_1 ... done
Waiting for drupal8_cli_1 to become ready...
Connected vhost-proxy to "drupal8_default" network.
Waiting 10s for MySQL to initialize...
Step 2 Initializing site...
Making site directory writable...
/var/www/docroot/sites/default/settings.local.php already in place.
You are about to DROP all tables in your 'default' database. Do you want to continue? (y/n): y
Starting Drupal installation. This takes a while. Consider using the --notify global option. Installation complete. User name: admin User password: 7yDUeUyVvH
Congratulations, you installed Drupal!
real 0m22.527s
user 0m6.640s
sys 0m2.980s

Drum roll… Open a browser to http://drupal8.docksal and you should see a freshly installed Drupal 8 site.

Step 2: Confirming Vagrant is Intact

For this step, we won’t be able to guide you through the process since all projects are different. The easiest way to confirm is to navigate to one of your Vagrant projects, then stop and restart the project.

vagrant halt
vagrant up

Running this should not cause any issues with mounting the project, and should start your Vagrant project.

Summary

To summarize, we completed a basic Docksal install. The one liner was installed which can usually accommodate, unless you are also running Vagrant. In that case we modify the folder which mounts to the Docksal VM. The reason for this is that NFS exports can’t overlap. By default, Docksal uses /Users which can cause an issue, as most, if not all the projects a developer does in Vagrant are usually in that User’s directory.

What this also means is that all Docksal projects will have to live within the DOCKSAL_NFS_PATH folder, because when Docksal uses the minimal VM layer on virtualbox it’s only mounting that one folder, whereas Vagrant projects are mounting individual projects to their respective VM.

We also ran a test to make sure we could get a basic Drupal 8 installation. This provides a good starting point when testing development within the Docksal system.

Nov 28 2017
Nov 28

If you ever have need of timed or delayed payments, we have some good news: recurring billing (also known as subscriptions) is new and improved in Commerce 2. Check out this week's High5 episode and learn more!

What is recurring billing?

It's anything where we want to have a transaction happen after the initial time when a customer is on our site. That might be monthly or yearly, or it might be when you want the last half of the payment to go through in a couple days or a week.

How does it work?

It's not like we store pictures of everyone's credit cards and just keep applying charges to them. Instead, we store tokens, or references to the credit cards. This is much safer because it means that even if the site got hacked, no one would have access to your actual banking information. At no point does Commerce ever store your actual credit card.

If you're interested in reading more about tokenization, Wikipedia has a lot of good information on the subject. 

How is this different from Commerce 1?

We sort of had tokenization (a.k.a card on file) in Commerce 1. It was a contrib module and wasn't actually part of Commerce itself. Some payment gateways supported it, some didn't, some did but only partially… it was much more of an ad hoc thing.

Now, tokenization is built into Commerce, so any major payment gateway that gets set up and has the capacity to store tokens (which is most of them), will do so. You don't need to do anything special for your payment gateway to handle recurring billings. As long as we have that token, we can keep making charges to it until that token becomes invalid (i.e. the card gets cancelled).

It was actually a credit to Commerce 1 that it had tokenization at all. It's a complex thing. For instance, if a payment doesn't go through, do we have to cancel the subscription? Do we have to get the product back? Do we do that immediately, or give them a window of time to put in the new card? A lot of ecommerce setups just avoided that entirely, so it was definitely a strength of Commerce 1, and now it's really a strength of Commerce 2.

The bottom line

Recurring billing rocks, and is now built right into Commerce 2. 

Nov 23 2017
Nov 23

Is your commerce site ready for the big time? We're talking about Black Fridays, product launches, back-to-school weeks, and any other time you are going to get exponentially more traffic than you would normally get. A lot of people just assume their site/server/staff can handle such increased volume, but unless you've tested it by running 10 or 20 or 50 times the traffic through it, you really don't know.

The problem is that scaling doesn't work in a linear way. Let's say you're currently using 10 percent of your server's capacity. Simple math would indicate that you could handle 10 times as much traffic and be at 100% of capacity, so you should be fine.

But it doesn't necessarily work that way in the real world. It could be that there is some sort of hidden flaw that flares up when that volume of traffic comes through: maybe you hit some sort of race condition, or a caching system starts to cycle too fast, or you get a database bottleneck and everything gets backed up behind it. It could be some little glitch that's easily fixed and everything goes back to normal—but if you fix it halfway through the biggest sales day of the year, it's too late.

So how can you get ready?

1. Do performance testing.

Your goal should be to mimic live as much as possible. You don't just want to run the test on your local server. You want to spin up a similar environment, or maybe spin something up at 1/10th of the scale and hit it hard with lots of capacity. Or do it through Amazon and only run it for an hour or something to save on cost.

Once you have your environment, you have to try to simulate actual traffic. You don't want to just hit the home page repeatedly, because that's not how your customers interact with your site. They go through the checkout, and click around on product pages, and search, and log in to their account. They do a whole bunch of random stuff, and you have to try to mimic that. You can't do it perfectly, but you want to hit all the parts of your site and throw a bit of randomness in there to try to get as close to the real experience as possible.

In a perfect world, you would have gone through a similar event like Black Friday already and learned from it. But maybe you're a first-timer. Or maybe you're launching a big new product unlike anything you've had before, and it's backed by a TV spot, and you're expecting a massive volume of sales to follow. So test your site and be sure.

2. Prepare for stock issues.

Stock problems can obviously be much worse in a high-volume situation. On a slow day, if an order goes through when you are out of stock, maybe you could just call that person and say oops, sorry, but it's going to take a couple days to fill that order.

But if you have a huge burst of traffic, you might sell 20 items when you only have two in stock. And you can't even get 18 on your next order, and it's going to take six weeks to get that many, and now you have a real problem.

So if that happens, what do you do? How are you handling out-of-stock issues? Do you have messaging to say this is going to be delayed? Are you going to shift customers to alternate recommended products? These are all things you need to consider.

3. Set staffing levels appropriately.

You don't want to be in a situation where your website can handle the traffic, but your human workers cannot. In a physical store, everyone knows they need to up the number of sales staff to deal with a huge crush of shoppers. But when it comes to the website, sometimes people forget that someone still needs to put 10 times as many items in boxes, and deal with 10 times as many email complaints, and talk to 10 times as many customers via live chat.

How does your current process scale? How fast does it take you to do an order? Maybe you need to think about automated shipping, or standardized box sizes, or any one of a number of other things that will make your staff's lives easier during high-volume times.

Conclusion

As you can see, there are quite a few things that you can do to make sure your opperating smoothly during those peak sales days throughout the year. Some of these things you can do yourself. Some of them you might need some technical support. If support is what you need, or you'd like to discuss this further, contact us. We've been through it all before and can share our experience.

Contact Us

Nov 23 2017
Nov 23

Currently we are busy building a realtime chat platform called Lus. In Lus we connected Drupal to NodeJS for a blazing fast system, with realtime communication (chats, tasks & file sharing).

Within Lus, people can cooperate in ‘channels’, comparable to the WhatsApp groups. Team communication takes place in these channels. A channels works best if you organize it around a certain topic, like ‘sales’.

As soon as a new channel is being started, existing team members can be added in the easiest way imaginable: with the help of a ‘auto-complete field’: as soon as you start typing, suggestions will immediately pop up, in this case for names of team members:

This auto-complete field has been custom developed by us, in part because our Drupal installation uses custom database charts which aren’t available in Drupal 8 core. How did we do it:

1. The form element

To get started we need the Drupal auto complete form element, allowing users on the front end to pick the desired team members. We define this as follows:

Because we use #autocomplete_route_name element, Drupal knows that such a form element has to be ignored on the front end.

2. Custom route

As you can see in the form element, a reference is made to the route, from which data has to be obtained. We’ll add these in the .routing.yml file:

This routing.yml file is already in our module’s root.

3. Controller with custom query

In the route we just created we refer to a custom controller AutocompleteController, method handleAutocomplete. This one can be found in the map moduleroot/src/Controller:

This method ensures that the right data is collected from the data base and will be given back correctly formatted as well.

Wrap it up

As you can see, suggestions are being given for code corrections. In an optimization run we’ll get onto it. For now, at least the data is coming though correctly and we can create new channels with existing team members by means of a auto-complete field.

Credits header foto: ricardo Gomez Angel

Nov 21 2017
Nov 21

 

 

A point of sales system is already in production in Drupal 7; people are using it and seem to like it. And now, we've ported it to Commerce 2 for Drupal 8. Check out this week's High5 to learn more!

What does this mean?

In Drupal 8, the POS is much more built in, and you can easily do things like change out widgets. So if you update your orders and you add a new field, the field will show up there. If you add a specific widget that controls how that field displays, you can pick from a list of available options and it will work in the POS.

How is this different?

In Drupal 7, the POS was very stand alone—it was all custom-built forms and custom-built options. You actually configured it outside of Commerce itself. It used some of the underlying parts of Commerce, but from a user perspective it was almost as if it was a separate module.

For Drupal 8, that's not the case. It has the same level of functionality, but it's integrated much more so you can use a lot of the Commerce infrastructure. For instance: Drupal 7 had the concept of locations (as in store locations), but Drupal 8 has the concept of stores built right in, so we just use that. There's lots of stuff that goes along with stores: you can attach addresses and extra billing information and so on, and the POS can take full advantage of that in Drupal 8.

Are there any new features?

We have quite a bit more reporting (such as KPI reports for tacking metrics for sales people, for instance.) We also have a new "quick add" section that lets you easily add common products without having to look them up by SKU—it's quite robust and fits nicely into the user interface.

When will all this be ready?

We're only at Alpha 1 right now. Alpha 2 should be coming soon. The module should be fully ready to go in the near future. You can download it's current state and follow progress here.

The bottom line

POS is finally ready for Drupal 8. You can start using it, and we're going to continue releasing new features at least once a month for the foreseeable future.

Nov 16 2017
Nov 16

As one of North America’s premier users of Drupal we have worked together with Okanagan College to develop a new Drupal Web Developer Certificate that will be offered weekday evenings beginning January 8, 2018.

We are so anxious to find coding talent that we are putting our own money on the line in hopes of addressing our HR recruitment challenges.

“We need great candidates for interesting and exciting CMS work in Kelowna and are looking forward to hiring graduates from this program,” says Shae Inglis, CEO of Acro Media. “In fact, Acro Media is going beyond just supporting the OC program. We are also sponsoring a contest to provide a $4,000 tuition award to a talented student who submits the best code sample before Dec. 15 for the January intake of the course. Contest details are available at www.acromedia.com/contest

“The Drupal Web Developer Certificate will give students the knowledge, practice and experience to find great jobs and careers in the Okanagan. This exciting Okanagan College and industry partnership has resulted in a program that will provide companies with highly qualified and work-ready graduates,” explains Dennis Silvestrone, Okanagan College’s Director of Continuing Studies and Corporate Training.

Taught by industry experts, this 240-hour Certificate will be offered at the Okanagan Innovation Centre in downtown Kelowna Mondays through Thursdays from 4:30 p.m. to 9:30 p.m. Students applying for the Drupal Web Developer Certificate are financial aid and student loan eligible.

For more information visit www.okanagan.bc.ca/drupal or call 1-888-638-0058 to learn more about qualifying for this Certificate.

Nov 14 2017
Nov 14

Moving to a new e-commerce platform can be a massive undertaking, but Drupal is making it simple. Whether you currently use Commerce 1, Ubercart, Shopify, or Magento, there is (or will soon be) an easy way to move over to Commerce 2 and see what it can offer you. Watch the latest High5 video here to learn more.

What moving means

There are a ton of different parts that make up your e-commerce site: products, product variations, orders, customers, account balances, user logins, etc. One of the first things you need to decide is which parts you're going to migrate. Maybe you want to pull order data, but not discounts, which can be notoriously difficult to move over. Products are obviously essential, but moving tax rules over is not nearly as crucial, since you could probably set those up yourself (and if you work with a third party for that anyway, migrating tax rules is a waste of time).

What migrate tools can do

Migrating your site manually is incredibly labor-intensive and prone to failure (you try moving 10,000 products manually without screwing any of them up.) Automating the process with migrating tools that have been thoroughly tested will give you a lot more consistency when moving your data around. And the best part is that this is all open source; we're releasing these tools so that anyone can migrate their site on their own at no charge.

How the tools were developed

We started from the most common stuff (products, orders) and worked our way out to customers and discounts and product classes and all the rest. We have sample sets that we test for each of those aspects. So we have full databases of Ubercart sites, for instance, that we migrate over so we can see which parts are missing and what needs to be improved. We continually work to build those missing pieces and fill out all those edge cases.

What's ready and what's coming

We have all the basics done for Ubercart; if you want to do an Ubercart to Commerce 2 migration right now, you can do it, though you might have to do a little bit of configuring and customizing to get the edge cases. We're trying to get to a point where you can literally just push a button and have everything move over, but that's still a couple months away. Commerce 1 is close to that, Magento is pretty basic, and Shopify is more of a prototype right now.

Nov 14 2017
Nov 14

Our year-end rush is in full swing. Briefly looking back, we have had a good year! For the last time this year, the module updates, and what struck me:

1. Block Refresh

A block in Drupal will not change its content by itself. Perhaps you would like a block to refresh automatically: so that visitors of your Drupal website will get to see for example every 15 seconds a new article, or an urgent message coming through without people having to refresh their page.

After installing this module you can set this per block in three different ways:

  • Automatically via a timer (f.e. every 15 seconds).
  • Manually with the aid of a ‘refresh link’.
  • Once per ‘page load’.

Even when you have enabled Drupal’s block cache this module can make sure you will get to see new content.

(Drupal 7)
 https://www.drupal.org/project/block_refresh

2. Simplify

If you look at a standard Drupal form to add, for example, a new page, it looks a bit messy. There is a lot of information on the screen, which is redundant for content managers. This commonly used module cleans up that junk.

(Drupal 7 & Drupal 8)
 https://www.drupal.org/project/simplify

3. W3C Validator

A W3C validated web page means that the HTML formatting is correct according to the standards. This means that the structure is sound and that probably all browsers and screen readers can properly read the page; this is also good for your SEO. This module helps you with W3C validations:

  • It validates new pages or nodes you are creating.
  • It can generate a report of all your pages.

(Drupal 7 & Drupal 8)
 https://www.drupal.org/project/w3c_validator

4. Search 404

A standard 404 page (‘page not found’) gives rather poor information to your visitors. This popular module will change that: it does not show a static page, but will search into your Drupal system and will show your visitors results of pages they might have been looking for.

This feature will also have a positive impact on the SEO of your Drupal system.

(Drupal 7 & Drupal 8 alpha)
 https://www.drupal.org/project/search404

5. Custom Search

The default search field in Drupal is pretty straight forward: a search box and a ‘search’ button. This module expands this with more advanced search options:

Configure text:

And some config options:

There are more advanced options, install the module and see which ones are of interest to you.

FYI: The Drupal 8 version gave me an error during the installation in Drupal 8.0.1

(Drupal 7 & Drupal 8 beta)
 https://www.drupal.org/project/custom_search

6. Block by date

Let’s assume you want to place a notification at a given time within a block in your Drupal site. For example, an offer, notification or maintenance message. Then this module can come in handy: it can automatically switch a block between a specific date and time on and off for you.

(Drupal 7)
 https://www.drupal.org/project/block_date

7. Scheduled maintenance

It is preferred to announce a scheduled maintenance on a website. So users know that the site — or part of it — is temporarily unavailable. Within the Drupal core functionality it is possible to enable the ‘maintenance module’ for your website, but it is only possible to turn it off or on.

With this module you can automatically inform your website visitors (or social intranet) about a scheduled maintenance:

  • You can set a message with the announcement.
  • Specify how long up front this message needs to be visible.
  • Specify when Drupal should actually go into the maintenance mode.

(Drupal 7 & Drupal 8 alpha)
 https://www.drupal.org/project/scheduled_maintenance

8. Select2 Field Widget

A better and more useful way to enable your content managers to make a selection.

(Drupal 7)
 https://www.drupal.org/project/select2widget

9. Back to top

Very popular since the rise of responsive Drupal websites: the ‘back to top’ button. Convenient for visitors with a mobile or tablet.

(Drupal 7 & Drupal 8 beta)
 https://www.drupal.org/project/back_to_top

10. Form Bloc IP — FBIp (Drupal 7 & Drupal 8)

Maybe you encountered this problem before: a user tries to log in, but forgot his/her password. After several failed attempts Drupal blocks the user for some time. And that block cannot be made undone by an admin in the Drupal backend; only directly via the database.

This module is solving that problem and other problems:

  • An admin screen to unblock blocked users.
  • Log IP addresses of spammers and block them.
  • Create a white list of IP addresses; only those IP’s can from now on send (login) forms.

https://www.drupal.org/project/fbip

11. Safe cache_form Clear

Drupal’s cache_form table can quickly become quite large and clog the system, but with a ‘clear all caches’ Drupal is throwing away everything that can cause performance issues.

This module is solving that: it will only clear small bundles (chunks) of this cache table. Easily manageable chunks for Drupal which will avoid performance issues.

It only works in combination with database cache tables, not when you are using for example external caches likes Memcache of Filecache.

(Drupal 7)
 https://www.drupal.org/project/safe_cache_form_clear

12. Search API attachments

By default Drupal indexes only content from nodes. If you are also working with attachments in Drupal I can imagine that you also want to index the contents of those files, so that they are included when visitors are performing searches in your Drupal site.

This module is helping with that, it is an add-on for the Search API module and requires the Apache Tika Library. It also runs on Apache Solr. Solr is preferred otherwise your database can quickly become too large, which results in time consuming searches and visitors dropping out.

(Drupal 7 & Drupal 8 alpha)
 https://www.drupal.org/project/search_api_attachments

13. Navbar Awesome

An add-on for the Navbar module. The Navbar is a common used module for Drupal 7 providing easy and responsive backend navigation. It is similar to the default navigation bar in Drupal 8.
 This Navbar Awesome module gives the Navbar a more ‘clean’ and modern look.

(Drupal 7 beta & Drupal 8 beta)

https://www.drupal.org/project/navbar_awesome

14. Taxonomy unique

Do you want to make sure that all terms (keywords/tags) entered in one Drupal vocabulary are unique? After installing this module Drupal will check if that is the case. When you enter a term that is not unique, then an error will be shown.

(Drupal 7 en Drupal 8 beta)
 https://www.drupal.org/project/taxonomy_unique

15. Nagios

When you are managing many Drupal sites then central active monitoring can save a lot of work. This module integrates monitoring using Nagios. It checks, among others, the following components:

  • Is the database accessible
  • Is cron running well
  • Should Drupal core or modules be updated
  • Is PHP running well (in case PHP for some reason drops out)
  • Is the database structure (schedule) running behind
  • Is the ‘files’ directory writable
  • Other status messages, which can also be seen in the ‘Drupal Status report’.

(Drupal 7 & Drupal 8 dev)
 https://www.drupal.org/project/nagios

16. Rename Admin Paths

An additional security for your Drupal backend. With this module you can change the default backend paths such as /admin/… and /user/… into something else. So spambots, hackbots and hackers do not know which URL to use.

(Drupal 7 en Drupal 8)
 https://www.drupal.org/project/rename_admin_paths

17. Login destination

After a user logs in, you might want to refer him/her to a particular path, such as his/her personal dashboard. This small, popular module allows you to easily set this up.

(Drupal 7)
 https://www.drupal.org/project/login_destination

18. Memcache Storage

When you are managing a high performance Drupal site, then chances are that you have implemented the Drupal Memcache module. This module is only an integration and gives statistics per page about the Memcache use, but does not provide any other administrative tasks herein.
 This module is an alternative and does offer additional administrative tasks for the Memcache actions within your Drupal system, including:

  • What caches are stored where (Memcache or database).
  • ‘User sessions’ and ‘locks’ can also be stored in the memory.
  • Separate empty caches / Memcache bins.
  • Drush integration.
  • (Drupal 7 en Drupal 8 beta)
  • https://www.drupal.org/project/memcache_storage

19. User Password Reset Link Timeout

Once you create a user within Drupal you can send a one-time login link; which is by default valid for 24 hours. This period cannot be set automatically, after installing this module it is.
 We recently used it with an implementation of Drupal social intranet OpenLucius, in which we first imported users and then sent a login link simultaneously via the Mass Password Reset module.

(Drupal 7)
 https://www.drupal.org/project/user_pwreset_timeout

20. Force Password Change

For better protection of the data of your users, it is recommended that they periodically change their passwords. This is not forced by default in Drupal; this module can take care of this.

(Drupal 7)
 https://www.drupal.org/project/force_password_change

21. Dummy image

When you are developing on your localhost, then usually you do not have all images from a live environment stored on your local computer. This is resulting in lots of broken images and delays in page loads.
 This module makes sure you get to see dummy images so that it is not needed to constantly sync all images from live and yet it is possible to test them locally.

(Drupal 7 en Drupal 8 alpha)
 https://www.drupal.org/project/dummyimage

22. Stage file proxy

Another solution to the same problem described above: when you have not stored all files and images locally. When you install this module and it finds an image that is locally not found, then it copies the image from live to local. It only does this for the pages you visit locally so you need minimal disk space; especially handy when dealing with a large site with many files/images.

(Drupal 7 en Drupal 8 dev)
 https://www.drupal.org/project/stage_file_proxy

Wrap up

That’s all folks. Next month again a new ‘cool Drupal modules’ blog. Stay tuned!

Nov 14 2017
Nov 14

Christmas is almost here!

In our last post you saw our call for venues. Europe answered the call and we received 13 venue submissions from 7 countries, including Australia. We are now working through the submissions and we will send out a more detailed question list to all submitters.

Get involved

So far a lot of work has been done in norming and storming and the team continues to build great momentum and is strengthened almost every day. We believe that “Many hands make light work” and we’d like you to get involved. Even helping with small tasks will help to make this great event happen. So if you want to participate then now is the time to take action and get involved! Sign up on our OpenSocial website and spread the word by tweeting and sharing on Facebook about this great community-driven event.

The proposed event model

The current consensus is to start with a minimum viable conference model:

  • Two days of sessions (Thursday and Friday)
  • General Contribution Day (Saturday)
Schema

If possible, this could be expanded with two days beforehand for trainings and a community day. This also means a contributor can contribute for 5 days.

This is still at the planning stage and any ideas you may have would be greatly received.

To make this event sustainable, we may not be providing food which will significantly cut down the cost for this event. We’ll make the final decision based on what is possible with the budget. Best effort will be made to invite food trucks and find good restaurants in the area if needed.

Wifi is under heavy debate and depends on what the location is charging. We are hoping that we can come up with a cost effective solution. It is the next tier in this growing conference model. Followed by coffee and snacks.

If we get the main community event funding model correct, then we might be able to also facilitate food in the training and community days. In summary we are looking at budget items in priority order and not as a given.

Conference costs for Dublin 2016

This might be confusing to read but is in fact very logical if we look at the thumb figures from Dublin. In a blog post from the Drupal Association, the financial problem of DrupalCon Europe was explained.

Around ⅔ of the income comes from ticket sale and the rest comes from sponsorships and other sources. If we look at the expenses, roughly 50% of the expenses are for the catering and the facility cost. For more detailed information you can look at the Profit & Loss statement from the blogpost.

What do these numbers tell us? It helps us to understand what are the largest expenses of an event of this size. We are using this information to help us to find ways to cut down costs. For example, we can:

  • Cut down on the floor space needed by having a smaller auditorium and streaming the keynote to other rooms at the venue.
  • Use a venue that is close to local food outlets which could make supplying food optional
  • Aim for locations that allow us to cut down on staff costs by means of volunteers

If we do this, then this could become a viable, even profitable event. Any profits generated could be used in supporting camps in the region as well as flow back into the project.

Going out of the comfort zone

In 2017 we had over 50 Drupal camps in Europe. Almost all of them were within the Drupal camp comfort zone of 500 attendees maximum, with a budget between 50k and 80k euros. So in order to be successful we need to experiment and consult or even hire some professionals.

Drawing by Baddy

What is next?

The venue is very important for any conference but we are not losing sight of what is ahead. We have many steps that we still have to cover in order to bring you, your friends and colleagues a great event:

  • Define sponsor benefits and packages
  • Decide how to handle talk/session proposal and selection process
  • Marketing and Promotion — in the community and outside
  • Volunteer coordination — can some tasks be crowdsourced?
  • Create an event website — we are still looking for some design help here!

But before we dive too deep into any of those tasks, the venue needs to be in place — we will be reaching out to those that have submitted proposal with some additional questions (if all goes as planned those will be sent out Monday) and we expect to be able to confirm the venue mid-December.

If you can provide some insights, advice or want to help collaborate getting this event further on its way, please do not hesitate reaching out to us! Either on twitter or [email protected]

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