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

Oct 11 2017
Oct 11

web-development-vs-app-development.jpg

Smartphones have had an immense impact on the way we both interact with websites and how they’re built. In the early days of Android and iOS -- or even further back to flip phones that could access the internet -- websites weren’t designed to fit well onto a small screen. Mobile browsers did what they could to make them work, but it really wasn’t all that long ago that you had to double-tap on some text just so you could zoom in and read something.

There was an app-craze when the smartphone boom happened. Everyone needed to get an app. But is that still the case? Responsive web design is an alternative that many see as more appealing than investing in a site and an app, but can a responsive website fully replace a mobile app?

Responsive Web Design vs Mobile Apps

The vast majority of internet browsing is done on mobile devices now instead of on desktops or laptops, so it makes sense wanting to put time and effort into a finished project that will display well on a smartphone. But what exactly is the difference between a responsive website and an app? If you design a site responsively, users will be able to access it from any device with an internet browser and it should be able to adjust itself to fit whatever resolution and screen size they’re using.

A mobile app, on the other hand, has been specially designed to work on certain operating systems (Android and iOS being the big two) and at specific resolutions. Apps can also make use of things like QR codes, augmented reality, voice recognition, and more. Internet browsers are helping to bridge the gap here, though, and you’ve likely noticed features like Click to Call, User Location, and access to your phone’s accelerometer and gyroscope becoming more common when using your phone’s internet browser.  

Do I need a mobile app if I have a responsive website?

If you dive into data regarding how we all use our phones, you may see some compelling points for going with a mobile app. For instance, 90 percent of mobile activity is spent using apps. But let’s dive a little further into the data. Out of that 90 percent app usage, Facebook (specifically) commands a huge piece of the pie, as do things like messaging/social apps, games, and entertainment -- leaving very little room for anything else.  

A responsive website, on the other hand, is easier to access and share between users (no downloads needed!) and will help build a mobile presence that can be found via search engines. Responsive design will also be more friendly on your wallet and will take less time to build from the ground up than an app would. Going with a responsive website over an app also provides accessibility to more users. Apps can be a barrier for some older users who may be reluctant to download apps but are very familiar with accessing websites via their mobile devices.

Responsive web app as a replacement

Modern responsive websites are more than traditional html and css, they utilize robust frameworks that are closer to an app than a static website. Sites like this are known as web apps. It may have the same appearance of a mobile app, as well as most of its capabilities, but a web app doesn’t require a user to download it -- it just loads in-browser in place of the regular website. Historically, a weakness of a web app would be that it can’t access things like your camera or GPS, but hybrid web apps are now able to gain access to your phone's API, similarly to a regular mobile app.

Having a responsive web app also eliminates the need to submit your app to the proprietary Apple app store for Apple devices and Google Play for Android devices. On top of that, there is no need to post updates for each device type or worry about compatibility beyond standard cross-browser testing.

How to choose between a responsive web app and a mobile app?

In the end, you need to look at what will best serve your needs best. A mobile app makes sense for a platform like Facebook since they need to efficiently deliver tons of content and media, rely heavily on a positive user experience, and don’t need to worry about discoverability.

If having access to device APIs for your users is something that will greatly increase their overall experience but you don’t want to invest the extra time and money that a mobile app necessitates, then a hybrid web app may be the way to go.

You may also find that a standard responsive website offers everything that you need, and can forgo the added overhead and time that building a web app that accesses device features requires. Building a mobile site first also gives you the option to someday extend it to utilize device features.

If you’re not sure what the best solution is for you, feel free to reach out and we can help you kick around options.

Offer for a free consultation with an Ashday expert

Oct 10 2017
Oct 10

 

To say that payment gateways are much improved in Commerce 2.x is a bit of an understatement. The process of implementing a payment gateway has been cut down to about a third of the time, with more functionality rather than less.

How could this be, you ask?

We took a whole bunch of stuff you used to have to custom make for each payment gateway and put it right into Drupal Commerce itself. That’s not as easy as it sounds. You have to make sure it works for every kind of payment gateway out there: regular ones that take credit cards, those that use PayPal or Apple Pay, even those that accept Bitcoin.

We wanted to simplify the process without restricting it—and that’s what we managed to do. (It took three revisions and a lot of time, but hey, Rome wasn’t built in a day.)

Typically, when you implement a payment gateway, there’s some sort of library or API for that gateway, and you need to connect that library to your ecommerce system so that when you want to process a payment, it knows to tell that library to process it. That used to take 20 or 30 hours of work. Now, we have it narrowed down so there’s very little custom logic you have to write to link things up. It really speeds things up.

Tokenization

We use tokenization for everything by default. Tokenization is when you take a credit card number and you pass it on to the payment gateway, and they give you back a reference for that credit card. So any actions taken on that card (payments, refunds, pre-authorizations) are done against the token and not against the actual card. You don’t store the credit card number; you just store the reference to it.

This has two big advantages:

  1. If that card expires and a new one is issued, most payment gateways will handle that on the back end, and you just use the same token you always used. This is how Netflix is able to keep right on billing you for eternity; they don’t need your new credit card. (Unless you cancel it and get an entirely new one, of course.)
  2. You are not storing the credit card number, which is good for PCI compliance. The more modern gateways like Stripe and Braintree have a JavaScript layer so that you don’t store that credit card number even for a fraction of a second; it never touches your server. It goes right from the user’s browser to the payment gateway, and the gateway delivers the token. So if you get hacked, you don’t compromise those credit card numbers, because you never had them.

Multi-currency

We use a localization library provided by Google to handle pretty much every kind of currency in use in the world. This is important because you have to know how to format the numbers: What symbol does it use? Does it have decimal points? Does the currency use commas or periods as separators?

Even the language the currency is being displayed in will affect how it appears. Take the Canadian dollar, for instance. In English, the Canadian dollar has the dollar sign at the beginning and uses a period as the decimal separator; in French, the dollar sign goes at the end, and the separator is a comma.

The Bottom Line

In Commerce 2.x, implementing payment gateways is a lot simpler, and there’s a whole lot more functionality.

Oct 05 2017
Oct 05
October 5th, 2017

Welcome to the first 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 get you up and running with Emulsify. This blog post accompanies a tutorial video, which you can find embedded at the end.

Emulsify is, at it’s core, a prototyping tool. At Four Kitchens we also use it as a Drupal 8 theme starter kit. Depending on how you want to use it, the installation steps will vary. I’ll quickly go over how to install and use Emulsify as a stand alone prototyping tool, then I’ll show you how we use it to theme Drupal 8 sites.

Emulsify Standalone

Installing Emulsify core as a stand alone tool is a simple process with Composer and NPM (or Yarn).

  1. composer create-project fourkitchens/emulsify --stability dev --no-interaction emulsify
  2. cd emulsify
  3. yarn install (or npm install, if you don’t have yarn installed)

Once the installation process is complete, you can start it with either npm start or yarn start:

  1. yarn start

Once it’s up, you can use the either the Local or External links to view the Pattern Lab instance in the browser. (The External link is useful for physical device testing, like on your phone or tablet, but can vary per-machine. So, if you’re using hosted fonts, you might have to add a bunch of IPs to your account to accommodate all of your developers.)

The start process runs all of the build and watch commands. So once it’s up, all of your changes are instantly reflected in the browser.

I can add additional colors to the _color-vars.scss file, Edit the card.yml example data, or even update the 01-card.twig file to modify the structure of the card component.

That’s really all there is to using Emulsify as a prototyping tool. You can quickly build out your components using component-driven design without having to have a full web server, and site, up and running.

Emulsify in a Composer-Based Drupal 8 Installation

It’s general best practice to install Drupal 8 via Composer, and that’s what we do at Four Kitchens. So, we’ve built Emulsify 2 to work great in that environment. I won’t cover the details of installing Drupal via Composer since that’s out of scope for this video, and there are videos that cover that already. Instead, I’ll quickly run through that process, and then come back and walk through the details of how to install Emulsify in a Composer-based Drupal 8 site.

Okay, I’ve got a fresh Drupal 8 site installed. Let’s install Emulsify alongside it.

From the project root, we’ll run the composer require command:

  • composer require fourkitchens/emulsify

Next, we’ll enable Emulsify and its dependencies:

  • cd web
  • drush en emulsify components unified_twig_ext -y

At this point, we highly recommend you use the Drush script that comes with Emulsify to create a custom clone of Emulsify for your actual production site. The reason is that any change you make to Emulsify core will be overwritten when you update Emulsify, and there’s currently no real good way to create a child theme of a component-based, Pattern Lab -powered, Drupal theme. So, the Drush script simply creates a clone of Emulsify and makes the file renaming process into a simple script.

We have another video covering the Drush script, so definitely watch that for all of the details. For this video though, I’ll just use emulsify core, since I’m not going to make any customizations.

  • cd web/themes/contrib/emulsify/ (If you do create a clone with the drush script, you’ll cd web/themes/custom/THEME_NAME/)
  • yarn install

  • yarn start

Now we have our Pattern Lab instance up and running, accessible at the links provided.

We can also head over to the “Appearance” page on our site, and set our theme as the default. When we do that, and go back to the homepage, it looks all boring and gray, but that’s just because we haven’t started doing any actual theming yet.

At this point, the theme is installed, and you’re ready to create your components and make your site look beautiful!

[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 Brian Lewis
Brian Lewis

Brian Lewis is a frontend engineer at Four Kitchens, and is passionate about sharing knowledge and learning new tools and techniques.

Oct 02 2017
Oct 02

“Shipping” in Commerce 1 meant “get shipping rates.” End of story. If you wanted to do something crazy like actually receive the item or put it in a box in the warehouse, you were out of luck. You could integrate with another system, but otherwise you were really just a storefront.

But Commerce 2.x is a different story. Now you can go from getting rates all the way down to actually receiving the shipment.

Some background

With Commerce 1, we realized we had shipping that didn’t do anything other than give rates (and if you have free shipping, you don’t even care about that). So we set out to fix that in Commerce 2.x.

Shipping is actually a pretty complicated process. Once someone purchases a product, how does it actually get to them? You need to print off labels that have barcodes and will work for UPS and FedEx and any other delivery service you plan to use. You have to know what boxes to put stuff in, what goes in what box, what gets shipped out from what location, etc.

Commerce 2.x now has a nice shipments API that can handle all of that.

New functionality

Everything has a plugin interface now. Take packing, for example. You can have a packing algorithm that is really simple—i.e. everything goes into a theoretical box of infinite size. Or the algorithm can be more complicated—you can say these things can’t get packed with this, or these things are chairs, so they stack a certain way.

For every step of the shipping process (getting rates, printing labels, doing packing slips, and so on) you can use the functionality that’s now built in to Commerce 2.x, or you can replace any or all of those pieces with other providers. That could be delivery services like FedEx or UPS, or it could be some sort of third-party shipping provider that handles the boxing, or it could be Amazon if you do your fulfillment through them.

The bottom line

Shipping in Commerce 2.x now covers the whole flow of shipping, from ordering to having the package arrive at someone’s house. It’s a massive improvement over Commerce 1, which only gave the rates.

To learn more, check out our High Five episode “Drupal Commerce 2.x—Shipping.

Subscribe to our YouTube Channel for more Drupal Commerce goodness!

Oct 02 2017
Oct 02

Working in the charity sector you learn to be pretty resourceful when you need to be, and that doesn’t stop at blagging free stuff (obviously we never do that ;)).

One of the most significant things we learnt from amalgamating our campaign sites onto a single platform was the efficiency that emerged from reusing code and functionality.

So when our Schools and Youth team approached us with an objective that was new to all of us we did what anyone else would do, look at what we’d done already and could copy!

The objective

Noses! 

Red Noses to be precise. We’ve just launched our first ever ‘Design a Red Nose’ competition for schools where students between 4 and 18 can draw their own Nose design with a chance of getting their masterpiece as one of the final nine Noses made for the next Red Nose Day in 2019. Yes, it’s pretty exciting stuff and we’ve had more than a few disgruntled members of staff annoyed at the fact that they’re no longer schoolchildren.

To build the entry functionality, we needed a simple and efficient solution for teachers and school staff to be able to upload their students’ entries.

I thought about various online forms we’d created in the past and whether we could repurpose those to add an image upload mechanism.

Then my somewhat genius colleague Caroline – whom you might know from blogs such as Optimistic about our future of optimisation and How ‘going live’ became my mental blogger –  completely flipped it on its head and suggested a piece of functionality we’d used for past Sport Relief and Red Nose Day campaigns – our fundraiser gallery. This was used for our fundraisers to upload photos of themselves doing the weird and wonderful things people do for Comic Relief.

It seemed like the perfect solution and – spoiler alert – eventually it was, but obviously there were a few creases to iron out first. I won’t bore you with the details, no one likes ironing, but in short we had to:

  • Add an online form to the current functionality
  • Adapt the existing validations to fit other file sizes and formats like pdf
  • Ensure the designs being uploaded had somewhere to go and that we could get to them!
  • Ensure the data in the online form was sent to a secure and integrated database we could access
  • Integrate a schools address look-up used for schools-related forms

So we managed to get the form up and running (despite a few niggles that came up in QA, a few grumbles that came up with the changing the validations and error messages and a couple of gripes when we tried to link the form to our CRM database) – hurrah!

Lessons learned

There were lots of elements to this upcycling process: numerous parties that needed to be consulted, from data and legal, to tech and design; finding and implementing a solution in six weeks (while working on other products with clashing launch dates) and; testing and ensuring a simple user journey.

So, what nuggets of wisdom can I pass on to anyone else about to attack the same kind of problem?

  1. Communicate! Regular stand-ups made sure all teams were on the same page at all times, and allowed us to work quickly.
  2. Upcycle! Look at what you’ve used before and how you can adapt and iterate to get to your end goal more quickly. Also, think about how you might use it again – we’ve already planned our next iteration!
  3. Trust and collaboration! We reached a solution smoothly and efficiently because our stakeholders came to us with the problem. By being descriptive to our dev team of what was needed rather than prescriptive about what they should build, our team ended up building the best thing!
  4. Focus! It’s easier said than done but where you can get teams to focus on one thing at a time, it’s efficient, productive and keeps people a lot happier!

Share this:

Like this:

Like Loading...
Sep 28 2017
Sep 28
September 28th, 2017

If your site was built with Drupal within the last few years, you may be wondering what all the D8 fuss is about. How is Drupal 8 better than Drupal 6 or 7? Is it worth the investment to migrate? What do you need to know to make a decision? In this post we’ll share the top five reasons our customers—people like you—are taking the plunge. If you know you’re ready, tell us.

  1. Drupal 8 has a built-in services-based, API architecture. That means you can build new apps to deliver experiences across lots of devices quickly and your content only needs to live in one place. D8’s architecture means you don’t have to structure your data differently for each solution—we’ve helped clients build apps for mobile, Roku, and Amazon Alexa using this approach (read how we helped NBC). If you’re on Drupal 6 now, a migration to Drupal 8 will allow you to do unleash the power of your content with API integration.
  2. You can skip Drupal 7 and migrate straight to D8. If you’re on Drupal 6, migrating directly to Drupal 8 is not just doable—it’s advisable. It will ensure every core and contributed module, security patch, and improvement is supported and compatible for your site for longer.
  3. The Drupal 8 ecosystem is ready. One of the reasons people love Drupal is for the amazing variety of modules available. Drupal 8 is mature enough now that most of the major Drupal modules you have already work for D8 sites.
  4. Drupal 8 is efficient. Custom development on Drupal 8 is more efficient than previous versions—we’ve already seen this with our D8 clients and others in the Drupal community are saying the same thing. When you add that to the fact that Drupal 8 is the final version to require migration—all future versions will be minor upgrades—you’ve got a solid business reason to move to Drupal 8 now.
  5. It’s a smart business decision. Drupal 6 is no longer supported—and eventually Drupal 7 will reach “end of life”—which means any improvements or bug fixes you’re making to your existing site will need to be re-done when you do make the move. Migrating to Drupal 8 now will ensure that any investments you make to improving or extending your digital presence are investments that last.

If you’re still not sure what you need, or if you would like to discuss a custom review and recommendation, get in touch. At Four Kitchens, we provide a range of services, including user experience research and design, full-stack development, and support services, each with a strategy tailored to your success.

LET’S TALK!

Read about American Craft Council’s move to Drupal 8
Your site should use component-based theming, here’s how
See what we’ve done for other clients >>
Read more about the services we provide >>
Meet the team >>

Web Chef Todd Ross Nienkerk
Todd Ross Nienkerk

Todd Ross Nienkerk is the CEO and co-founder of Four Kitchens. He was born in a subterranean cave in the future.

Sep 24 2017
Sep 24

Over the years Drupal distributions, or distros as they're more affectionately known, have evolved a lot. We started off passing around database dumps. Eventually we moved onto using installations profiles and features to share par-baked sites.

There are some signs that distros aren't working for people using them. Agencies often hack a distro to meet client requirements. This happens because it is often difficult to cleanly extend a distro. A content type might need extra fields or the logic in an alter hook may not be desired. This makes it difficult to maintain sites built on distros. Other times maintainers abandon their distributions. This leaves site owners with an unexpected maintenance burden.

We should recognise how people are using distros and try to cater to them better. My observations suggest there are 2 types of Drupal distributions; starter kits and targeted products.

Targeted products are easier to deal with. Increasingly monetising targeted distro products is done through a SaaS offering. The revenue can funds the ongoing development of the product. This can help ensure the project remains sustainable. There are signs that this is a viable way of building Drupal 8 based products. We should be encouraging companies to embrace a strategy built around open SaaS. Open Social is a great example of this approach. Releasing the distros demonstrates a commitment to the business model. Often the secret sauce isn't in the code, it is the team and services built around the product.

Many Drupal 7 based distros struggled to articulate their use case. It was difficult to know if they were a product, a demo or a community project that you extend. Open Atrium and Commerce Kickstart are examples of distros with an identity crisis. We need to reconceptualise most distros as "starter kits" or as I like to call them "puppies".

Why puppies? Once you take a puppy home it becomes your responsibility. Starter kits should be the same. You should never assume that a starter kit will offer an upgrade path from one release to the next. When you install a starter kit you are responsible for updating the modules yourself. You need to keep track of security releases. If your puppy leaves a mess on the carpet, no one else will clean it up.

Sites build on top of a starter kit should diverge from the original version. This shouldn't only be an expectation, it should be encouraged. Installing a starter kit is the starting point of building a unique fork.

Project pages should clearly state that users are buying a puppy. Prospective puppy owners should know if they're about to take home a little lap dog or one that will grow to the size of a pony that needs daily exercise. Puppy breeders (developers) should not feel compelled to do anything once releasing the puppy. That said, most users would like some documentation.

I know of several agencies and large organisations that are making use of starter kits. Let's support people who are adopting this approach. As a community we should acknowledge that distros aren't working. We should start working out how best to manage the transition to puppies.

Share this post

Sep 21 2017
Sep 21

Drupal Commerce 2.0 has finally reached 2.0 status with an official stable release on September 20, 2017! Sound the horns! More Cowbell! Naturally, our clients are starting to think about migrating Drupal 7 Commerce 1.x to the new Drupal 8 Commerce 2.0 platform, this post is an effort to help you decide if migration is right for you, and how to approach the tasks at hand. Not to brag (ok, we are bragging), but we have some incredible insight into the process of migration because two of our very own are core migration module maintainers (quietone & heddn). I reached out to these two when putting together this post.

Do you need to migrate?

The quick answer is not yet, but you should be starting to think about it. You don’t need to migrate, but you will want to. Check out a few reasons why you’ll be begging to make the leap:

  • Drupal 7 and Commerce 1 will only be supported for so long now that new versions of both are out. The end of life dates haven’t yet been set, but that doesn’t mean you shouldn’t start to prepare for the inevitable.
  • End of life means that the worldwide network of Drupal developers will pivot their energy away from D7/DC1 and focus their skills, efforts, engineering and security practices on the new and shiny version of the platform. That means that if you want all of the good (and free) Drupal juice, you need to hop over to D8 and DC2 to reap the rewards.
  • Drupal Commerce 2 introduces a better update path. What does that mean? It means that new features will be introduced into the core through micro-updates, major migrations will be a thing of the past. Yup, you read that right - This is the last full migration you’ll ever need to make.
  • Features, oh the new features. All yours! From tax integration, multi-language support, currency setups, shipping, fulfillment, API’s left and right, oh the list goes on and on. You get the bells AND the whistles, and they will just keep coming as new updates roll out without any effort or expense on your part. Migration can be mighty sexy.

When the inevitable does happen and the masses are using the new version of the platform, Drupal 7 and Commerce 1 will be laid to rest by the community; there will most likely be a big scramble from those who haven’t already planned for the future. Being ahead of that curve could be advantageous, not to mention opportunistic and allow for your company and eCommerce store to have a voice in driving the roadmap of Commerce 2.

What can you expect from migrating?

You’re thinking back to the initial build, configuration and custom module development of your D7/Commerce 1 site, and you’re thinking, how in the sweet blue sky can we possibly migrate this glorious unicorn over to D8 and Commerce 2 without going through all of that planning, pain and expense again… We hear you. Any migration does require some technical expertise to complete successfully, but any competent development team should be able to pull it off. Shying away from an absolutely necessary business upgrade is not the answer.

eCommerce migrations are 2 parts.

  1. Moving from Drupal 7 to Drupal 8 (think of your core moving up a notch, themes, templates and CMS are all getting pimped out). This does require a “re-do” not just a port.
  2. Migrating the commerce engine and all it’s parts and associated data to Commerce 2.0.

How long will it take? That’s the first question we are asked. For a very simple site, we’ve seen a pure content migration take as little as 50 hours. For more complex migrations, where we’re bringing in unique data from various sources, it could easily take 200+ hours for the migration alone, and the D8 framework and templating is in addition. Step one is to find out where you fall on the spectrum of difficulty and begin to parse out the to-do list accordingly before jumping into the undertaking.

Take migration as an opportunity to level up your online business; It’s an opportunity to come up with a fresh design that takes into account today’s technology, design and UX standards that shape the way users ultimately use your website. If you’re on D7 and Commerce 1, it’s time for that site evolution conversation to begin.

How does a migration happen?

As mentioned earlier, migrating does require a number of technical steps. Time to get into some of the nerdy details…. Here’s a general approach that we’ve been using successfully.

  1. Get a source database dump from the existing Drupal 7 Commerce 1.x site. TIP: Potentially, get the site code too. It isn't strictly necessary, but helpful.
  2. Install a vanilla Drupal 8 site with no content and only the modules enabled that you want to migrate into. Enable Commerce 2, the date module, pathauto, Google Analytics, etc. TIP: Don't bother adding any content or configuring this site; You’ll end up losing all of the configuration after the migration.
  3. Using Drush, create all my migration configurations and export the configuration to yaml files. TIP: We use Drush, because the migration modules GUI is very simplistic and doesn't allow for any site re-architecture.

    If we need to collapse node types, combine product types, use media on D8, etc., it makes more sense to migrate the content directly from Drupal 7 into the new structure. However, this is only possible with a custom migration where we build the configuration, export the yaml files and start customizing and mapping to the new destinations.

  4. Now we would apply this patch (by heddn) and run all the migrations. In the future, we might not need this patch, but at the time of writing we do. This lets us see what migration errors exist and how much more work we have to do. If there are errors on this first migration, and there always are, we fix the errors and run the migration again. TIP: At this point, we’re only focusing on migrating configuration, not content. Getting the configuration migration solid is the first milestone and usually doesn't take that many hours.
  5. Next is the content migration. This is where we have lots of fun combining content types and move all the files into shiny new media entities, etc. We won't re-run the config migration at this point, so if we need to start tweaking the config on the site, flipping knobs and switches, we can do that now.

    The majority of the migration effort is spent making sure all content is migratable. Things that are notoriously hard are: field collection/paragraphs, multi-lingual sites and media, video, audio or file fields. TIP: Look out for the odd line item fees or product classes that take some extra work.

    Basically, anything that seems dirty, ugly, hacky, and wasn't in core in Drupal 7 or Commerce 1 is going to take some time to migrate cleanly. Make a list, check it twice.

  6. At this point we can setup a staging environment and compare the new site on Drupal 8 to the previous Drupal 7 site. If this is for a client, they can oftentimes become involved at this stage. We’re looking for missing content fields, malformed dates, missing files and anything else that seems amiss. We haven't run our final migration yet, just trying to gauge how close we are. We'll run the actual final migration later on.
  7. Now, or maybe a little earlier after we've landed on a stable Drupal 8 site configuration, we can also start doing other site building and theming work. We cannot place blocks or be certain about what node or product ids are going to be, since we haven't run the final migration. But we can use Recreate Block Content module and hope for the best.
  8. We’re getting very close now. Theming is now complete and we should have creative and client signoff of the site's appearance. We should now have a solid migration process and be able to schedule a go-live date.
  9. On, or as close to go-live as possible, we can start migrating files and data. For files, We like to rsync all the Drupal 7 files to the Drupal 8 destination beforehand. File migrations are quite slow, but rsyncing is much faster. For the remaining data, depending on its size, the final migration can take anywhere from minutes to several hours. Sometimes we can jump start the migration a little by running it a day or two in advance, but know that any new content or users that are created in those couple days are going to disappear once we take the new site live. The exact timing of the migration really depends on the site. TIP: Have a rollback available in case you need to take a second crack at this.
  10. After some final testing, backups, and other launch tasks, we can flick the switch and take the new Drupal 8 Commerce 2.0 site live! Break out the champagne and celebrate!

What if there are any problems after launch?

This is an important question. If we’ve all done our jobs correctly, with prudent testing, then there really shouldn’t be any (or many) problems after launch. However, with large migrations there are so many variables at play. It would be unrealistic and unwise to think that there won’t be any bugs; they may not be launch-gating but they will need attention and clean up nonetheless. Internal dev teams and external service providers should all have systems in place to deal with potential issues; it’s all hands on deck to test and report on the new setups success and issues.

How do we handle this step? Acro Media does this by providing a bug warranty for 90 days whereas we will fix any bug that arises within this initial timeframe, free of charge. We also offer various service level agreements (SLAs) for additional, ongoing support.

In conclusion

We hope that this article provides some insight into what’s involved with migrating your Drupal 7 Commerce 1 site to Drupal 8 Commerce 2, and gets the conversation started for your business. It sounds like a big job, because it is - but it’s totally worth it. Not only will you end up with the latest and greatest in Drupal and Drupal Commerce, but you’ll now be setup for proper eCommerce into the future. New revenue streams, new marketing directions, or just the “same ol’ thing” but faster and with a new coat of paint, the direction is yours to tak

Of course, if you'd like a hand we're always here to help.

Contact us to discuss your migration!

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