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]

Nov 13 2017
Nov 13

Business people working on project in office

Business people working on project in office

By now you have likely heard quite a bit about Drupal 8. But do you have a good sense of when and why to make the switch?

Switching to Drupal 8 will make new features and functionality available for your site and help you stay current with the latest best practices. But it will take time and effort, and may mean a bit of refactoring as well.

What’s new in Drupal 8?

Drupal 8 adds a number of helpful features into core, making it possible to build fully-featured websites out of the box. Drupal 8 takes care of basic needs, so contributed modules can be reserved for specialized functionality.

There are more than 200 new features in Drupal 8, including built-in support for multilingual and mobile-friendly sites, a simplified content authoring experience with in-place editing, native web services, Views integration into core, stronger HTML5 support and much more.

In addition, Drupal 8 is written in well structured, object-oriented PHP based on the Symfony framework. And it leverages the Twig templating system, making design patterns simpler, faster, more logical and more secure.

Once you are on Drupal 8, you can easily take advantage of minor releases that will add powerful functionality on a predictable schedule, without requiring you to reinvent your site. And the focus on backwards compatibility beginning with Drupal 9 means upgrading between major versions won’t be a massive headache like it has been with past versions of Drupal.

Time to switch?

There are a number of factors to consider when deciding to switch to Drupal 8. In general, the sooner you can bring your site up to the most up-to-date standards, the better. But it’s also important to consider your objectives when deciding on the best time for an upgrade.

If the functionality in Drupal 8 would revolutionize the way you do business, or you are considering rolling out significant new functionality, now might be a good time to switch. But if your Drupal 7 site is running well and there aren’t any solid business reasons to make the switch, you may consider holding off until Drupal 9 becomes available.

To help clarify your decision, we’ve created a quiz to help you determine when it’s time to make the switch.

Nov 13 2017
Nov 13
November 13th, 2017

Welcome to the fourth episode in our video series for Emulsify 2.x. Emulsify 2.x is a new release that embodies our commitment to component-driven design within Drupal. We’ve added Composer and Drush support, as well as open-source Twig functions and many other changes to increase ease-of-use.

In this video, we’re going to teach you how to best use a DRY Twig approach when working in Emulsify. This blog post accompanies a tutorial video, embedded at the end of this post.

DRYing Out Your Twigs

Although we’ve been using a DRY Twig approach in Emulsify since before the 2.x release, it’s a topic worth addressing because it is unique to Emulsify and provides great benefit to you workflow. After all, what drew you to component-driven development in the first place? Making things DRY of course!

In component-driven development, we build components once and reuse them together in different combination—like playing with Lego. In Emulsify, we use Sass mixins and BEM-style CSS to make our CSS as reusable and isolated as possible. DRY Twig simply extends these same benefits to the HTML itself. Let’s look at an example:

Non-DRY Twig:

<h2 class=”title”> <a class=”title__link” href=”/”>Link Text</a> </h2> <h2class=title><aclass=title__link” href=/>LinkText</a>

DRY Twig:

<h2 class=”title”> {% include "@atoms/01-links/link/link.twig" with { "link_content": “Link Text”, "link_url": “/”, "link_class": “title__link”, } %} </h2> <h2class=title>{%include"@atoms/01-links/link/link.twig"with{"link_content":LinkText,"link_url":/,"link_class":title__link”,

The code with DRY Twig is more verbose, but by switching to this method, we’ve now removed a point of failure in our HTML. We’re not repeating the same HTML everywhere! We write that HTML once and reuse it everywhere it is needed.

The concept is simple, and it is found everywhere in the components directory that ships in Emulsify. HTML gets written mostly as atoms and is simply reused in larger components using the default include, extends or embed functions built into Twig. We challenge you to try this in a project, and see what you think.

[embedded content]

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 | Pt 5: Building a Full Site Header in Drupal

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.

Nov 10 2017
Nov 10

I always look forward to unconferences. It’s their unpredictability and element of surprise that I enjoy, you never quite know what the day will bring. I love the edgy feel, the lower barrier to entry, and that it’s OK to fluff your words or try something new. Sensing the nerves of the ones who unexpectedly present for the first time, witnessing how energising their experience is, discovering a topic or theme for the first time, or taking the mic because you feel inspired by others are all reasons I’m drawn to attend and why CTI Digital was proud to be one of the sponsors.

The North West Drupal User Group Unconference last weekend was no exception in terms of inclusivity and our Drupal team were there in force.

 

Our Developers Thoughts

IMG_20171104_112942 (1).jpg

Phil Wolstenholme, a frontend developer in our Drupal team, spoke about using Cloudinary (a third-party image optimisation service) to deliver substantial site speed improvements for our client, Aman Resorts.

"Unconferences work without any knowledge before the event of who (or how many people) will be speaking, so there’s a rush at the start to get your idea up on the wall to secure a slot to speak in. I was lucky (or fast…) enough to bag a slot early in the day before the competition heated up for the afternoon slots.

It was interesting to talk to a primarily Drupal audience about a commercial service that exists outside of Drupal and the free and open source world. I was a bit wary of this - I wanted my talk to come across as sharing a useful tool, not a sales pitch. To show the optimisations made possible by Cloudinary I took an example component from the Aman website and applied a series of optimisations to the image within it, explaining how the file size decreased with each step. In the process, I also covered topics like the WebP image format, Client Hint HTTP headers, and the custom CDN integration we developed to reduce bandwidth costs for Aman.

With headless CMSs and microservices being a hot topic at the moment, I think we will start to see similiar talks that cover how Drupal’s out-of-the-box functionality can be supplanted by specialist third party services that do one thing, but do it very well."

 

Daniel Davison, a Junior Drupal Developer at CTI, attended the unconference for the first time this year.

"This was the first NWDUG Unconference that I attended and I was very pleased with how it turned out. The talks were all captivating and informative, and it was good to get together with the local Drupal community. I had already met quite a few of the people who attended the NWDUG monthly meet up but it was good to see so many new faces there. As soon as I entered MadLab, where the unconference was held, I was greeted by some familiar faces and handed a goody bag (always a bonus). I then found myself a seat and once everyone had arrived we planned who was doing what talks and in which room, this was so that people could go to the talks that they were interested in and decide when in the day they would do their talk if they were doing one.

Personally, my favourite talk if I exclude my colleagues, Phil and Graham, was the talk by Richard Sheppard on the use of Docker with Drupal and he talked about something I had thought about myself. I had been to Docker talks before but it had never been talked about in terms of use with Drupal so it was nice to learn about how he had been using it personally and his experiences with it. Docker is useful as it allows a developer to have more applications running on the same hardware than other technologies such as virtual machines. It makes it easy for developers to quickly create ready-to-run container applications, and it makes managing and deploying applications much easier.

Food and drink were provided and there were regular breaks. Afterwards, everyone went to Common which gave everyone an opportunity to get to know each other even further and have a drink together. Overall the event itself was well worth going to and I look forward to next year."

37455821004_3da884e553_z.jpg

Graham Brown, one of our Drupal Developers, came along to the unconference not intending to speak. But the welcoming community in NWDUG inspired his impromptu talk on PuPHPet.

"Like some of my colleagues at CTI, this was my first time attending an unconference. The registration procedure was smooth and efficient and the goody bag contained a proper mug which came in handy for the first coffee of the day! The introduction by Phil Norton was informative and included a briefing as to what an unconference actually is and how it works.

I had arrived completely unprepared talk-wise but due to the introduction making the whole process seem so relaxed and informal I decided on the spot to give a talk on PuPHPet which is an online / browser-based setup utility for those out there who use Vagrant
and their favourite virtualisation package to manage their virtual machines for development purposes.

I was impressed by the diversity of talks ranging from non-Drupal specific subjects such as website project management processes to talks which could be platform agnostic such as Docker and image compression CDNs given from a Drupal perspective. Phil’s talk on Cloudinary, for example, was a Drupal-specific show and tell about a service which is available for a vast array of CMS and e-commerce platforms, but the same principles apply to whichever framework you choose to use.

I’ll definitely be checking out the new programs I learned about and also re-visiting Docker from a Drupal perspective in an attempt to use it as an alternative to my current Vagrant-based workflows. There was also a talk given about Deployer which again I’ll also be looking at using for personal projects to make my deployments run smoother.

I’m looking forward to the next unconference. Based on the value the event gave me in terms of all the industry knowledge I gained I’m also going to be making more of an effort to go to the monthly NWDUG events held at MadLab."

 

Final Thoughts

With over 50 attendees what was striking to me, for someone in the community for over a decade, was the proportion of abundance of new faces and rising stars, graduates, apprentices, and those moving to Manchester for the digital scene. I came away feeling the local Drupal community was growing, vibrant and full of promise.
Nov 08 2017
Nov 08

diet-Drupal.pngDrupal and lightweight aren’t words that have historically gone hand in hand. Drupal 6 and 7 had some hoops to jump through to get something not included in the box. If you wanted to use an external service for displaying content or adding features you would feel that pain. Drupal had apparently not heard the phrase, “Less is more”. Does using Drupal really mean that you have to always deal with every Drupal layer to accomplish seemingly simple things? Luckily with Drupal 8 this isn’t the case any longer.

Hooks, hooks, and more hooks

Drupal is an awesome box of legos, you can build just about anything you want with it, that’s always been part of the draw for the system. The problem is that you had to have a lot of Drupal around to do it. You could do without all of the Drupal in the way by getting around it, but very quickly you would end up with a site that is in a bit of a Frankenstein’s monster situation and inheriting it would be a nightmare. If you needed something installed through some sort of package manager, you would likely have to do a whole lot of work to get it to play nice with Drupal, or you would have to sacrifice some of the benefits of using that system.

If you aren't interested in writing your own code, you could make use of the many contributed modules that are available. These little nuggets of awesome are great for adding a variety of features to your site, but they are bound by the same rules as above. Everything had to be added in a specific Drupal way and that caused a bit of overhead. Not to mention that if you have to use four modules to accomplish the feature you needed, then you also have four more to keep updated for security and stability. Not a bad solution, but it requires a lot more investment than should be necessary to allow for what should be simple, right?

Server shown with many cables tangled together.

I’m sure you’ll remember how this all went together later.

Your hooks can’t hold me!

Drupal 8 is a bit different in how you can extend it. This time around Drupal has partnered up with other industry experts, like Symfony, to make the system even more extendable and with less Drupal involved. That PDF converter library your friend likes that is installed with Composer can now be part of the project much more easily. You can even install Drupal itself that way if your hosting provider allows for that.

You can use many other libraries from a variety of sources, and they can integrate very simply while using very little Drupal code. This means you can easily add some other PHP, JavaScript, Python (if you’re into that), library and get the functionality you want without adding more reliance on other community contributed modules or deeper Drupal hooks. This opens the doors for using external services you might already be familiar with for things that Drupal already does as well. Want to use Solr or Google for searching on your site? Easy. Need your files to be stored somewhere separate from the website? Done. Want React to replace the display of your site? You get the idea.

More community contributed modules are becoming available for Drupal 8 and they are also taking advantage of the ‘less is more’ approach that comes with the upgrade. If you aren’t as technically inclined or don’t have a team that can deep dive into Drupal easily, then these will be a great way to add more features to your site. You may still need a custom solution for your needs, but these may get you closer before you get to that point. Alternatively, you could find an outside vendor that already has this all down and could expertly judge when contributed or custom solutions will work. Where would you find one of those you ask?

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

Want to get more out of Drupal? If you don’t know your Symfony from your Composer and you are stuck on these hooks, then I would suggest you try working with a team of Drupal integration experts. Ashday happens to be pretty good at this sort of thing and we aren’t shy to talk about it either. We have been working with Drupal 8 since before it was officially released and we are pretty big fans of all the great things to come out of it.

MIKE OUT

Offer for a free consultation with an Ashday expert

Nov 08 2017
Nov 08

This is part two of a two-part series.

In part one, we discussed how Drupal 8’s adoption in its first two years was a bit lackluster compared to what many expected. Grounded in a better understanding of the shortcomings of the past two years, we’ll try to equip those of you considering Drupal 8 with the information you need to make the best decision for your organization as you continue to invest in the powerful framework of Drupal.

Image of Drupal 8 adoption curve
Credit: Angie Byron AGAIN on “Everything you need to know about the top 8 changes in Drupal 8” from May 2015

Drupal 8 adoption is certainly no longer in the “early adopter” phase, yet we still haven’t entered the “majority” phase. For most organizations not yet powered by Drupal 8, our stance is: it’s probably time to upgrade. The value you’re missing out on with the newer software is real. Perhaps less obviously, if you’re investing in your Drupal 7 site beyond passive maintenance, you may well be doubling your long-term costs by deferring and exacerbating what will need to be refactored later. For organizations who have web staff, work with an agency, or do any non-trivial customization to their Drupal website, this applies to you.

A disclaimer upfront

Drupal agencies like ours benefit from upgrades in the short-term because they are usually a substantial undertaking. This fact, in part, is why over the past two years people have written more often about encouraging an upgrade to Drupal 8 rather offering a more holistic and measured perspective. A small dose of healthy skepticism typically serves site owners best. If Savas Labs is to live into its values we must factor in the needs of two other stakeholder groups when advising on an upgrade: our clients, and the collective Drupal community. Given the substantial effort to upgrade, if we focus solely on the short-term, we do our clients a disservice. In doing that, the next time those site owners and admins have the option to select a tool to power their web systems, they may look elsewhere remembering their pain and disappointment in recent experience. This ripple effect has the potential to create many former Drupal users. Imbued with the open source ethos, we believe we owe it to the broader Drupal community from which we’ve gained so much to consult with honesty and integrity.

What you’re missing out on

As we discussed in part 1, we lived through the challenges of the complete re-architecture of the Drupal application from 7 to 8.

Angie Byron, the person I apparently can’t stop referencing, said in 2013:

For people who grew up learning PHP on Drupal, and there are a lot of people for whom that’s true, I think Drupal 8 will be kind of a big adjustment for them.

Though it wasn’t easy, at Savas Labs we feel strongly that it was a wise investment that’s just beginning to pay off. At this point in its maturation, we believe now (as other Drupal leaders have felt for some time), that Drupal 8 is superior to previous versions in nearly all use cases for which organizations currently use Drupal. Some argue that Drupal 8 has become too complex and left smaller sites behind, but it’s important to consider their incentives for a well-rounded perspective. Via Acquia, Pantheon and other hosting providers, you can serve up a Drupal 8 website within minutes equipped with more features and a superior user experience to previous versions on a free tier to boot! While simultaneously catering better to those not writing code, the engineers who have always pushed Drupal to its physical limits have more power to build sophisticated tools and integrations that can do more for their clients than ever before.

In exploring this deeper, let’s start with the technical, and dig into the more nuanced to answer the Drupal 8 question: “What’s in it for me?” (WIIFM?), for you.

WIIFM? Features.

It’s fairly easy to find information touting Drupal 8’s strengths around the web, and it’s pretty straightforward that software we write today (and have been writing for 4 years) is superior to software written 8.5 years ago (or 10.5 years ago with Drupal 6). Let’s look briefly at some high-impact improved features for site owners and admins.

Design/UX/Usability Improvements with Drupal 8

In developing Drupal 8, perhaps for the first time, the Drupal leadership took user experience work seriously and developed a cohesive strategy to improve UX for Drupal 8. The results paid off.

  1. Responsive out of the box: Given that Drupal 8’s release came long after responsive web design became popular enough to garner its own acronym, naturally, all themes (administrative and otherwise) were developed to be responsive. RWD has been a must for years, but it took heavy lifting to achieve in Drupal 7.
  2. Better content authoring: Drupal 8 has adopted a more Wordpress-like UX for editors, which for many years had been cited as a distinction between the two, rightfully favoring Wordpress. Content authoring layout improvements coupled with responsiveness have made administration from a phone a pleasant experience.
  3. Accessibility at lower cost: Accessibility efforts, though not prioritized by all, continue to gain traction as we continue to expand our ability to be inclusive. We’ve seen clients threatened with lawsuits over not adhering to accessibility standards. Whether motivated by benevolence or risk-aversion, accessibility should be on your radar, and it’s easier in Drupal 8.
  4. Multilingual in core: With a cohesive system now in core, we have been able to build a couple of multilingual sites with relative ease, not having to dedicate substantial additional time to the translation component.

Drupal 8 multilingual is a world of difference. What would take 22 or more modules in Drupal 7 you would do with 4 (and all in core). - @kristen_pol

RESTful possibilities

One of the developmental focuses of Drupal 8 we believe has tremendous impact on how organizations can maximize the value of their content is the API-first Initiative. We will likely write an entire post about this in the future, but in short the initiative makes Drupal 8 much better equipped to serve as a central content repository that can expose content to many types of devices in the formats they require for display. Historically, Drupal has been pretty exclusively focused on producing HTML (one format) for a web browser (the device/software). Drupal 8 now treats Roku, iOS & Android Apps, video game systems and the web browser all as first-rate citizens for content consumption. As the number and variety of devices that connect to the web continues to rapidly grow, Drupal 8 can serve as a powerful hub that provides relevant content and experiences to end-users. You’d be remiss to snooze on this one. To get an idea of the possibilities check out Contenta CMS, a Drupal 8 distribution built by some of the people behind the initiative.

WIIFM? Performance.

If you take performance seriously, which you should, there’s a lot to like about Drupal 8. Sticking with the theme of sophistication, Drupal 8 provides a much more granular ability to cache specific components than its predecessors. And as we know in the high-performance web world, cache is king. When Drupal 8 first came out, a leading Acquia engineer showed some mixed results on Drupal 8 performance. The heavier codebase invariably means having to swim upstream to make it outperform the lighter codebase in Drupal 7, but I’m happy to say the architects had their flippers on when working through these challenges. Take these two fundamental points:

  1. Regardless of how fast the underlying code executes, what matters to users is perceived performance, i.e. how long they have to wait to interact with the page. Perceived delay has been drastically reduced by an experimental-turned-core module (more on that later) called BigPipe. BigPipe loads components of a page in the order in which a user is expected to interact with them while delivering more expensive components as they’re available. This breaks with the tradition of all-or-nothing webpages served by Drupal that were either in the cache or not, lending itself to a Facebook-like experience, which is where BigPipe came from.

    GIF of Drupal 8 BigPipe Video
    Slower video here

  2. Modern performance tactics derive the largest gains from outside of the application leveraging services like a Content Delivery Network (CDN), and/or a web application accelerator, like Varnish, to serve up resources to anonymous traffic (users not signed-in) as quickly as possible. For most sites, anonymous traffic comprises a majority of overall traffic. Traditionally, there have been limitations to improving performance for authenticated traffic, and that’s where Drupal 8 shines. With BigPipe and a more granular caching system, Drupal 8 can substantially outperform Drupal 7’s authenticated user experience, so it’s a win-win.

If you’re made of time today, check out our other articles we’ve written about performance for a deeper dive into this broad and complex topic.

WIIFM? People.

We know that behind any powerful movement are powerful people. To quote Dries, as I did in my Drupalcon talk in New Orleans:

fostering the Drupal community is actually more important than just managing the code base.

Also, atop the Drupal.org homepage used to read

Come for the code, stay for the community.

Without needing to resonate with all the warm and fuzzies that many within the community do, these sentiments show the richness and value of the Drupal community. And that rich community, not out of neglect, but rather necessity, has moved on from Drupal 7. Top designers, developers, and strategists are working on few Drupal 7 projects these days, and most would prefer to move on. For those who work with web designers and engineers (or used to be one like me), you know that they often have an insatiable appetite for learning, and want to do that with increasingly relevant tools to their growth and output. Sticking to dated software is an effective way to weed out the best and brightest.

The Improved Developer Experience (DX) of Drupal 8

Just like happy customers tend to be repeat customers, happier developers also produce returns; they’re more productive.

There are a few improvements in Drupal 8 that make life substantially better for developers. The Configuration Management Initiative was a boon to developers who struggled with a module called “features” which was not designed to do what most of us used it for. The CMI addresses the previous workaround, rife with inconsistencies, of moving site configuration from development to staging and production environments. Although it may seem trivial, developers love this better system in Drupal 8, and it means more efficient development, therefore higher ROI.

Proudly found elsewhere / not invented here / getting off the island

A primary Drupal 8 philosophy that has largely been successful, but yet to fully bear fruit, is the concept to drastically reduce “Drupalisms” that had proven a challenge for newcomers to the system who had to learn a suite of things specific to only Drupal. The proudly found elsewhere paradigm seeks to mitigate this by leveraging the best of other open source tools when possible rather than reinvent the wheel. A few of the tools Drupal 8 now exploits are Symfony components, Twig templating engine, and Composer Dependency Manager. This “borrowing” has two positive consequences: 1) it reduces the workload for Drupal core contributors by utilizing what’s freely available and well vetted through other communities, 2) it allows people familiar with those other frameworks a smoother onramp to productivity in Drupal. I believe we haven’t yet seen a majority of the benefit to the Drupal 8 project from the many people who were already versed in Symfony and TWIG before working with Drupal.

To quote Angie Byron for the thousandth time (full video here):

For people who are classically trained or have experience in other languages, Drupal 8 is going to make a lot more sense to them than Drupal 7 did. We’re just falling more in line with what the larger people are doing… within the broader PHP community.

WIIFM? Cost savings.

The active decision to upgrade or passive indecision to wait both have cost implications. Perhaps this is the most useful section for readers whose primary responsibilities aren’t technical.

Continuing to invest in Drupal 7 (or earlier) can be costly in ways that may not be abundantly apparent on the surface. For most organizations who work with an agency, custom development is where a brunt of the efforts are spent, and therefore is the primary cost driver. “Custom development” occurs when the functionality a client requests is either not freely available on the open-source market or the agency is unaware of its existence and a developer will write code for the specific use case to “extend” the out-of-the-box functionality. The 80-20 rule applies well to software development in Drupal: roughly 20% of the functionality a client requests accounts for 80% of the effort of a project since that 20% must be built from scratch. When site owners request various functionality, it can be difficult for them to differentiate what may constitute custom development efforts vs. freely available from the contributed community. Given the high effort of customization and related technical debt accumulated, site owners should request a high degree of transparency to understand what requires custom development when establishing project budgets. This way, the organization can do a cost/benefit analysis on a granular, per-feature basis. The goal for developers should be to always start with exploring what already-made wheels are out there for the turning before crafting their own. Be wary of alternative thinking. Yet, as extensible and rich the Drupal community is, nearly all of our engagements require customization.

Easy Drupal upgrades forever

A happy Drupal sunrise
Image from Dries’s blog post

To the surprise of the community, in an abrupt departure from business-as-usual in early 2017, Dries committed to “easy upgrades forever”, starting with Drupal 8 of course. The short of it is Drupal 8 to 9 upgrades should be far easier (and less expensive) than any previous major version upgrade, and so will be from here on in. That means for those not yet on Drupal 8, you only have one final difficult upgrade left in your Drupal journey until the end of time.

This is a fairly natural outcome given the possibilities afforded by a more structured, object-oriented architecture coupled with the growing desire to ease upgrade pain that has been building for some time. Although difficult technical work is needed to flesh out exactly how this will be done, the commitment from the top is worth putting stock in and the community is on the way to making this grand proclamation a reality. When upgrades are far easier, they will help rectify some of the sentiment of leaving the smaller sites behind, since major version upgrades will be a much less daunting task with Drupal 8 and beyond.

Drupal 6 or 7 custom development is especially expensive

However, perhaps the most important point is that you may be doubling your efforts for the final time if you’re doing custom development on Drupal 6 or 7, since it will invariably need to be rewritten to work on Drupal 8 with the same 80-20 rate we mentioned earlier. Given the commitment to easy upgrades and guidelines for backwards compatibility, it’s quite likely that custom code written for Drupal 8 will be highly portable to Drupal 9 and 10 that won’t require an arduous rewrite.

A Drupal 6 house
Not our actual house, and it’s not this bad.

I live in the equivalent of a Drupal 6 house. My partner and I keep putting off things we’d like to do now in prep for a more substantial renovation “on the horizon.” We’re not going to get solar panels before replacing the roof, and we won’t upgrade to a high energy efficiency HVAC system until we restructure some of the foundation. We’re being mindful of mitigating our overall costs, which makes sense, but this all sets up a perverse incentive to make no improvements in the immediate. The same can be true for an older Drupal site. As she frequently reminds me, I’ll remind you: it’s probably time to take the plunge and build your Drupal 8 house.

Cost to upgrade is going down

While there remains one final decidedly not easy upgrade if you’re not yet on Drupal 8, the good news is the cost to upgrade has gone down and will continue to. As of the release of 8.4.0, migrating from Drupal 6 is nearly all the way there:

Core provides migrations for most Drupal 6 data and can be used for migrating Drupal 6 sites to Drupal 8, and the Drupal 6 to 8 migration path is nearing beta stability.

The sentiment on 7, expectedly so, is not as far along:

The Drupal 7 to Drupal 8 migration is incomplete but is suitable for developers who would like to help improve the migration and can be used to test upgrades especially for simple Drupal 7 sites. Most high-priority migrations are available.

So migration from 7 still requires some work. More on this ahead.

Early adopters paved the way

We all owe a debt of gratitude to those who were willing to take the risk of building on Drupal 8 in its earlier days. We commend both organizations and agencies who were ambitious and willing to incur some risk to help push the rest of the project forward. We’re proud to put ourselves on that list, starting 2.5 years ago, but it unsurprisingly came with challenges and lessons learned. Mistakes that come with experience are virtually entirely positive for the future since we’ve learned what to do and what to avoid. It’s time for you to benefit from the work of the early adopters.

WIIFM? The Future.

The future is uncertain; the only things guaranteed are death and taxes. Actually, even those I’m not so sure :wink: Regardless, the future for Drupal 6 and 7 are a known entity not likely to get much better. The upside of Drupal 8, while partially known, is largely still in the making and will keep getting better over time.

Continuous innovation with experimental modules! Who doesn’t want that?

Among the suite of other firsts, Drupal 8 has updated its minor version approach to accommodate for innovations in core and this is another game changer. Previously, the first version of Drupal 7 (7.0) was essentially functionally the same as the latest (currently 7.56). Now new minor releases introduce experimental modules which are driven by agreed-upon priorities and are then vetted over time to see if they’ll graduate from the “experimental” label and be fully baked into core. Therefore Drupal 8 can and will adapt; Drupal 7 cannot. The transparent structure leadership established provides a good balance of innovation and predictability with two minor version releases a year. To track these for your own planning, at any time you can check the development roadmap.

Javascript

The Drupal community has been abuzz with “headless” or “decoupled” Drupal since the advent of Drupal 8. The basic idea is that Drupal can lean on its strength of being an excellent tool for highly structured and organized data in the backend while allowing freedom and flexibility of choice on the presentation layer (front end). Though discussed two years ago to no formal conclusion, Dries has recently cited React as the go-to presentation layer for Drupal administrative interfaces come early 2018. This is a fairly big deal, and formally moving forward to more tightly link with React has many implications we haven’t yet fully explored. As the lines between websites and web applications continue to blur, this proudly-found-elsewhere addition may prove to be a powerful one that will not be possible for Drupal 6 or 7. We see this as another wise move to be more in-sync with the rapidly growing impact of JS frameworks.

Access to complementary tools

The re-architecture towards object-orientation helped Drupal join the modern PHP community’s framework (Symfony, Laravel, Cake, Phalcon, Zend, Slim, CodeIgniter, Yii, and Fuel to name the most popular) development practices. One subtle yet substantial value to that move is now many tools that are built to help support these other frameworks are available to Drupal as well. As the toolkit for modern web development grows richer and more robust, the more Drupal can utilize, the better. A couple examples we’ve recently used to help inform project quality and future maintenance costs are Code Climate and Scrutinizer. These tools have much less value analyzing a Drupal 6 or 7 site.

Our advice

So we’ve dumped a lot of information on you at this point, but it may still not be entirely clear what you should do with your outdated Drupal site. Ahead we provide general suggestions as well as what is pertinent to site owners for each version separately (Drupal 6 and 7).

To everyone on Drupal <8

We still have <3 for Drupal <8. Drupal 5, 6, and 7 got us to where we are. But here’s what we think you should consider about where you’re going.

  1. Plan 3 years out if possible. A stitch in time saves nine, and every minute of planning saves 10 in execution. They’re clichés, but true. Planning well requires a real dedication to strategic and investigative work; there’s no way around it. The upside is it allows you to be intentional about when to incorporate an upgrade, rather than being at the mercy of expiring security support. Organizational stakeholders are usually not compelled by upgrading for the sake of upgrading without other bells and whistles that come with it. An experienced partner can help shepherd the long-term planning process to provide guidance on efforts and things to consider. If you’re not working with an agency, do it yourself. Expect to redesign and do a software upgrade every 3-5 years and time those together if possible. Factor in upgrades to other systems that integrate with your website as well as any initiatives that may require functional improvements. Put all of these larger investments on a roadmap with a timeline and be clear about what components are dependent on or impacted by other components. With technical work, the devil is in the details, so a thorough assessment or “discovery project” is usually the best next step. Discovery work is light on upfront investment yet thorough enough to guide your organization through the many choices in your roadmap. This is really the best way to use your resources most efficiently. If your organization hasn’t historically done this, it handicaps you a bit at the moment, but if you’ll excuse one final cliché: there’s no time like the present.
  2. Be mindful of what you don’t need. We all get excited about the possibilities of new functionality. However, when things we’ve built have outlived their purpose, let them go. Given the complexity and interdependence of the tools we build, customizations take the form of mounting, insidious and potentially crippling technical debt if left unaddressed. The cost to upgrade the technical debt is likely the major cause for most of those who have not yet upgraded; it is certainly the case for all of our partners who haven’t. This debt can be hard to track, and it’s not something most agencies proactively share since they have a hand in creating it and can also be shortsighted. Ask for answers as to how your partner is managing your technical debt. If you don’t get good answers, keep asking. Another subset of this concept is that even if you want to maintain certain functionality, it needn’t be done in the with the same modules on the Drupal 8 platform. So don’t take a given module’s absence in Drupal 8 as a certainty that it cannot be efficiently achieved in Drupal 8. In many cases, it can.
  3. Training will be required. If you plan to build with the same team that built your <8 site, and they have not worked on any other Drupal 8 or object-oriented PHP projects, make sure you dedicate time and budget resources for substantial training.

To those with production Drupal 6 sites.

I wrote a Drupal 6 series as Drupal 8 had announced its release (the overview, the risks, the options, Drupal 7 or 8) which is a good reference for both what was true then and what has changed now. Then, I certainly encouraged a conversation with your partner about what is right for you. That has not changed. What has changed is the maturity of the migration system, making it easier to port your content from 6 to 8. An upgrade to Drupal 8 by way of migration should be where you start based on all of the above, and the job before committing to that path is to well vet all requirements to migrate. Given that migrations are high-effort, you should explore alternatives with your development team. How much it’s worth to invest in a migration depends on how valuable your old content is to preserve, which varies widely among organizations.

If through research you uncover that you’re still not ready for Drupal 8, you should make an action plan to follow up on the components that will allow you to upgrade to Drupal 8 and track those over time. You should look into efforts to upgrade to Drupal 7, being mindful of how you can mitigate the costs to the Drupal 8 upgrade. You should consider support with the MyDropWizard team in the immediate. It’s lead by David Snopek who is on the core security team and has an impressive Drupal resume. It’s hard to assess how the support provided by MDW compares to the core security team, but it’s much better than not having any security support. I would also caution those to not use the relief from having coverage through MDW as a reason to rest on your laurels. If Drupal is still working for you, you should be thinking about how to get to Drupal 8. Additionally, as we agreed earlier there’s no longer even certainty to death and taxes, it’s possible that things could change for MDW, and you’d be without support again.

To those with production Drupal 7 sites.

As far as building new on Drupal 7, I have a hard time conceptualizing for whom that is the right choice. MDW wants to keep the door open to building new in Drupal 7, but others point out incentives again. Much like the hat tip to Dries for accepting criticism, I must commend MDW accepting these comments on their blog.

If you have a high degree of customization and technical debt, keep track of the development of Drupal 9. Upgrade now cannot be prescriptive for the 900,000+ sites still on Drupal 7. We generally agree with Angie’s recent presentation at Acquia Engage called Drupal 9 and Backwards Compatibility: Why now is the time to upgrade to Drupal 8 for those on Drupal 7:

If it’s working for you that’s fine! (Until Drupal 9) But if D8 offers features you want, consider earlier adoption.

So, if you’ve determined that you’ll remain on Drupal 7 for some time, your development team should be aware of a couple Drupal modules (xautoload and service_container) that make writing Drupal-8 like code possible in Drupal 7. These tools will help familiarize developers with Drupal 8 paradigms and possibly reduce substantial technical debt in the future.

To those not on Drupal, but considering it

If you’re in the market for a CMS and have ambitious web goals, you should at least check out Drupal. It’s been holding fairly steadily in the CMS market, and given some of the problems of the past with versions before Drupal 8, we think this speaks very promisingly of the future for Drupal. This is not to say that it is the right fit for all websites. It is not. However, with free hosting options, an improved and simplified admin experience, and the most powerful backend of the open source CMSes, it does fit a lot of needs.

We want to hear from you

We want to hear from your experience, whether or not it resonates with what we’ve presented here. Are you having challenges to upgrading that you feel went unaddressed here? Notice anything we overlooked? Comment away, or write us privately if that’s appropriate. I’m also often on Drupal slack (@chrisarusso) checking in on our local #TriDUG meetup conversations.

Nov 07 2017
Nov 07

 

Tax regulations can be ridiculously complicated, particularly in the U.S., but Drupal has your back. With more inclusions and better integrations out of the box, Commerce 2.x represents a significant improvement from Commerce 1.x. Watch this High5 video for details!

Commerce 2.x now includes:

  • Native integration with Avalara
    That means full integration for every region that Avalara handles. Integrations with Tax Cloud and TaxJar are also in the pipeline, so U.S.-based businesses will have a few different options.
  • Built-in tax rules for Canada and the EU (and more)
    These are now included right out of the box; no add-ons or third-party service required. As long as you stay up to date with your Commerce install, you will automatically get any new rules or changes. And if you sell to other countries, you can still build the tax rules and configure them yourself.
  • The ability to prescribe when a tax applies
    Besides being able to set what products a tax applies to and in what regions, you can now select when it applies. So if a tax rule is set to come into effect on January 1st, for instance, you can set that up way in advance and not have to be up at dawn on the big day to push a button. This functionality is also key when it comes to redoing old orders that were done under a different tax scheme.
As always, if you have questions about getting your site setup on Drupal Commerce 2, let us know! We'd love to help.
Nov 01 2017
Jay
Nov 01

drupal-upgrade-crisis.jpg

The Drupal Upgrade Crisis is Over

Back in March 2017, Dries Buytaert, the creator of Drupal, published a blog post entitled "Making Drupal upgrades easy forever" in which he confirmed what we here at Ashday had already suspected: Drupal 8 has laid the groundwork for seamless upgrades to future Drupal versions. But what exactly does that mean, and what benefits could this have for your website?

The Dark Age of Upgrades

Prior to the release of Drupal 8, Drupal releases broadly followed a policy that included minor releases and major releases. Minor releases (such as upgrading from Drupal 7.18 to 7.19) were usually fairly simple updates. They would fix bugs, add in some small new features, and resolve security issues, but ultimately, it was rare for a minor update to cause any problems for a well-built Drupal site.

However, major releases (such as upgrading from Drupal 6 to 7) were a whole 'nother matter; they're basically different systems entirely.. Standard policy with major updates was that most anything that needed to be changed could be, even if doing so would make it impossible to seamlessly update a site from one version to the next. For instance, Drupal 6 included a feature by default that allowed each of a site's users to select what theme they saw the site in (changing the site's overall look and feel). In practice, not many sites made use of this feature, so it was removed in Drupal 7 so that developers could focus on the more frequently-used parts of Drupal. Of course, if a site used this feature, it couldn't be upgraded to Drupal 7 without either losing that functionality or having new development done to add a replacement. The Drupal way to make progress was to not tie the potential of the future to the decisions of the past.

What this has lead to, however, is that oftentimes, once a site has been built on one version of Drupal, it doesn't get upgraded to the next version without good reason. In fact, there are many sites still out there running on Drupal 6 simply because upgrading to Drupal 8 would be too expensive and time-intensive of a process.

Fortunately, the dark age of upgrades may be at an end.

Enter: Drupal 8

When Drupal 8 was released, the paradigm shifted. Drupal 8 is very different from Drupal 7 (even more so than 7 was from 6), and so upgrading a site to Drupal 8 presents many of the same difficulties as upgrades in the past. But, thanks to the hard work of the Drupal developers and everyone else involved in the project, future upgrades should be much simpler. Drupal 8's code has been written to make good use of web development standards in ways that past versions never even tried. Because of this, Drupal 8 is fundamentally a foundation that can be built on by future versions without needing a complete overhaul.

What that means is that any site which is kept up to date as minor releases come out should continue to work on Drupal 9 with minimal effort needed to upgrade it. Instead of everything changing at once like it did going from Drupal 7 to Drupal 8, old code and little-used features can be phased out slowly as better alternatives are developed and implemented.

And that leads us to the final result of this change of approach: Prior to Drupal 8, a site could be built and then be minimally maintained with security updates until the next version of Drupal came out, at which point it had to be rebuilt entirely. Now, a Drupal 8 site can be built, and if it is minimally maintained until Drupal 9, there might be a few adjustments needed to remove deprecated features, but there will certainly be fewer than in the old way. But what's more, if that Drupal 8 site is actively maintained, it may not even be using any deprecated features at all by the time Drupal 9 comes out, allowing that upgrade to be made with ease.

What Does This All Mean for You?

From a technical perspective, these are all great changes, but what does it actually mean for your website? Several things:

If you are on an older version of Drupal: Now is the time to upgrade. Upgrading from 6 is long overdue (it doesn't even get official security updates anymore!), but upgrading from 7 makes sense now as well. Before Drupal 8, it was common to skip versions… for instance, a Drupal 5 site would skip Drupal 6 entirely and get rebuilt on Drupal 7. But upgrading a Drupal 7 site to 9 shouldn't really be too different from upgrading it to 8… so, why wait? Upgrading now will help avoid any last-minute scrambling to update the site when Drupal 7 eventually stops getting security updates.

From a business and marketing standpoint, there's another hidden advantage as well. Before, redesigning a website often got tied to the need to upgrade Drupal. There wasn't much reason to do a big redesign, if you'd have to upgrade from one major release of Drupal to another just a year later, so the changes would get bundled together to avoid having to do two rebuilds. But what's more, taking on all the concerns of a site redesign alongside the technological challenges of a Drupal upgrade could make doing both at once a challenging task in itself.

Once your site is on Drupal 8, major releases should no longer require rebuilding the site… which frees up your Drupal developers to be able to do a redesign whenever it makes sense to from a branding or business perspective. Drupal 8 gives you the power to decide when a website overhaul should be done, rather than tying such upgrades to the technology the site happens to be built with.

Offer for a free consultation with an Ashday expert

Nov 01 2017
Nov 01


Lots of live Commerce 2 sites were actively and successfully selling products to people long before the official launch on September 20th. We ourselves were among the early adopters taking advantage of the new functionality available in Drupal 8. But as with any new-and-not-fully-tested technology, there were the inevitable growing pains: missing functionality, bugs, etc. Fortunately, most of those issues are now in the past.

A few core modules that were buggy but are solid now:

  • Promotions and coupons
  • Taxes
  • Payments (supports 30+ payment gateways!)
  • Products
  • Orders

As an added bonus, the Commerce Shipping module that Acro Media helped develop received a full stable release alongside Commerce 2 (which is especially cool when you remember that Commerce 1 launched with no shipping functionality at all). Commerce Shipping features a much improved API and includes support for UPS and FedEx, with USPS to follow shortly.

Acro Media and other community members have been working on a few other associated modules to go along with the Commerce 2 launch. Here are the details:

  • Point of Sale is going to alpha release
  • Commerce Migrate is going to have a new release (likely not a stable release, however, as there is still work to be done migrating edge cases)

    Ubercart to Commerce 2 migrate is mostly done and includes all core stuff like products, customers, orders, taxes, etc.

    Commerce 1 to Commerce 2 migrate is a little rough but is still very usable; an improved version should be ready in October sometime

A cool new Composer based Commerce Kickstart installer is also available! It represents a great improvement over the original Commerce Kickstart and should be easier for everyone to use. You can find that here.

TLDR: The fully supported, stable release of Commerce 2 is live and has lots of cool stuff with it. If you were hesitant to use it to build sites before, you most certainly can go ahead now.

Nov 01 2017
Nov 01
1 November 2017

Yesterday a project on github was moved, causing Drupal’s own build process, and that of many other websites, to “break”. Here’s what happened:

  1. The coder library was removed from github (it’s main home is on drupal.org).
  2. Drupal core’s composer.json had a reference to the now non-existent repository.
  3. Anyone attempting to obtain Drupal by downloading it’s source and running composer install couldn’t, due to the broken link.
  4. Many other developers who tried to build their websites were similarly left disappointed.

This issue on drupal.org captures the problem in more detail.

We’ve been here before

In March 2016 a JavaScript library called left-pad was removed from the npm package manager, causing the builds of many front-end projects that used it to break.

This seems to be a risk that comes with dependency management, and raises the question of should vendor be committed to version control? I’m hoping that this post will help you answer that.

Notice that I’m only talking about full applications or website codebases here, not libraries. If you’re working on some sort of standalone component for use within a larger project (like a contrib module), you definitely don’t want to ship vendor to your users. Nor do you want to include composer.lock.

A lean codebase

The keep-vendor-outside-git argument favours a lean codebase. There’s some merit to this. After all, upgrading a module is often considered a single, atomic change, and it’s nice when a pull request of the form “Upgrade the EVA module to 1.2” comes down to a single line:

diff --git a/composer.lock b/composer.lock
index 378e3be3fa..8f6d7d31a9 100644
--- a/composer.lock
+++ b/composer.lock
@@ -637,17 +637,17 @@
         },
         {
             "name": "drupal/eva",
-            "version": "1.1.0"
+            "version": "1.2.0"
         },

It’s not hard to cross reference that with a changelog in the other project, should you need to. And by downloading the code each time prevents you from modifying a module without auditing it. Every patches is explicitly listed.

It’s interesting that composer’s own documentation recommends this approach.

Resilience

The commit-vendor-to-git argument focuses on resilience. You don’t want your build process to be dependent on external services that may or may not be available. Furthermore, you want to be able to track all changes to your source code in one place, both the bespoke code and any other libraries.

Pascal Morin articulates this well here: Do you really need composer in production? The CocoaPods dependency manager for iOS also leans towards this position.

Can we have our cake and eat it?

We’re looking at two objectives - the resilience of not being dependent on packagist/github/drupal.org for building, plus the advantages that come with a lean codebase. By trying to achieve both, are we trying to have our cake and eat it?

In an ideal world, each project would have some kind of artefact repository. One that’s under your control and from where you can obtain every library/version combination you’ve ever used in the project. This is what Maven, a Java dependency management tool, suggests.

Do I think the core Drupal repository should contain a vendor directory? No, I don’t. I think it’s Drupal’s job to be a component, augmented with contributed modules and perhaps custom code. Every Drupal website is different; as soon as you add a contributed module the contents of vendor change.

But unless you have the resources to manage an artefact repository, your website’s repository probably should contain vendor. You can still have the benefits that composer brings, but why introduce another point of failure at build time?

Notes

Oct 27 2017
Oct 27

Drupal 8’s official release was nearly two years ago, and many ask how is it doing? Has it lived up to its ambition to revolutionize Drupal websites?

In the first of a two-part series, we’ll provide our insight into the evolution of Drupal 8 over its first two years in the wild. In part two, we’ll look at important factors to consider in your Drupal investments going forward.

(Drupal) Change is hard

To launch a website (much like to rock a rhyme that’s right on time) is tricky; to operate a web system in a way that uplifts your organization is just plain hard. Although keeping up with the most current software is typically advisable, there are costs to doing so, even for free software like Drupal. Without the vendor lock-in that comes with proprietary Content Management Systems, Drupal site owners have a high degree of freedom to consider how best to invest their web resources. However, this freedom also has a price (see a pattern emerging?) in the form of time and stress incurred from the responsibility to select the best digital tools to drive your organization for years with limited information to evaluate the nearly limitless options.

Of the 1 million+ organizations whose main window to the digital world is powered by Drupal, many have priorities that compete in time and budget with web system investments. When considering these priorities, determining the right time to invest in an improved user experience, design, feature-set, or software upgrade can be difficult.

With the ever-increasing complexity and interconnectedness of the software systems we build, even the world’s most prominent organizations, often with legions of engineers, have had colossal mishaps with upgrades. By default, upgrades are not easy.

To upgrade or not? That is the question.

Like any decision, whether you’re building new or upgrading, the fundamental question is: do the benefits outweigh the costs? In the specific case of investing in Drupal the question becomes: when does making the leap to Drupal 8 rather than continuing to invest in Drupal 7 (or possibly 6… don’t tell me it’s 5 :wink: ) outweigh the costs to take that leap? For any organization to properly answer that question, it’s necessary to look 3-5 years out with regard to budget and organizational goals. It’s also helpful to better understand how the broader community has approached this same decision over the past two years. Let’s take a look.

Taking stock of Drupal 8’s adoption

stock market image

After nearly two years since its public release, how has the adoption of Drupal 8 gone?

Analysis from the top

Before DrupalCon North America in May 2016 in New Orleans, Drupal founder and current project lead Dries Buytaert blogged that Drupal 8 was doing “outstanding,” citing statistics to substantiate his optimistic view.

Based on my past experience, I am confident that Drupal 8 will be adopted at “full-force” by the end of 2016.

Many in the community contested the veracity of his optimism in the article’s comments and I commended Dries (yes that’s me and not him, and definitely not him) for facilitating an open conversation that elicited a broad perspective.

About a month later, some six months after Drupal 8 was released, Savas Labs attended DrupalCon NOLA.

During the perennial “Driesnote,” Dries continued to present Drupal 8 as well on its way to match if not exceed the success of Drupal 7.

I really truly believe, Drupal 8 will take off. My guess is that by the end of this year [2016] Drupal 8 will serve an escape velocity… it will become the de facto standard.

and

The new architecture, features, as well as frequent releases: all of these things make me feel really, really optimistic and bullish about Drupal 8.

Adoption by the numbers

According to the usage statistics available on the Drupal website, when writing this nearly 80% of the world’s Drupal websites were powered by version 7.

drupal stats d8A graph started by Angie Byron of Acquia that I updated to present.

When Drupal 7 was released on January 5, 2011, there were already more Drupal 7 sites than sites powered by the major version two releases prior: Drupal 5 (A). The same feat for Drupal 8 took over nine months after its release to achieve (C). Total Drupal 7 sites eclipsed total sites of its predecessor version (6) about 13 months after the release of Drupal 7 (B). After nearly 2 years from the release of Drupal 8, it has not yet eclipsed Drupal 7 installations, and at present there are over 700,000 more Drupal 7 sites than Drupal 8.

Our take on Dries’s bullish-ness

To his credit, the future is notoriously difficult to predict, and even when predicting it, Dries spoke of the significant work that lay ahead to see his vision come to fruition. He also made the referenced comments well over a year ago, and I’ll concede speaking in hindsight is infinitely easier. Having said that, comparing the total number of upgraded Drupal 8 sites to Drupal 7 sites over the same period from release in a community that had grown ~220% since Drupal 7’s release, while factually indisputable, was probably not as accurate as using adoption percentages to analyze overall trends.

Even the most conservative interpretations of “escape velocity” or “full-force” would have to concede that we’re at least a year behind Dries’s hopes when he was reporting from DrupalCons Barcelona and New Orleans on impending rapid Drupal 8 adoption. But, what’s a dictator worth his salt to do, benevolent or not, other than to stretch the stats a bit to show what he would like to be true for his beloved community, from which he also profits?

Our assessment

After two years, the data unequivocally show, as I began discussing at DrupalCon New Orleans, the rate of Drupal 8 adoption is objectively slower than Drupal 7. At this point, a majority of organizations have not yet upgraded from 7 to 8, though likely many have begun efforts. Taking a simplistic view, this means Drupal 8 has either been more costly to upgrade, a comparatively less valuable product, or perhaps both.

Regardless, since it matters to our partners, we found it important to explore the reasons behind the slow adoption rather than to pretend it’s not happening. After architecting Drupal 8 web systems for 2.5 years, we have gained insight into the relatively slow adoption.

Drupal 8 adoption challenges

Drupalers haven’t written much about the retrospective analysis of the Drupal 8 adoption challenges. But without being able to take a real, honest look inward, we cannot improve. We must know thyself because the examined Drupal problems are worth fixing! We highlight here the most prominent challenges that have slowed Drupal 8 adoption.

1. Complete code re-architecture

The massive shift of the underpinnings of the Drupal code is a decision that has long been debated within the community. There’s no question it has proven a challenge for proficient Drupal 7 developers to develop on Drupal 8: for most, substantial training and learning is required. Training takes time, and time can often mean money. The loss in short-term efficiency for seasoned Drupal developers made early adoption riskier, and typically added to a project’s expense. Joining with other prominent frameworks known outside of Drupal like Twig and Symfony (colloquially referred to as “getting off the island”) was a collective decision by wise Drupal leadership with the long-term value of the product in mind, but in the short-term, for the average Drupal developer, it meant more new things to learn.

2. Slow contributed module porting

Historically Drupal has derived much of its usefulness from the rich contributed module ecosystem that extends the features of Drupal core. Contributed modules, although crucial to most live Drupal websites, by definition are not directly driven by those that oversee Drupal core development. This disconnect invariably leads to some important modules not having a usable upgraded version when a new major version of Drupal core is released. This is well-known within the Drupal community, explained at great length by Angie Byron (second reference), and not unique to the Drupal 8 release. Tremendous amounts of individual and community efforts are required to upgrade modules to the latest major version. Due to #1 from above, these efforts were further exacerbated by the re-architecture. Costs to upgrade even one module (it’s common for a Drupal 7 site to use 100) are often greater than clients or agencies are willing to absorb on a given project.

3. Incomplete upgrade path

We often describe websites as comprised of three main asset groups: the code (Drupal core, contributed and custom modules), files (think media assets like images), and the database where content and site configuration lives. When upgrading, you download the new Drupal code, which has a set of instructions that must be run to apply complex updates to the database. Files remain unchanged. A well-oiled upgrade process is required to update the content and configuration from the site being upgraded into a format intelligible to the new system. The approach to perform those upgrades has also changed in Drupal 8 to what is now referred to as “a migration”. As of the most recent minor release of Drupal 8 in October states:

…Drupal 6 to 8 migration path is nearing beta stability. Some gaps remain, such as for some internationalization data. The Drupal 7 to Drupal 8 migration is incomplete but is suitable for developers who would like to help improve the migration and can be used to test upgrades especially for simple Drupal 7 sites. Most high-priority migrations are available.

“Nearing beta stability” after two years out from release is not ideal though it is reality since perfecting these migration tasks is hard work. One can discern from the Drupal 7 -> 8 migration snippet that it’s clearly further afield, and for those who need to preserve their content, perhaps a non-starter for a 7 -> 8 upgrade. The inability to efficiently update database structures adds to project expense. Whatever doesn’t come over “for free” with the migration will need to be manually replicated by a human, and humans are costly, as our time is precious.

4. Stance on backwards compatibility

Drupal’s approach to backwards compatibility is famously “for data, not code”. Briefly put, in their words: “While the upgrade path will reliably preserve your data, there is no backward compatibility with the previous Drupal code.” If you want to dig deeper, there’s a lot of good discussion on this topic.

WordPress’s approach, perhaps more than anything, explains its ubiquity and ability to better keep sites on the latest version. In their words:

Major releases add new user features and developer APIs. Though typically a “major” version means you can break backwards compatibility (and indeed, it normally means that you have), WordPress strives to never break backwards compatibility. It’s one of our most important philosophies, and makes updates much easier on users and developers alike.

Albeit a bit confusing, even for the non-technologist, you get the sense they’re more worried about breaking stuff and want upgrades to Just Work™. The strength of the Drupal approach is it allows for more innovation, and in some ways, less baggage since preserving backwards compatibility often means hanging on to outdated code. The trade-off is, once old code is determined to be holding innovation back, it’s cast to the side, and new structures must be implemented in the updated version. Historically, this paradigm has caused many to get stuck in an outdated Drupal version for longer than they’d like because they cannot afford an upgrade.

5. Inertia, perceived value, and expense

A modern organization is focused on more than just their website, and for investments that don’t deliver direct, visual, tangible change, stakeholders often overlook them, even when they may present value. Examples where the value is oft-invisible to clients are investing in an automated testing framework that ensures perpetual site integrity, or vigilantly applying security updates as they become available. In either case, the client may perceive them as optional, but foregoing them is likely to cost the organization in the long-run.

Since Drupal only provides security support for two major versions at a time (presently 7 and 8), for many, the prime motive for a new release, often framed as a mandate, is to upgrade from the version two major releases prior, which has fallen out of support. When Drupal 8 came out, Drupal 6 fell out of support after a grace period of three months, generously extended from the day of release given some of the community’s recognition of some of the challenges we’ve documented here.

If an organization doesn’t heed the security warnings, and doesn’t find enough value in the new features, they may choose to ignore the upgrade completely. The truth is it’s hard to estimate the future risk of using outdated software. However that future risk is very real, and digital security compromises show no signs of slowing down. Savas Labs always advocates for timely security coverage, but it has not always been a budgetary possibility for our partners to upgrade from Drupal 6 to Drupal 8 upon release of 8.

An answer to the Drupal 6 problem

In addition to our experience, the usage data show many organizations did not plan sufficiently to upgrade from Drupal 6 to 7 or 8 upon Drupal 8’s release. Recognizing that, a Drupal agency My Drop Wizard set up long-term security support for the many Drupal 6 sites that were not ready to upgrade to Drupal 8. It’s debatable whether or not this was a good thing for the community. People forced to change, often will change sooner than they would otherwise, but they may resent you for it. Conversely, you’d be hard-pressed to find an MDW client who didn’t experience anxiety relief when offered an inertia-compliant alternative.

Organizations that don’t perceive opportunity in the value the new software provides will look at an upgrade strictly as an expense to avoid, likely citing topics we’ve covered here.

Takeaways

Through experience and analysis, we see there are many understandable and justifiable reasons why many organizations haven’t yet upgraded to Drupal 8. Now that we’ve done the hard reflection, the good news is that the present is a much brighter place for not only Drupal 8 but all future versions of Drupal. We have made it through most of the difficult growing pains, and there’s great reason to believe that the community has invested wisely in the future. In part two, we cover the costs of investing in Drupal 7, and why it’s probably time to move to Drupal 8.

Oct 26 2017
Oct 26
October 26th, 2017

Welcome to the third episode in our video series for Emulsify 2.x. Emulsify 2.x is a new release that embodies our commitment to component-driven design within Drupal. We’ve added Composer and Drush support, as well as open-source Twig functions and many other changes to increase ease-of-use.

In this video, we’re going to teach you how Emulsify works with the BEM Twig extension. This blog post accompanies a tutorial video, embedded at the end of this post.

Background

In Emulsify 2.x, we have enhanced our support for BEM in Drupal by creating the BEM Twig extension. The BEM Twig extension makes it easy to deliver classes to both Pattern Lab and Drupal while using Drupal’s Attributes object. It also has the benefit of simplifying our syntax greatly. See the code below.

Emulsify 1.x:

{% set paragraph_base_class_var = paragraph_base_class|default('paragraph') %} {% set paragraph_modifiers = ['large', 'red'] %} <p class="{{ paragraph_base_class_var }}{% for modifier in paragraph_modifiers %} {{ paragraph_base_class_var }}--{{ modifier }}{% endfor %}{% if paragraph_blockname %} {{ paragraph_blockname }}__{{ paragraph_base_class_var }}{% endif %}"> {% block paragraph_content %} {{ paragraph_content }} {% endblock %} </p> {%setparagraph_base_class_var=paragraph_base_class|default('paragraph')%}{%setparagraph_modifiers=['large','red']%}<pclass="{{ paragraph_base_class_var }}{% for modifier in paragraph_modifiers %} {{ paragraph_base_class_var }}--{{ modifier }}{% endfor %}{% if paragraph_blockname %} {{ paragraph_blockname }}__{{ paragraph_base_class_var }}{% endif %}">  {%blockparagraph_content%}    {{paragraph_content }}  {%endblock%}

Emulsify 2.x:

<p {{ bem('paragraph', ['large', 'red']) }}> {% block paragraph_content %} {{ paragraph_content }} {% endblock %} </p> <p{{bem('paragraph',['large','red'])}}>  {%blockparagraph_content%}    {{paragraph_content }}  {%endblock%}

In both Pattern Lab and Drupal, this function above will create p class=”paragraph paragraph--large paragraph--red”, but in Drupal it will use the equivalent of p{{ attributes.addClass('paragraph paragraph--large paragraph--red') }}, appending these classes to whatever classes core or other plugins provide as well. Simpler syntax + Drupal Attributes support!

We have released the BEM Twig function open source under the Drupal Pattern Lab initiative. It is in Emulsify 2.x by default, but we wanted other projects to be able to benefit from it as well.

Usage

The BEM Twig function accepts four arguments, only one of which is required.

Simple block name:
h1 {{ bem('title') }}

In Drupal and Pattern Lab, this will print:

h1 class="title"

Block with modifiers (optional array allowing multiple modifiers):

h1 {{ bem('title', ['small', 'red']) }}

This creates:

h1 class="title title--small title--red"

Element with modifiers and block name (optional):

h1 {{ bem('title', ['small', 'red'], 'card') }}

This creates:

h1 class="card__title card__title--small card__title--red"

Element with block name, but no modifiers (optional):

h1 {{ bem('title', '', 'card') }}

This creates:

h1 class="card__title"

Element with modifiers, block name and extra classes (optional, in case you need non-BEM classes):

h1 {{ bem('title', ['small', 'red'], 'card', ['js-click', 'something-else']) }}

This creates:

h1 class="card__title card__title--small card__title--red js-click something-else"

Element with extra classes only (optional):

h1 {{ bem('title', '', '', ['js-click']) }}

This creates:

h1 class="title js-click"

Ba da BEM, Ba da boom

With the new BEM Twig extension that we’ve added to Emulsify 2.x, you can easily deliver classes to Pattern Lab and Drupal, while keeping a nice, simple syntax. Thanks for following along! Make sure you check out the other posts in this series and their video tutorials as well!

[embedded content]

Thanks for following our Emulsify 2.x tutorials. Miss a post? Read the full series is 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| Pt 5: Building a Full Site Header in Drupal

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.

Oct 26 2017
Oct 26


The good news is that Commerce 2.x has the potential to handle tons of different reports and display the data any way you want. The dashboard is complete and the framework is impressive. The catch is that many of the reports don’t technically exist yet, so you need to do a little configuring to make sure you’re looking at the data that’s most important to you.

What kind of reports are we talking about?

You could have a whole suite of point-of-sale reports, for instance (in Commerce 1, they were their own set of reports; in Commerce 2, they just build on Commerce reporting). If you need reports for checkout, or cart, or analytics, you can have them all in the Commerce reporting suite, even if they are vastly different types of reports. So you can have reports for different people who manage different metrics, but you can build them all using the same framework.

How does this work in terms of configuration?

Some stuff can be built through views. We also use a Twig templating system now, which is not quite as easy to use but is a lot more robust if you want to build more complex reports, because it allows you to do the full templating and theming. It’s like if you’re building a Drupal site: you might configure stuff in the back end or you might build your own theme (or some combination of the two). Reports work the same way.

That means we have more flexibility than we had in Commerce 1, which mostly handled reports through views. Using views can work, but you can run into performance and flexibility issues with complex data (like if you have two million orders that you’re trying to run reports on).

What can we expect from the production release of Commerce 2.x?

It’s important to note that production and reporting don’t actually have the same release schedule because Commerce reporting is an add-on module. So when Commerce 2.0 releases, all the data will be tracked, and there will be some reporting you can do, but the suite of reports that come with the production release will be a little thin initially.

The bottom line: reports are a lot more flexible than they used to be.

To learn more, check out our High Five episode “Drupal Commerce 2.x.: Reporting and Analytics.

Subscribe to our YouTube Channel for more Drupal Commerce goodness!

Oct 24 2017
Oct 24

Two weeks ago we published our first post to introduce ourselves to the Drupal community. Today we are back with the latest updates and also with several calls to action to everyone in the Drupal community. From the very beginning we stated that this is an event organised by the Drupal community, for the Drupal community, and this is a great opportunity to get involved.

Photo credits: Michael Cannon

A lot has happened in the past week. Here is an overview of the highlights we achieved since our last official communication;

In the meantime there are also a lot of behind the scenes tasks that we keep working on to make sure that Drupal Europe 2018 will actually happen. Here’s an overview of what we are currently working on:

  • Defining our internal roles & the leadership team.
  • Design branding materials.
  • Explore event ticketing systems.
  • Exploring payment gateways.
  • Investigating feasibility of using Kickstarter
  • Developing best-practices and various administrational templates which can be reused in the future.

Call for venues

No website or payment gateway will make the event happen alone though. The biggest outstanding question about Drupal Europe is location and timing and we need your help in moving forward on that.

Currently we are collecting data about possible venues in Europe. Is there a possible venue in your country that you could think of? Would you like to invite the Drupal community to your hometown? Let us know by simply answering several questions about the venue.

The more detail there is in the proposal the better we can compare the options.

We are not expecting you to organise the entire conference by yourselves or your local community, we are just looking for venues where our organisation could host Drupal Europe.

Currently we are aiming for a date between the end of August and the beginning of September 2018. We are planning to have the conference from Thursday to Saturday where we will have a sprint room, different session rooms, an exhibition hall for sponsors and the possibility to have our own catering services. Before the actual conference we will be hosting summits and optional two days of training beforehand.

Call for Swag

Drupal enthusiasts like their swag, and so do we. We thought it would be fun to put some creative minds on designing t-shirts, mugs and other cool swag that are all related to Drupal Europe 2018. We would love to see you involved!

Call for Designers

We’d love to have a lasting brand that does not need to be reinvented again if the event ever happens again in the future. So if you are, or if you know, a creative person or company who wants to contribute this and add “Designed the branding for Drupal Europe 2018” to their resume or portfolio, please do let us know via Twitter

Oct 23 2017
Oct 23

Drupal sometimes gets a bad rap for being overly complex, but aren't your site needs also complex? If they aren't, you can stop reading here, skip over WordPress and go straight to Squarespace. If Squarespace can’t cover all your needs, keep reading.

Okay, if you are still reading, then you have complex web needs. The good news is that Drupal has you covered. But simply saying your web needs are complex is too generic, so let's break it down and see how Drupal deals with different kinds of complex needs.

Do you have a lot of content?

Drupal doesn’t care how much content you have. With its out-of-the-box tools, Drupal gives you a nigh-infinite number of ways to organize and manage your content. 

The built-in, customizable admin tools allow you to have large amounts of content in an easy to use management system. On the frontend, a well-executed content driven design will give your users a great experience even if you have hundreds or thousands of pages to navigate. Having a good Drupal partner is the key to establishing a content plan on both the backend and frontend. 

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

What does your content look like?

People tend to think of content as being pages on a website, but this isn't quite accurate. Most websites have pages that are part static and part dynamic. Consider, for example, Amazon.com. Very few of the “pages” on Amazon.com are set in stone; instead, most of them are result of a search combined with filtering to show the user lots of individual pieces of content in a single view.

Instead of thinking of entire pages as pieces of content, let's break it down further. Content is:

  • Text
  • Images
  • Files
  • Products
  • Items
  • Locations
  • Data Points
  • People

The list goes on. Drupal doesn’t care how you define content, it simply gives you the tools to define it in any way you need to. Drupal then takes all of your different types of content and gives you the power to manage and display them together in countless configurations and displays.

For example let's say you have products and locations, each defined as individual pieces of content. Using Drupal, we can display the products that a location stocks on the location’s page and we can also display the locations that a product is available at on the product’s page.

Drupal allows you to publish the details of each type of content in one system and then use and remix that content across multiple pages. You can't do that with a single WYSIWYG (what-you-see-is-what-you-get) field on a page, like you would get with an out-of-the-box WordPress site.

A good Drupal partner can help you define the shape, size, and types of content that your website needs.

Do you have users on your site?

Having users on your site is always going to crank up the complexity of the site. Fortunately, Drupal is built to deal with support for user accounts right out of the box. You can have many types of users by assigning them different roles, and you can have hundreds or thousands of individual users. Drupal handles users much like it does content, with near infinite flexibility. Each user role has its own set of permissions and rules to follow. This allows you to do things like turning user memberships into products, relating users to content, and configuring what your internal team members can do to edit the site content.

Your Drupal partner can help determine what kind of users you need.

Do you want to grow?

Even if your needs aren’t quite as complex as described above, Drupal may still be the right fit, especially if you intend on growing. Drupal is built to scale. Defining types of content and users in your system now will save you from needing to do so in the future.

Your site may be just an idea and a few pages at the moment, but when it's time to grow, don’t let an inflexible website stand in your way. Today you may be selling your goods on a simple website, but tomorrow you may get that big wholesale order that needs to connect with a large datasystem to get product details and specs and even automate reorders.

A good Drupal partner will help build your small site with the foundations to become a big site.

You need Drupal

A good Drupal site is an indispensable business tool, but I would not recommend taking on building an enterprise or complex Drupal site on your own. Having a good Drupal partner is key to a successful Drupal site.

There are a lot of articles out on the web that make the case that Drupal is too hard or complicated. Drupal isn’t hard or complicated for Drupal people... and we are Drupal people. Drupal is complex but that complexity allows us to tailor your Drupal site to match your business.

We will handle the complexity of Drupal, and you can handle the complexity of your business.

Offer for a free consultation to determine if Drupal is the right choice for your organization

Oct 23 2017
Oct 23

What is Decoupling?

Decoupling has been gaining momentum in the past couple years. An increasing number of websites and applications combine their content management system’s backend and editorial capabilities with a separate framework that renders the front end. 

The idea is to make data available in a different format (usually JSON) so the framework can parse it, and so the developer can take full control of the markup, UI, routing, etc. While it’s not ideal for certain types of sites (if you have a lot of pages for instance), it becomes very handy when dealing with single page applications or projects that require a lot of user interaction.

I recently attended Decoupled Dev Days in New York City. This two day event was a way to gather a small portion of the Drupal community (and others) for an in-depth look at the work many people are putting toward making Drupal an attractive backend for a decoupled app. Guest speakers were also main contributors for Angular.js and Ember.js, which was beneficial; the goal was not to make another Drupal centric conference, but rather to attract a broader audience within the tech community.

It was a great opportunity to see the community at work and to get insights about implementation, performance, tools, and more while working on a decoupled app myself.

Two sessions were presenting what we would call Drupal install profiles - basically starter kits for a Drupal 8 decoupled project. Contenta and Reservoir both aim to get your Drupal install ready for beheading. They are also both quite opinionated in what they keep and remove from a regular install. I’d recommend reading this comparison article to learn more. Let’s keep in mind that these projects are in constant development and the early writing about them may not reflect some of the latest development phases.

Now An Then

Our team started working on a decoupled project for NowAnThen.com a few months ago. This site, a product of Wonderful Machine, is aimed towards engaging photographers, genealogists (amateur and expert!), and educators in creating timelines of their own images or of photos uploaded throughout the site. Users add the photos to their personalized timelines to create another medium for visual storytelling. Some timelines have only a few photos while others (such as the Global Timeline found on the home page) will have a vast amount of images attached to it. No matter what, the images should be able to load smoothly onto the timeline in order to create a seamless history viewing experience.

Now An Then

When we first heard the pitch for this site, we were immediately intrigued and up for the challenge. The site is essentially based on a scrollable, searchable timeline of images with metadata (caption, linked author etc). We inherited a prototype that was buggy and not scalable. The client wanted a robust solution in order to handle high traffic and offer more features while keeping the performance optimal. A user’s focus should be on the images and content of the site, rather than the site’s shortcomings.

Now An Then

We chose to decouple our own install profile with React for this project. It made perfect sense to just use Drupal for some basic functionality (paging, login and account creation, and obviously all the good backend stuff). Keeping this functionality as simple as possible was essential for this project. We chose to do the routing with Drupal as it seemed to add a lot of extra work with React for no legitimate reason. We basically decoupled the main content region of our theme layer.

I had worked with Angular and Drupal in the past for a simple project (bearangular.zivtech.com) as a way to get some chops, and I found React’s learning curve to be easier. It’s quite subjective, but I felt the level of abstraction was higher with Angular, making my understanding of the Javascript’s “behind the scenes” much more difficult.

My co-worker had already set up the app and made the Drupal data available to React through a custom module that passed the data through the Drupal.settings API. I didn’t have much to do to get up to speed with some of the syntax and JSX custom elements - everything was pretty straight forward. I had to brush up my ES6 skills and after doing a lot of jQuery, I actually really enjoyed jumping back into vanilla JS.

We used webPack to compile the JS and went through the usual npm workflow. Module installations were super simple, which was a nice change from the Drupal module world. It was all fun and games until we had to optimize for performance. We were building something that had not been done before and it required some serious brain twisting.

The homepage is a timeline of all images on the site, and this is where things got interesting. We needed to imagine a scenario with, say, a timeline of one million images. As we are dealing with overflown content, it seemed clear we could only load what’s in the viewport, such as an infinite scroll. But it’s not that simple.

We wanted to provide a smooth experience while scrolling, so the regular infinite scroll was not exactly an ideal solution. Instead, we decided to work with subsets of 15 images loaded initially, loading the next subset at a half past scroll in any direction (and unmounting the subset on the further opposite). We also had to have the date scroller respond to the timeline both when dragging it, clicking anywhere on its axis, or on scrolling through the timeline.

In the end, the challenges in this project had less to do with React itself and more to do with problem solving and implementation. React’s abilities excelled for the purpose of this project. It provided a complex solution to be implemented simply within the existing build. We believe decoupling will become an essential part of our development process for projects that have similar needs to NowAnThen.
 

Oct 20 2017
Oct 20

As you might have heard during the closing session of DrupalCon Vienna last week, an initiative is working on organising an event for the European community in order to close the gap between DrupalCon 2017 and DrupalCon 2019. Today, one week after the closing session, we are here with our first official communication and we would like to share our current progress.

The discussions about organising an event in 2018 started when Megan Sanicki started blogging about the future of DrupalCon Europe. Some people within the community felt the need to have a big event in Europe for various reasons:

  1. We want an event which brings together the European Drupal community.
  2. We want to make sure that the European market sees that Drupal as a technology is a strong brand.
  3. We want to prove our community that we can do this conference sustainable and cost effective.

Before DrupalCon

Many people contributed to an even greater amount of opinions on what we do want and don’t want for a conference in 2018, all these opinions and ideas from social media, BoF’s and meetings have been collected in a summary document

During DrupalCon

You must have noticed that the lack of DrupalCon 2018 was the main topic of lots of discussions in Vienna. The discussions already started during the community summit where a group was talking about the future of DrupalCon Europe in general. During the con we had at least 4 BoF’s, people were sprinting on the initiative, people were having meetings with the Drupal Association and even during the social events people started putting their heads together to come up with solid plans for 2018.

Licensed — Image courtesy of Amazee Labs

There were even people who didn’t attend a single session during this DrupalCon so that they could keep working on ensuring that the community could meet next week.

We identified several key requirements from our community and we will do all the necessary in order to address these requirements during the organisation of this conference. Almost everyone agreed to the following statements:

Licensed — Image courtesy of Paul Johnson
  • We want a large Drupal event which is affordable for everyone from within Europe.
  • We don’t need huge and fancy venues if we can decrease the price of the tickets and make the conference more sustainable.
  • We don’t mind taking a lunch break and go out to find some food during the event if this will decrease the price of the tickets.

Today

Thanks to all the work we have done during DrupalCon Vienna, today we have a working group of several key people from within the European Drupal community that are collaborating on organizing a large scale Drupal event in Europe next year. It has been decided that the event will be called “Drupal Europe”.

Licensed — Image courtesy of Paul Johnson

The Drupal Association has acknowledged our initiative and has decided that they will support us wherever is possible. We would like to outline that this initiative is not about creating a separate entity. We encourage collaboration and we will keep the Drupal Association in the loop of all our future progress.

This working group is not the same group that Megan announced at DrupalCon Vienna. The group of eight people was formed to advise the Drupal Association on a selection process, and the selection criteria for licensing DrupalCon Europe in 2019. Nevertheless, some people are involved in both groups. This will help to strengthen and prove the advice of this group.

The format of Drupal Europe

As Drupal Europe 2018 will act as a proof of concept for future DrupalCons we decided to go for a MVP approach for 2018. This means that we will experiment with various concepts with a main focus to organise a sustainable event.

Ticketing

As Drupal Europe 2018 should be an event which brings members of our community together, we will introduce different tiers of tickets. The first tier will be for people who are coming to collaborate on contribution & community work. This ticket will allow people access to BoF’s, sprint rooms, social events and the sponsors exhibition hall.

The second tier of tickets is targeting people who come to learn and to get updates from speakers. This ticket grants the person access to sessions and trainings plus all that the contribution ticket allows above.

Keynotes

In order to make this event sustainable, we are not looking for venues that can have 2000+ people in one room. Venues that are offering these type of rooms are usually very expensive and booking one could lead to failing in our mission. Instead we are looking for a venue with several rooms where people can watch the live stream of the keynote instead.

Mission

Our aim is to organise a sustainable and affordable event where people from the European (and global) Drupal community can collaborate together on tackling challenges and engage in order to make Drupal grow both as a technology and as a brand.

Our core values:

  • Engage
  • Challenge
  • Grow
  • Collaborate
  • Community
  • Sustainability

What’s next?

  • Call for venues
  • Setting up OpenSocial site so all the enthusiasm can be converted into action.

Who’s involved?

Want to get involved? Send a DM to http://www.twitter.com/@drupaleurope , contact any of people listed above or join us at https://drupaleurope.getopensocial.com/

Financial support

We’re in need of early sponsors to back the plan and make it scale. If you are interested, please contact any of the people listed above.

Oct 18 2017
Oct 18

A checkout is a pretty fundamental part of a commerce system. So the fact that Commerce 2.x has a checkout is not really news. But it’s what you can do with the checkout that makes 2.x special.

You can now configure the checkout workflow. You can opt to ask for billing information, shipping information, certificates, registration details, etc. There’s lots of different data that can change depending on the type of product you sell. If you sell digital products, for instance, you don’t need shipping information. If you sell course registrations, you might require pre-existing certificates. Maybe you do both, so you need to configure multiple types of checkouts.

And that’s easy to do. For the most part, it’s a matter of dragging and dropping options. You can add or remove pieces pretty easily. If you need something really custom, like if you need to validate a safety certificate against a third party, you might need a developer to build that functionality. But otherwise it’s a fairly simple process.

You can also integrate into any part of the checkout. Maybe you do something when you add to cart, or when you complete the order. Maybe you even go off-site to pay through PayPal or register through Eventbrite and then come back. You can hook into any step you need in order to get those things done.

Commerce 2.x also has a more modern checkout out of the box than Commerce 1 had, with billing information on the side, and a floating cart rather than a series of pages you go through, and all those sorts of best practices. It’s a nice update from Commerce 1.

In the end, it’s all the customizations that make the checkout in Commerce 2.x new and cool.

Oct 17 2017
Oct 17

when-drupal-is-bad-fit.jpg

My instinct is to say never….but if you are still wondering “Should I use Drupal?”, read on and we will take a look deeper to see if we can find some cases where Drupal may be a bad fit.

Brochure and small websites

Drupal can be overkill if your site needs consist of a page or two and maybe a webform. I would agree that the overhead of Drupal may be a bit much here, but you should also consider your future needs. Your simple site may need to grow into something that requires users, e-commerce, or more complex data handling. If that is the case then you would save money in the future by investing in a solid web framework early on.

Legacy Systems

If years of your data is tied up in a legacy system, it may be too risky to try to switch a site over to Drupal. That is understandable but you should also calculate the costs of maintaining the old system, the added time it takes to add new features, and the vulnerabilities that come up in older depreciated software. It takes a lot of planning and can be a bit tedious but a migration to Drupal 8 may actually cost less in the long run.

Small Budget

Drupal development costs due seem to be a bit higher than development on other popular content management systems. But I would say that the difference in cost is negligible, especially when you have a lot of custom needs. Drupal will actually save you money once it comes time to build custom features.

See our article on Drupal vs. WordPress for more details when comparing the true costs of a WordPress site.

If you truly have a tiny budget and many development needs, it is probably time to face reality and scale back to what you can truly afford, regardless of which CMS you choose. If you have a small budget and you can’t accomplish everything you need with a WiX website, then it may be time to re-think your web presence entirely.

No Drupal Experience

If your internal development team or development partner has no previous experience in Drupal, then it really might not be the best choice for your project. It is definitely worth the effort to learn, but be prepared to make big increases to your project timeline. However, this can easily be solved with supplementing your existing team with an experienced Drupal shop like Ashday.

It turns out that there are a few instances where Drupal may not be the best fit, but most of them can be overcome with some planning and evaluation of future needs and requirements.

If you want to build in Drupal but don’t have the right team for the job, you are in luck! Ashday can help with that. 

Offer for a free consultation with an Ashday expert

Oct 13 2017
Oct 13
October 13th, 2017

Welcome to the second episode in our new video series for Emulsify. Emulsify 2.x is a new release that embodies our commitment to component-driven design within Drupal. We’ve added Composer and Drush support, as well as open-source Twig functions and many other changes to increase ease-of-use.

In this video, we’re going to teach you how to create an Emulsify 2.0 starter kit with Drush. This blog post follows the video closely, so you can skip ahead or repeat sections in the video by referring to the timestamps for each section.

PURPOSE [00:15]

This screencast will specifically cover the Emulsify Drush command. The command’s purpose is to setup a new copy of the Emulsify theme.

Note: I used the word “copy” here and not “subtheme” intentionally. This is because the subtheme of your new copy is Drupal Core’s Stable theme, NOT Emulsify.

This new copy of Emulsify will use the human-readable name that your provide, and will build the necessary structure to get you on your way to developing a custom theme.

REQUIREMENTS [00:45]

Before we dig in too deep I recommend that you have the following installed first:

  • a Drupal 8 Core installation
  • the Drush CLI command at least major version 8
  • Node.js preferably the latest stable version
  • a working copy of the Emulsify demo theme 2.X or greater

If you haven’t already watched the Emulsify 2.0 composer install presentation, please stop this video and go watch that one.

Note: If you aren’t already using Drush 9 you should consider upgrading as soon as possible because the next minor version release of Drupal Core 8.4.0 is only going to work with Drush 9 or greater.

RECOMMENDATIONS [01:33]

We recommend that you use PHP7 or greater as you get some massive performance improvements for a very little amount of work.

We also recommend that you use composer to install Drupal and Emulsify. In fact, if you didn’t use Composer to install Emulsify—or at least run Composer install inside of Emulsify—you will get errors. You will also notice errors if npm install failed on the Emulsify demo theme installation.

AGENDA [02:06]

Now that we have everything setup and ready to go, this presentation will first discuss the theory behind the Drush script. Then we will show what you should expect if the installation was successful. After that I will give you some links to additional resources.

BACKGROUND [02:25]

The general idea of the command is that it creates a new theme from Emulsify’s files but is actually based on Drupal Core’s Stable theme. Once you have run the command, the demo Emulsify theme is no longer required and you can uninstall it from your Drupal codebase.

WHEN, WHERE, and WHY? [02:44]

WHEN: You should run this command before writing any custom code but after your Drupal 8 site is working and Emulsify has been installed (via Composer).

WHERE: You should run the command from the Drupal root or use a Drush alias.

WHY: Why you should NOT edit the Emulsify theme’s files. If you installed Emulsify the recommended way (via Composer), next time you run composer update ALL of your custom code changes will be wiped out. If this happens I really hope you are using version control.

HOW TO USE THE COMMAND? [03:24]

Arguments:

Well first it requires a single argument, the human-readable name. This name can contain spaces and capital letters.

Options:

The command has defaults set for options that you can override.

This first is the theme description which will appear within Drupal and in your .info file.

The second is the machine-name; this is the option that allows you to pick the directory name and the machine name as it appears within Drupal.

The third option is the path; this is the path that your theme will be installed to, it defaults to “themes/custom” but if you don’t like that you can change it to any directory relative to your web root.

Fourth and final option is the slim option. This allows advanced users who don’t need demo content or don’t want anything but the bare minimum required to create a new theme.

Note:

Only the human_readable_name is required, options don’t have to appear in any order, don’t have to appear at all, or you can only pass one if you just want to change one of the defaults.

SUCCESS [04:52]

If your new theme was successfully created you should see the successful output message. In the example below I used the slim option because it is a bit faster to run but again this is an option and is NOT required.

The success message contains information you may find helpful, including the name of the theme that was created, the path where it was installed, and the next required step for setup.

THEME SETUP [05:25]

Setting up your custom theme. Navigate to your custom theme on the command line. Type the yarn and watch as pattern lab is downloaded and installed. If the installation was successful you should see a pattern lab successful message and your theme should now be visible within Drupal.

COMPILING YOUR STYLE GUIDE [05:51]

Now that we have pattern lab successfully installed and you committed it to you version control system, you are probably eager to use it. Emulsify uses npm scripts to setup a local pattern lab instance for display of your style guide.

The script you are interested in is yarn start. Run this command for all of your local development. You do NOT have to have a working Drupal installation at this point to do development on your components.

If you need a designer who isn’t familiar with Drupal to make some tweaks, you will only have to give them your code base, have them use yarn to install, and yarn start to see your style guide.

It is however recommended the initial setup of your components is done by someone with background knowledge of Drupal templates and themes as the variables passed to each component will be different for each Drupal template.

For more information on components and templates keep an eye out for our soon to come demo components and screencasts on building components.

VIEWING YOUR STYLE GUIDE [07:05]

Now that you have run yarn start you can open your browser and navigate to the localhost URL that appears in your console. If you get an error here you might already have something running on port 3000. If you need to cancel this script hit control + c.

ADDITIONAL RESOURCES [07:24]

Thank you for watching today’s screencast, we hope you found this presentation informative and enjoy working with Emulsify 2.0. If you would like to search for some additional resources you can go to emulsify.info or github.com/fourkitchens/emulsify.

[embedded content]

Thanks for following our Emulsify 2.x tutorials. Miss a post? Read the full series is 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 | Pt 5: Building a Full Site Header in Drupal

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

Download Emulsify

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.

Oct 11 2017
Oct 11
I was using a Drupal composer template and a few days ago, it upgraded from 8.3 to 8.4 automatically. I noticed and didn't really think much of it, so I applied the database updates and went on my way. Today, two days afterwards, I ran across this article which pointed out that PHP 7 is required for the underlying Symfony framework. Our site is running on Debian 8, which has PHP 5.6 and powers other PHP applications, so I wasn't looking to update the underlying OS and possibly break my other PHP things.

So I downloaded a db snap from 8.3 and then re-applied the 8.4 update and took another database snapshot. Then I diff'd the database snapshots. The biggest changes seemed to be in the cache tables and removing and adding some revision columns. So I reverse-engineered a backgrade SQL script. With that, I updated the composer.json file from this:
        "drupal/core": "~8.0",


to this:
        "drupal/core": "8.3.*",

Then I took a precautionary database backup and then did a composer update, which took care of the code backgrade. Then I ran my script (drush sqlc < backgrade.sql) and then I did a drush entity-updates to actually update the database schemas to match the backgraded code.

Now I just need to ignore Drupal telling me about 8.4 until I'm ready to fully embrace PHP 7. I feel like something bigger needed to get my attention to the update in system requirements when I ran the initial composer update.

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