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 30 2017
Oct 30

Imagine your Drupal site as a... patient who has received the wrong diet (or who simply hasn't been told that he should stick to a special diet in the first place) and all the wrong medication, as well. A silly metaphor for the most common Drupal mistakes that you might have been making on your website.

... and whom (your website “patient”) you're now striving to train for the Olympics, meaning to boost its overall performance. 

It's not going to work unless you “detect” those common issues deriving from improperly handling your site and from deviating from Drupal's best practices. And not before you get them fixed, obviously.

And how can you know for sure whether you are making these “popular” mistakes on your Drupal website?

Easy! You just give an honest answer to each one of the 7 questions from our little “investigation” here below.

Ready?
 

1. Have You Been Ignoring the Drupal Updates?

Just admit it! 

And then try counting how many times you placed the Drupal Core and Contrib Drupal Security Advisory at the very end of your priority list. Or just how many times you ran the suggested upgrades selectively?

The more time has passed since you stuck to this “bad habit”, the more vulnerable your Drupal site's become. 

This is, undoubtedly, one of the common Drupal mistakes and the “ultimate” source of the most security threats.

Note: For instance, if it's an unacceptably long period of time that we're talking about since you stopped maintaining your website properly (if it runs on a version older than Drupal Core 7.32), then it stands all the chances to have turned into an easy target for Drupageddon attacks.
 

2. Are There Any Unused Modules Left to Linger On Your Drupal Site?
 

  • bogged down site performance (with your way too large database as a “culprit”)
  • high impact security issues
  • unnecessary overhead
     

This is precisely what you get when you're being negligent in managing your unused modules (or themes).

Those modules that maybe you just installed and took out for a quick spin, fascinated with their much-talked-about functionality, and that you no longer use. Yet you just leave them... be. And weight down your database with an unnecessary load of source code.

Some of them might be lingering there since... your site's early days. Think of all the developer and administration modules (e.g. Devel or View UI) which shouldn't be overburdening the production version of your website.

Yet, they still do!

They're just being tolerated and gradually turning themselves into some major security issues if no one in your team deals with Security Advisories regularly.

The solution to this issue, that can easily make it to top 3 most common Drupal mistakes, is as clear as daylight: uninstall all the modules and themes that you're no longer using! Don't just bundle up unnecessary overhead.

And while the solution is ridiculously handy, the benefits are definitely worth the time and “effort”:
 

  1. improved file system
  2. instantly boosted site performance
     

3. Is The PHP Filter Module Enabled? One of the Most Common Drupal Mistakes

Just skip this question if it's a Drupal 8 website that you own. For this specific module has been (thank God!) removed from Drupal 8 core.

Now, getting back to the PHP Filter module, which many site owners decide to enable (like you, probably), here's why you should rush to... uninstall it:
 

  • practically it's an invitation for all ill-intended users to easily run PHP code right there, on your website
  • once enabled, it's quite a challenge to.. disable it before you've reviewed your site's content thoroughly
  • and if you skip this step (the close reviewing of your site content), you risk displaying PHP code in plain text on your website (which could turn into a true security “crate” if not detected before you disable the module)
     

4. Are You 100% Sure the JS/CSS Aggregation Settings Have Been Correctly Configured?

If so, then the JavaScript and CSS files that Drupal renders in HTML can be easily bundled up and compressed.

But if not properly configured, your users' browsers will be forced to process far more requests in order to render your web pages' content. Which will inevitably impact your site's page load times.
 

5. Have You Managed to Avoid the Common “Overusing Roles” Pitfall?

Or not? Don't be too harsh on yourself if you have, indeed, “overused” the user roles system. It's, undoubtedly, one of the most common Drupal mistakes website owners make after all.

And what else could you have done when the default user roles that Drupal provided you with just didn't fit the specific permission levels you had in mind for your users, right?

You went ahead and created your own roles...

Unfortunately, these newly custom-made roles can easily:
 

  • lead to Drupal admins being forced to edit each and every user role separately whenever he/she has to update the permissions
  • cause “security craters” when not properly configured 
  • (overusing roles, along with their “collections” of permissions, can) impact your site's overall performance (particularly when you're striving to manage each and very set of permissions in their associated user roles)
     

6. Have You Configured The Full HTML Input Format for Your Most Trusted Users ONLY?

Or have you simply overlooked it entirely? Have you just disabled HTML filtering from the HTML Input Filter completely?

By configuring the Full Input Format for ALL your users, you're basically granting everyone permission to post HTML on your website. This way, you're just opening a gateway for any user to embed malicious code on your Drupal site.

Even a banal little thing such as an image tag can easily turn into an "injectable solution", a dangerous one, in the hands of an ill-intended user who can post HTML on your website just like that.

Now here's what you should do to avoid this scenario:
 

  • make sure that your filter is configured for some users ONLY and, even then, that you set only the specific set of tags they'll need to use
  • make sure your default and custom Input Filters are correctly configured so that they pose no security risks
  • scan your database through and through identifying any possible suspicious code that might have been injected already
     

7. Are You Weighting Down Your Database With Too Many (Unused) Content Types?

Do you need ALL the content types currently overcharging your database (considering the fact that three database tables get added to your database with every new content type that you bring on)? Are you actually using them all?

For, it not:
 

  • your database is unnecessarily overburdened
  • your content editors' workflow is unnecessarily complex due to the whole network of confusing content types that they need to tangle themselves up in

And now the solution to this issue, for certain one of the top most common Drupal mistakes:

Just run an inventory of all your content types, sort them into used and no longer used ones and... just "trim the fat"! Get rid of those that are just filling in space in your database!

This is our top 7 mistakes that you, too, are probably making on your Drupal site (even if not all of them).

Now that we've exposed them to you we can't but end our post with a conclusion/piece of advice:

The handiest way to optimize your website's performance is by preventing performance issues to occur, in the first place. Now that you have them “brought to light” it should be easier, with a little bit of effort, to avoid them, shouldn't it?

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

DrupalCon Vienna... Drupal 8.4.0's release... React “nominated” to be integrated into Drupal core… decoupled Drupal turning into THE hot topic of the moment... This is October on Drupal planet!

And since here, at OPTASY, we've “struggled” to be one step ahead of all the news, the emerging trends shaping the future of Drupal and the best new practices in Drupal development, we've come across some great Drupal blog posts.

They managed to inform us, inspire and delight us (since they're also ideally user-friendly written).

And since our team is anything but selfish or ungrateful like, we've decided to:
 

  • spotlight these valuable pieces of content that we liked most
  • share them with you
     

Note: It's in a strictly chronological order that we'll present them to you!
 

A blog post which came as a reinforcement and putting into words of Dries Buytaert's (Creator of Drupal) previous proposition expressed during his keynote at DrupalCon Vienna. All his posts are perfectly structured, containing his well-argued points and this one is no exception.

From the:
 

  • very context which led to a similar proposition being rejected by the Drupal community 2 years ago
  • to the sustained efforts made for getting Drupal ready for such a major JavaScript integration
  • to the current context of JavaScript in Drupal
  • to his suggestions for a smooth adoption of this approach
  • to outlining the reasons why it is React that he favored, over other JavaScript frameworks
     

… this blog post has undoubtedly been the one that stirred the most “controversies” within our team this month.

“React in Drupal... core?”, “Why React and not another equally popular JavaScript framework?”, “How quickly will we get a grip of these React-powered administrative UIs?” “How exactly will a decoupled administrative UI benefit us compared to a PHP one?”  
 

The blog post comes as a more than welcome refresher of all the accessibility principles, requirements and WCAG 2.0-centered tools. And this considering the current context where:
 

  • on one hand Drupal 8 is becoming the “standard” and along with it its extensive built-in accessibility support
  • but on the other hand decoupled Drupal's turning into a reality itself, too, and front-end developers will need to re-learn the accessibility standards and guidelines; they can no longer rely on Drupal 8's accessibility team to... handle it for them by default
     

The author, Tobias Williams, a front-end engineer at Mediacurrent, shares with us his experiences from a workshop on accessibility that he had attended “Accessibility: The Basics and Beyond”. In this respect, he highlights for us some of this talk's main takeaways in his opinion:

  • a needed recap of why we do need to “bother about” accessibility and how precisely do our efforts eventually come to translate into better user experience for all our users 
     
  • how the WCAG 2.0 guidelines are grouped (an aspect which he, himself, had overlooked) and which accessibility enhancements each one of the 4 sections focuses on
     
  • the very first major step is knowing your audience; avoid “blindly” adapting your site's content to these standards (maybe you don't even need to make your content work on all devices; if all your visually impaired visitors already use a built-in voice-over, for instance)
     
  • an inventory of all the tools that you should use for testing whether your site does adhere to all these accessibility standards; whether it presents any “weak links” making it difficult for some users to consume certain parts of its content 

And so Drupal 8.4.0 has been released and, along with it, Drupal blog posts highlighting its new features have been produced on the line.

Yet, we “fell for” this specific post due to Internetdevel team's way of presenting and structuring its content.

It's a succinct, to the point compilation of all the worth-mentioning enhancements brought to this minor version of Drupal 8 sorted into 3 main sections:
 

  • easy updates & backwards compatibility
  • newly integrated modules
  • enhancements aimed at supporting “novelties” in terms of frameworks, JS libraries... (hint: Simfony 3.2)
     

Gabe Sullice's piece of content falls into the “enlightening Drupal blog posts” category!

At least that's how we rated it and we can't but express our gratitude for the fact that he's taken the effort to share his discovery with the world.

Basically here's the challenge: although Drupal 8 “lures” us with form modes, which should enable us to easily manage the content entry side of your Drupal site, in fact...  this promised “empowering” comes with its own limitations.

Simply put: Drupal 8 doesn't know when exactly it should use one form mode or another so... you can't get away without writing custom code (or using contributed modules).

The Atensgroup's solution: hook_entity_field_access()!

What this hook does is allowing you to manage user control, therefore to hide certain fields which particular users shouldn't gain access to. This way you actually “block” those users' access to change the respective field (so you won't have to modify the input content, subsequently). And voila: problem solved!

During the second half of his blog post, Gabe kindly explains to us how to use hook_entity_field_access() during an easy to follow step-by-step tutorial.

A big “Thank you”!
 

Mateu Aguilo Bosch, from Lullabot “strikes again”! That's right, this is his second post on how to improve decoupled performance.

There was a need for a second post (so, no chance to apply his previously presented JSON API-based solution), for he's tackling now a context where you need to write data instead of fetching entities.

It's the Subrequests module that he spotlights now! A solution for aggregating multiple requests (of multiple kinds and even if one of them is closely dependent on a previous response) into one single HTTP request.

And this is a major performance boost since:
 

  • the module handles any type of request, therefore it's not limited to REST
  • it provides multiple responses in one single request
  • ... one HTTP round-trip with no server configuration 
     

The Lullabot author goes on:
 

  • explaining why precisely we need this module to enhance our decoupled Drupal's performance
  • detailing on “blueprints”, the JSON documents with instructions for Drupal to make requests in our name
  • explaining how to use subrequests
     

… and I'll leave the rest of the well-detailed, explanatory images-packed, tutorial-like blog post for you to discover.

And it's these 5 pieces of content which have made it to our list of top favorite Drupal blog posts this month! 5 informative, well-documented, unique value sharing and engagingly written blog posts. 

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!

Sep 20 2017
Sep 20

Following up the Drupal Commerce 2.0 launch announcement, the official 2.0 release launched this morning! A few of Acro Media's Commerce teammates decided to celebrate (the other 60-or-so team members were still required to stay at their desks and write code). We thought we'd share with you in case you couldn't make it in person. Tag #acromedia in your #drupalcommerce2 launch party pics!

party-time-excellent-small.jpg

But, enough about that! What you really want is to try it, don’t you? You’re in luck! There are a couple ways to take it for a spin.

Self Guided Demo

We’ve setup a demo site for Drupal Commerce 2.0 allowing users and fans see what it can do out of the box. Yes we've done a little additional theming, but no custom functionality! The demo is packed full of awesome stuff, and even has some guided tours that walk you through features. Check it out at your own speed:

Urban Hipster Drupal Commerce demo site
View the Urban Hipster Drupal Commerce 2 demo site

Schedule a Personalized Demo

Would you rather walk through the demo and be able to ask questions and get immediate feedback? Maybe talk about what it takes to get an existing eCommerce website into the new Drupal Commerce? Get into the weeds on migration? We have you covered. Contact us to speak with one of our Drupal Commerce business development experts. We’ll arrange a personalized demo and discussion around your schedule.

DrupalCon Vienna

The Commerce Guys will be at DrupalCon Vienna to show off the official release. So, if you’re in the area, or planning to attend, go see them! It’s taking place September 26-29, 2017 at the Messe Wien Exhibition & Congress Centre.

A lucky few from our Acro team will be there too. Our CTO, Shawn McCabe (smccabe) will be in attendence and if you’d like to schedule in a meeting with him contact us. We also have Vicki Spagnolo (quietone) and Rakesh James (rakesh.gectcr) there giving talks. Vicki and Rakesh will both be presenting on the topic of “Migrate Everything into Drupal 8,” which is now very relevant since both Drupal 8 and Commerce 2 will be officially released. Rakesh will also be giving a solo session on “Prophecise your phpunit tests”. Again, if you’re there, check it out!

Sep 19 2017
Sep 19

The holidays are over for a while now, so it’s about time for a new blog. In this article I’ll discuss 12 modules that can help you get started with a great Drupal site:

1. Max image size

A default Drupal installation can check if an uploaded image is too large and display a warning. This module does something similar but is also checking previously uploaded images that are too large and likely taking up too much space.
 It scans all the images (also already uploaded ones) and reduces the size of the original

More info and download — Drupal 7

2. User Import

Useful module to import users using a CSV file.

More info and download — Drupal 7

3. Select (or other)

Drupal’s form API knows by default a select element that allows you to offer choices to those who enter content. This element is limited to the provision of predefined terms (categories). After installing this module, this element can be expanded with an additional field: let the end user choose ‘other’ and offer a free selection field.

More info and download — Drupal 7 & Drupal 8 Alpha

4. Captcha-free Form Protection

Everybody wants to be protected against spammers, this is often done through the Captcha technology; probably you have heard of this before. This module protects you against spammers without Captcha, since this is often a barrier for visitors.

The module applies other techniques (‘behind the scenes’) such as checks if cookies / javascript are disabled, it can also check whether a certain time has exceeded. On the basis of these data it can determine whether the person who sent a form is most likely a spammer or not. The Honeypot module contains similar end features.

More info and download — Drupal 7 and Drupal 8

5. Twitter block

Simple but common used module: shows a Twitter stream from a particular account.

More info and download — Drupal 7 and Drupal 8

6. Leaflet

Leaflet is a javascript library that is quickly becoming popular and that let’s you create maps. It is an alternative to Google maps, allowing you to easily create customized maps and integrate external map services (for example Mapbox, Stamen or Thunderforest). Easy to configure, mobile-friendly to navigate and light in code.

For a detailed introduction see Drupalize.me.

More info and download — Drupal 7 & Drupal 8 dev

7. Better watchdog UI

The Drupal core has a logging module which gives great insights in errors, notices, content and user actions, etc. Install this module if you want to filter better in this log.
 FYI: Till Drupal 5 Drupal’s logging module was called ‘watchdog’, this term is still used for logging elements.

More info and download — Drupal 7

8. Check for acknowledgement

In some cases you want to know whether users of your system have read a particular piece of content. This is now possible after installing this module: it places a check mark at the bottom of a content page. Users placing the check mark are logged which is visible to you as a site administrator. This allows you to see who really confirmed they read the article.

More info and download — Drupal 7

9. IP address manager

Log the IP addresses of users logging into your Drupal site. This can be used for many things:

  • Detecting suspicious logins;
  • Identifying misconduct;
  • Detecting duplicate accounts.

More info and download — Drupal 7

10. Taxonomy container

Make the choice easier for content managers by clustering terms better.

More info and download — Drupal 7 & Drupal 8 beta

11. Date Facets

A widget for when you are using the Facet API: generates an additional block in which date-based filtering options are offered.

More info and download — Drupal 7

12. Read only mode

When putting your system in the maintenance mode in a default Drupal installation, the entire system will be temporarily put offline; the visitors will receive a maintenance message. Usually you would prefer that nobody is logged in on your site, as content can be changed during the update process. Those changes could be lost.

If you can ensure that nobody can enter/change content during maintenance, then you are also adequately covered — provided that your update is not generating errors. This module is doing just that: it places your site in the maintenance mode, so visitors can still view the site but cannot enter/change content.

More info and download — Drupal 7 & Drupal 8 beta

Wrap up

And finally, I discovered this cool site: modulecharts.org . Next month again a module update, so stay tuned! Questions or feedback? Let me know in the comments below

Sep 19 2017
Sep 19

Lately I have been hearing a lot about Laravel. This is a PHP framework to build web applications and that is quickly gaining popularity. I wanted to test it to keep up to date with this current technology. So I thought: I will build a concept in Laravel to see how it works and to compare it with Drupal 8.

My goals:

  • A static page in which the content is loaded from a local database.
  • Build a list of Blog items which is fed from a Drupal 8 RESTful API (which I had previously built for Node.js).

Overall content of this blog:

  1. Introduction to Laravel
  2. Laravel’s foundation
  3. Installing Laravel
  4. Routing in Laravel
  5. Laravel’s Migration: management of the database structure
  6. Eloquent ORM: query the database
  7. HTML templating in Laravel: Blade and Views
  8. Loading data from a RESTful Drupal 8 API

1. Introduction to Laravel

Required tools and knowledge

In order to participate you will need to have the following basic knowledge and tools:

  • PHP: intermediate knowledge
  • HTML/CSS basic knowledge
  • Good code editor (IDE), I am using PHPStorm
  • A browser, f.e. Firefox

What is Laravel

  • A PHP framework for web applications
  • Developed by Taylor Otwell
  • First release: February 2012
  • Open Source (MIT licence)

Why Laravel

According to the developers it is a ‘clean, modern web application framework’, which is built on other great tools. In addition, it is said that Laravel is ‘fun to code’.

Laravel is a MVC Framework

  • MVC = Model View Controller, a modern structure of web applications.
  • Model: application data and functionalities
  • View: the visible output, the HTML
  • Controller: interaction between user, model and view. Facilitated in Laravel by PHP.

Standard tools in Laravel

  • Routing of incoming requests
  • HTML templating (Blade)
  • Database definition and version control (Laravel’s Migrations and Eloquent ORM)
  • Authentication: login users and manage permissions.
  • Emailing with attachments

Laravel core is not a cms like Drupal 8

Laravel out of the box is not a cms. There is a cms component available (October cms), but in this regard Laravel cannot be compared with Drupal 8, which does offer in the core full blown cms functionalities. If you want to compare Laravel with Drupal, you will need to do this on the level of Drupal API and not Drupal cms.

2. Laravel’s foundation

Laravel’s foundation is built on strong components:

Laravel is a framework built on several other strong frameworks. Below an explanation of each component:

2.1 Laravel’s foundation: Symfony

Symfony is one of the main components in Laravel. The following Symfony components are, among others, used in Laravel:

Future releases of Laravel
 Laravel has announced to stay in sync with future releases of Symfony.

Symfony users
 When you are a user of Symfony you can also use Laravel components.

2.2 Laravel’s foundation: Composer

Laravel uses Composer, a PHP dependency manager. The main features are:

  • Works on a ‘per project’ basis, not global.
  • Works on Mac, Windows and Unix.
  • The dependencies are defined in a JSON file: composer.json. Composer can also be used in Drupal 8. This approach is also similar to the package.json in Node.js where NPM is ‘acting’ as Composer, see also.
  • See Packagist.org for 3rd party packages that can be used in Laravel by installing them through Composer.

2.3 Laravel’s foundation: Eloquent ORM

Eloquent ORM is Laravel’s database component, similar to the Database abstraction layer in Drupal 8. ORM is an acronym for Object Relational Mapper. It has been developed for Laravel, but can also be used outside Laraval. It is using an Active record pattern for database CRUD actions. It can facilitate one-on-one, one-on-many and many-on-many relations.

2.4 Laravel’s foundation: Migrations

Tables can be created, structured and (version) controlled through Laravel’s Migrations. All this is done via code, not configuration.

2.5 Laravel’s foundation: Blade

Blade is Laravel’s html templating machine. A Blade file is saved with the extension ‘.blade.php’. Variables in the template file can be placed as follows: {{variable}} (XSS filtered) or {!! variable !!} (unfiltered, [!] only use this when you know exactly what you are doing). You can also use PHP functionalities and codes in blade files. Blade also supports subtheming and conditional controls.

3. Installing Laravel

I am working on a Mac with OS X El Capitan. The current Laravel version is 5.1, and that is the version I am going to use. Go to Laravel docs and follow the instructions:

  • Make sure you have installed Composer.
  • Make sure the directory ~/.composer/vendor/bin is in your PATH, so that the laravel command is everywhere available. Learn here how.
  • Now you can install via the command laravel new a fresh Laravel installation. I am now going to my webroot and enter laravel new blog concept: a fresh Laravel installation will be created in the folder /blogconcept:

The created install:

  • You will get an ‘application key’. This will be used, among other things, to encrypt data, such as session data.
  • Go to the Laravel installation and run this command: php artisan serve to activate the Laravel server. Artisan is Laravel’s command line environment.

Go to your browser and navigate to http://localhost:8000. You should be seeing this:

4. Routing in Laravel

Routes are used to facilitate incoming page requests. This is similar to Drupal 7’s hook_menu() and Drupal 8’s routing system. The routes can be found in /app/Http/routes.php:

Static routes
 In routes.php you will see the default homepage defined, which you saw above in the browser. Here you can add your own routes. Below an example of a page with static information:

In a browser:

Dynamic routes
 Routes can also be built dynamically through working with variables:

Note the double quotes that are required to dynamically print out the variable. If you are using single quotes, Laravel will print literally {$person}.

In the browser:

5. Laravel’s Migrations: management of the database structure

First you will need a database, the standard used here is MySQL; I will make a database called ‘blog concept’. All the database settings are in config/database.php:

In this file you can set:

  • Fetch style
  • Type database: mysql is the standard, but Laravel also supports sqlite, pgsql and sql server.
  • The database connections, I am entering the following:

Tables can be managed manually through for example phpmyadmin, but that is not advisable. In Laravel the structure of tables/database can be programmed in code, resulting in flexibility and version control. ‘Database structure’ is also called ‘schema’.

By managing this in Laravel’s Migration developers can easily keep their databases in sync within a version control system, such as GIT. So you can also easily revert a database change.

Example: I am creating the initial migration file through command php artisan make:migration create_content_table. In the created file I am adding code that defines database tables:

This migration class exists of two methods: up and down. Up is used to create new tables, down is used to make the Up actions undone.

Execute command php artisan migrate, that will apply the migration code, and voila: the database tables are created:

More information: http://laravel.com/docs/5.1/migrations

6. Query the database with Eloquent ORM

For now I have manually filled the newly created tables with test content. Below a simple example to query this data:

  • Create a Model: php artisan make:model Content
  • Laravel creates the model in the /app folder:
  • The model is called ‘Content’ and not ‘Contents’, Laravel is smart enough to make that connection by itself.
  • Add the following code in routes.php:

$content = App\Content::find(1) => This is all it takes to query record with id=1 from the database table 'Contents', also here Laravel is smart enough to make the link with ‘Contents’. Then, all the fields from that record are stored in object $content, which can be assigned as variables to a blade template.

More information: http://laravel.com/docs/5.1/eloquent#defining-models

7. HTML templating in Laravel: Views & Blade

As previously indicated the HTML templating engine Blade is used in Laravel. The HTML files are called views, something else than Drupal Views: these are lists. An example of the use hereof can be seen immediately in the standard installation. In routes.php on line 15 the Laravel view ‘welcome’ is invoked: return view(‘welcome’);.

The views are included in the folder /resources/views, there you can also find the standard view ‘welcome.blade.php’:

An own dynamic view

Blade facilitates dynamically filling HTML pages. An example: I am creating a new view file called ‘about.blade.php’ and copy the HTML from welcome.blade.php:

I am adding the following code in routes.php:

You can see that the ‘about’ view is evoked through View::make() with an additional array included in which variables with content are defined that were previously loaded from the database.

Then I can use those variables in the Blade template:

In the browser:

FYI: more about Blade templates.

8. Data from a RESTful Drupal 8 API

As an example I am using the Drupal 8 API that I built earlier. The json output is looking like this:

First I played a bit around with Composer packages Buzz & Guzzle, both http clients. Those packages are facilitating much more than just retrieving data from a REStful API: POST requests, streaming large uploads, streaming large downloads, using HTTP cookies, uploading from JSON data, etc…

That is too much overhead, for now I can work with a standard php functionality: file_get_contents en json_decode:

  1. Create a new route: /blogs
  2. Query the json data from the external Drupal 8 RESTful API.
  3. Run through the json arrays data and create a new array where: key = url, value = blog title
  4. Render the Blade html view ‘blogs’.

Then I am copying an existing blade view and rename it to ‘blogs.blade.php’:

In this blade html view I am running through the associative array and am creating in this way a list with links:

Creating the detail page of a blog

Finally I would like to accomplish that when I click a link, the detail page of that blog appears:

  1. Create a new route with a variable
  2. Request the data from the Drupal 8 RESTful API.
  3. Look for a match in the url variable and a url in the json array from the API.
  4. When a match is found, create the variable: the title and body from the matched item.
  5. Render the html through a blade view.

In a browser:

As you can see, a lot still needs to be done concerning the styling. But as a purely functional concept, I am leaving it now the way it is.

Wrap up

Ok, that’s it for now. This is only an introduction in which I produced a concept. Many advanced components of Laravel have not yet been discussed, such as incorporating the logic code /routes.php that I placed to Models and Controllers. I would like to discuss this further in a next blog. Questions or feedback, let me know!

— Cheers, Joris

Sep 19 2017
Sep 19

We got a lot of questions last year like: can I build a new project on Drupal 8? What do I have to do with my Drupal 6 install when Drupal 8 is released? Do I have to upgrade my Drupal 7 install when Drupal 8 is stable.

We see these sorts of questions more and more, because Drupal 8 will have a stable release in the foreseeable future. And that means end of life for Drupal 6. So what to do?

Drupal 8

You want to live the future without dragging the past behind you, Drupal 8 does that very well. It’s completely rebuild from the ground up and has a lot of cool features:

Drupal 8 is not backward compatible, I think that’s a good thing: you don’t want to drag legacy stuff behind you. That’s a big bucket on your boat.

So is it necessary to upgrade your current Drupal 6 or Drupal 7 to Drupal 8? Considerations for:

  1. Drupal 6 to Drupal 8
  2. Drupal 6 to Drupal 7
  3. Drupal 7 to Drupal 8
  4. Tools for upgrading to Drupal 8

Difficult process?

Generically spoken, to what degree a Drupal upgrade process is difficult depends on the initial Drupal website builder. If that party knew what they were doing and took a future upgrade into account, than I guess you’ll be quite safe. But if that party duct-taped and Cable tied your Drupal site… then you might have a bigger challenge.

1. Drupal 6 to Drupal 8

Drupal 6 — RIP (almost)

Community support for Drupal 6 ends when Drupal 8 gets released, just like with Drupal 5. If you are running on Drupal 6 it won’t say ‘kaboom!’ immediately, but you should have a plan to upgrade to 7 or 8.

Drupal 6 site data (source):

About 20% of total Drupal sites is Drupal 6. Good to know: Drupal 6 will have 3 additional months of security support when Drupal 8 is released. So Drupal 8 modules can mature some more and an upgrade will be smoother. See also.

Simple Drupal 6 websites

With a simple Drupal 6 website I mean a ‘brochure’ website. In this website you have a couple dozens of pages with some static information and maybe a blog about your organization, company or personal activities. So there are no complex functions like an online community, webshop or social intranet/extranet. The project costs initially were 40~200 hours.

If you have such a Drupal 6 ‘brochure’ site, then Drupal 8 will probably be a good candidate, as it has a lot of features out of the box and chances are you can don’t need extra modules. So upgrade to Drupal 8 asap will probably the best step.

More complex Drupal 6 websites

A more complex Drupal 6 website would be an online community, a webshop or a Drupal social intranet. There are contrib modules installed and additional custom modules. The project costs initially were more than ~ 300 hours.

In this case you probably need extra modules in Drupal 8 to migrate your system. When those modules are not yet migrated then you can wait for them. But it’s kind of uncertain when they will be migrated and stable. A status overview of Drupal 8 modules.

When it’s clear that the needed modules will be ported to Drupal 8 in the foreseeable future then maybe it’s best to wait for that and migrate asap after those modules became stable. If they are not migrated in the near future, then take a look at what Drupal 7 has to offer (see below).

If your needed functions are also not available in Drupal 7 modules, then you have to build it custom. It’s seems wise to do that in Drupal 8.

2. Drupal 6 to Drupal 7

When Drupal 7 was released, we waited a few months with migrating Drupal 5 and 6 sites. As soon as the necessary modules were ported we upgraded the sites.

Drupal 5 data (source):

If you can’t wait until the necessary modules are ported to Drupal 8, then upgrading your Drupal 6 system to Drupal 7 is an option. Of course the modules must be available in Drupal 7, stable.

Drupal 8 is almost 5 years in development, if this continues then Drupal 7 will be supported for a long while. Including the extra 3 months security support Drupal 7 will be supported until ~ 2019. This is a rough estimate; Drupal 9 will probably not be in development for 5 years, since it will not be build from the ground up.

3. Drupal 7

Al lot of arguments described above also apply to a Drupal 7 website. It really depends on the complexity of your system: how much custom and contrib modules you implemented. The more complex the site, the less smooth an upgrade to Drupal 8 will be.

Since Drupal 7 probably will be supported for the next 3~4 years, I see no maintenance reason to switch to Drupal 8. But if you want to use all cool new features of Drupal 8 then upgrading if worth the consideration.

4. Tools to upgrade to Drupal 8

Drupal 8 core ships with a migrate module with an import API. This takes care of a lot of upgrading stuff, see Drupal IMP group

If you have a Drupal 6 or 7 install with little active modules then chances are those modules won’t be available in Drupal 8 in near future. So maybe then you’ll have to do the upgrades on your own.

Here are some resources that can help you with upgrading your modules and content to Drupal 8:

Everything You Need to Know About the Top Changes in Drupal 8:

Wrap up

So, malheureusement, there is no óne answer to the question: ‘when and how do I need to upgrade to Drupal 8’. It really depends on the complexity of your Drupal system. An analysis of your current system will be needed. You’ll have to compare your system with Drupal 7 and 8 core + available contrib modules.

Questions, feedback? Let me know in the comments!

Source header image

Sep 18 2017
Sep 18

So…. Drupal 8 got released! Congrats everybody! The end of life of Drupal 6 is then final. In addition, the 16th of november it was announced that Drupal.org is now serving its content and files via Fastly; which is giving a significant performance boost, well done!

Furthermore, what I noticed last month on module updates:

1) Scroll to destination anchors

This module modifies the behaviour of an ‘anchor’ within a page. So the page will not jump down but fluently scroll down. We have installed this module here.

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

2) Spider Slap

There are a lot of ‘evil spiders’ active on the internet. These are web crawlers that don’t respect what is written in your robots.txt. This can cause unnecessary load on your server and uncover information that you don’t want to see in a search engine.
 This module is solving this problem. It will block the IP when a spider does not behave, with as a result that it will no longer have access.

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

3) Bounce Convert

Do you want to make an announcement in the last moment before a visitor is closing your Drupal website? Then this module can be useful. It functions like Exit monitor or Bounce Exchange.

Introduction video.

!) Note that it is currently an alpha module, so not yet suitable for live Drupal sites.

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

4) Database Email Encryption

Do you want to maximise the security of the email addresses of your registered users? This is possible with this module. It encrypts the addresses in the database. Should the database end up in the wrong hands, then the email addresses cannot be read. Encryption is done using AES.

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

5) Unique field

A popular module existing since Drupal 5, but I never noticed it before. It is performing a check on entered fields (e.g. title field) and checks whether the entered title is unique. This will prevent the use of double titles which is good for, among others, SEO.

6) Login History

By default Drupal is not creating a login archive. This module will do this for you: it creates an archive in which the history of logins will be stored.

https://www.drupal.org/project/login_history Similar:

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

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

7) Sitemap

Generates a sitemap for your Drupal 8 website and can also create RSS feeds for example for your blog. This is the Drupal 8 version for the popular Drupal 7 module Sitemap.

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

8) D8 Editor File Upload

Easily place files in content. This Drupal 8 module adds a new button to the editor, which will make it easy to upload and place files.

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

9) Client side Validation

Validating a form in your Drupal website without refreshing the page. This widely used module now offers a Release Candidate for Drupal 8.

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

10) App Link

Probably you recognize this one: the message above a website on your Smartphone that you can view the page in a native app. If you built and linked an app (e.g. via DrupalGap) then you can generate this ‘app message’ on your Drupal website using this module.

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

11) OpenLucius News

An own module that has to be mentioned;). This module extends Drupal social intranet OpenLucius with a ‘news tab’ on the homepage. News about the organization can be placed here.

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

12) Simple XML sitemap

The title of this Drupal 8 module says it all: it provides an XML sitemap that you can upload to search engines, so you can see the indexation of all your site links in the relevant search engine.
 The module also has a few configuration options like setting ‘priority’.

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

13) Session Limit

Tighten the security of your Drupal system by limiting the number of sessions with which a user is logged in. You can for example set that somebody can be logged in once; if somebody is logging in on his/her Smartphone then he/she will be automatically logged out on the work computer.

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

14) Login Security

Provide additional security when logging in, it is for example possible to:

  • Set how many times a user can attempt to log in before the account is blocked.
  • Deny access based on IP, temporarily or permanently.

The module can also send emails (or a log to Nagios) to alert the Drupal administrator that something is going on:

  • It seems that passwords and accounts are guessed.
  • bruteforce attacks or other inappropriate behaviour when logging in.

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

15) OpenLucius LDAP

Another own module, that should be mentioned as well ;-). This module extends Drupal social intranet OpenLucius with a LDAP connection, so that users can login to OpenLucius with their existing LDAP account.

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

16) Protected node

Gives additional protection to a certain page (node). A password can be set when creating the node. If somebody then wants to look at the node, the password must be entered to get access.

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

17) Code per Node

It is common to ‘deploy’ Drupal code (PHP, JS, CSS) via GIT within an OTAP street to a live Drupal server. Usually with the use of a Continuous Integration tool.

[edit] As Eelke mentioned in the comments below: OTAP has to be DTAP for English audience. [/edit]

But with this module you can perform quick fixes per page without the whole operation. It offers the opportunity to add additional CSS; per node, content type, block or global.

Not how we would do it, but I can imagine that this could be a handy tool for Drupal site builders. This is probably also the reason why it is so popular.

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

18) Admin Toolbar

A handy toolbar for Drupal 8

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

Wrap up

Alright, these are the modules for this month. In December we will introduce again new ‘cool Drupal modules’, so stay tuned!

Sep 18 2017
Sep 18

So, like a bunch of other Drupal people, we’re also experimenting with Drupal 8; for our Drupal distro OpenLucius. Us being ‘less is more’-developers, one aspect we really like is dependency injection.

First things first, for all new developers we should explain exactly what dependency injection is. Dependency injection is an advanced software design pattern. It implements “inversion of control”, this sounds complex but it basically means that reusable code calls task specific code. (Reference: http://en.wikipedia.org/wiki/Inversion_of_control)

What does this mean for us Drupal developers?
It means we can write more efficient code by reducing the load. We only load what we need.

Types of injection

There are multiple types of Dependency injection:

  1. Constructor injection, where the dependency is injected through a class’s constructor.
  2. Setter injection, where the dependency is injected through a setter method of a class.
  3. Property injection, where a public field of a class is directly set.

All three methods have their pro’s and con’s I’ll try to explain these three in detail.

1. Constructor injection

There’s no real downside to using constructor injected dependency injections. The advantages are:

  • Constructor injection can ensure that a class cannot be constructed without a required dependency.
  • The constructor is only called once so the dependency cannot be altered afterwards

These two advantages do not limit the ability to use optional dependencies; these can be implemented using one of the other methods. It does however tend be a bit more difficult to extend the class or override the constructor.

Simple example of constructor based injection:

class SimpleClass { protected $variable; public function __construct(\SimpleType $variable) { $this->variable = $variable; } }

As you can see the SimpleType class is injected into the protected variable of the SimpleClass. Basically that’s all you have to do to :)

2. Setter injection

This type of dependency injection is often used for optional requirements as the only thing you have to do to prevent adding a dependency is not calling the setter.

The advantages are:

  • The above-mentioned, setting of optional dependencies.
  • You can call a setter method multiple times. This also allows you to add multiple dependencies using only one method.

The downsides are:

  • The setter can also be called after the construction of the object. Therefore you can’t guarantee that a dependency is not replaced.
  • You can’t be certain that a setter is called at any moment in time. So you have to implement a method to verify if a dependency is indeed injected.

Simple example of setter-injection:

class SimpleClass { protected $variable; public function setType(\SimpleType $variable) { $this->variable = $variable; } }

3. Property injection

Injecting directly into class objects is not advisable but there’s a small possibility that a thirdparty library implements public properties.

The downsides are:

  • There is no way of controlling whether a dependency is set. It can be changed at any point.
  • You can’t use type hinting to verify what type of dependency is injected. (type hinting is a way of ensuring that an object is of a certain type. For more information have a look at the phpdocs http://php.net/manual/en/language.oop5.typehinting.php)

Simple example of property injection:

class SimpleClass { public $variable; }

Dependency injection Drupal

All of this was PHP dependency injection, which can be easily implemented in Drupal 8. I’ll show two simple ways to implement these three methods, which can be downloaded as an example module at the bottom of the page. I’ll show a direct approach to using these 3 methods and a service-based approach. Both are quite simple to implement.

For demonstration purposes i’ve created simple module containing the four classes now properly named in a namespace called ‘Drupal\dep_test’ where dep_test is the name of the module. The classes are now distinguishable from each other:

  • SimpleClassConstructor
  • SimpleClassSetter
  • SimpleClassProperty
  • SimpleType

Within this module I’ve added a simple Controller, which makes it easy to display values. In the controller class I’ve added the following code for a direct approach:

// Initiate the Classes. $this->constructor = new SimpleClassConstructor(new SimpleType()); $this->setter = new SimpleClassSetter(); $this->property = new SimpleClassProperty(); // Inject dependencies. $this->setter->setType(new SimpleType()); $this->property->variable = new SimpleType();

As you can see a direct approach is quite simple to implement. Now we’re going to use a service based approach. For this we’re going to use a services.yml file.

This file contains the services and the function calls / properties to be set.

services: deptest.simple_type: class: Drupal\dep_test\SimpleType deptest.constructor: class: Drupal\dep_test\SimpleClassConstructor arguments: ['@deptest.simple_type'] deptest.setter: class: Drupal\dep_test\SimpleClassSetter calls: - [setType, ["@deptest.simple_type"]] deptest.property: class: Drupal\dep_test\SimpleClassProperty properties: variables: "@deptest.simple_type"

From top to bottom:

  • We define the simple_type service and tell, which class should be used.
  • We define the constructor service, set the class and give the simple_type class as an argument.
  • We define the setter service, set the class, set the function call and the argument for the function call.
  • We define the property service, set the class and set the property to the simple_type class.

Now if we call one of these services using the service container all properties will be set, just like the direct approach.

$this->service1 = \Drupal::service('deptest.constructor'); $this->service2 = \Drupal::service('deptest.setter'); $this->service3 = \Drupal::service('deptest.property');

Calling the service container directly is not advisable but for demonstration purposes it should suffice.

The end

That’s about it for this blog item. I hope it helps someone. Don’t forget to download the full package and have a look at the code.

Sep 18 2017
Sep 18

Search engine optimisation (SEO) has always been important, but in recent years its importance seems to have increased significantly. We were more often dealing with Drupal SEO implementations than in previous years. Many of the implementations contained overlapping components. Below we will discuss the most important ones:

1. Speed

Google Page Speed is a good indicator of how speed is experienced by end users and therefore by Google. Google attaches great importance to speed because end users are simply doing the same.

An example of a test of the front page of this site:

As you can see we can further optimize mobile and desktop by following the instructions provided. Although on our Dutch blog we have a Node.js frontend (and a headless Drupal 8 backend) a Drupal frontend can be tested as well with the Google Page Speed tool. The tool is testing, among others, the following:

  • JS and CSS aggregation and minimize (minify)
  • GZIP / browser caching
  • Optimized images
  • Landing page redirects
  • Prioritize visible content
  • User experience issues, for example the use of non generic plug-ins.

2. Schema.org

Schema.org is a collaboration between Google, Yahoo! and Bing to standardize the way data is structured in web pages. By using these standards these search engines are ‘snapping’ the content of your web page better, resulting in a significant SEO boost.

The schema.org library contains descriptive tags for content like films, persons, organizations, events, locations, etc. The purpose of the search engine is to make search results more clear, allowing people to easily find the right web pages.

3. Mobile compatible / responsiveness

2015 brought us mobilegeddon: if your website is not mobile ready then Google will appoint you penalties resulting in a lower ranking. And rightly so, a large part of the website visitors are using internet on their mobiles; and you would like to give them a good experience. You can test here if your website is mobile compatible.

4. Google Webmaster Tools / Search console

Essential SEO tool, sign in here and register your website. Then it is important to upload a XML sitemap. The Drupal module XML sitemap will help you with this. Once you have done that, you will be able to see how your website is ranking in the organic results of Google:

  • Which keywords enable your pages to be found in the search results.
  • What are people really clicking so that they land on your website.
  • Errors on your website.
  • Links that are not correct.
  • Links that are not accessible.
  • Schema.org implementation: how is Google treating the enriched html pages.

See below for example the dashboard of this website, with links unfolded and all the insights you can find here:

5. Write good, long content

Apparently Google is rating your Drupal website higher when you are publishing long and good quality content. Long and good pieces of content are also adding to the acquisition of new clients:

  • You have something valuable to promote on social media.
  • You have an excuse to reach out to your potential customers.
  • Visitors are staying longer on your website.
  • You are creating authority.

Read here more details about the how and why.

Areas of importance when writing content

  • Backlinks, make sure you get links on other websites that are highly rated.
  • Limit the number of relevant internal and external links, so that Google (and the — visitor) can better understand the context of your article.
  • Analyze the (successful) competitors: discover where they are, what they link and how they dominate social media.
  • Make sure your blog website is coherent, not a website with islands where non-cohesive content is separated from one another.
  • Update regularly: check for example once every month your articles and improve where appropriate: cohesiveness, spelling mistakes, new insights, etc.
  • Allow visitors to place comments using Disquss that has become a social media platform where you can attract inbound links.

Useful Drupal SEO modules

6. Page title

By default Drupal has one field to enter the title of an article. This title is used for both the page title as the ‘html title’:

The html title is important for SEO; usually you would like to define it differently than the readable title of the article (as the visitor is viewing it). This module is solving this problem and allows you to manage two titles individually.

You can also give the HTML title a particular predefined format so that it is created depending on the content type. For example “Blog Lucius | 18 Drupal SEO modules and tools for better findability in Google”. Where ‘Blog Lucius’ is always automatically stated in the beginning of the title with a pipe (‘|’) in between.

Download and more info on Page Title — (Drupal 7 — Drupal 8 info)

7. Metatags

Years ago meta keywords were one of the most important elements used to be found. But not anymore, Google is finding your Drupal site mainly with content and links to your pages. The meta keywords are still important but mainly for:

Indicating snippets
 The (summary) text about your page that will appear in the search engine:

Open Graph implementation
 Rapidly emerging technology, important for previewing your page on social media and now also in for example Gmail:

Download and more info on Metatag — (Drupal 7 & Drupal 8)

8. Pathauto & Subpathauto

Pathauto is a widely used Drupal module: it converts standard Drupal (/node/123) links to readable links (/news/this-is-a-news-item). Useful for your visitors and thus for Google.

Download and more info on Pathauto — (Drupal 7 & Drupal 8 dev)

Subpathauto is an extension of Pathauto: it recognizes sub-paths and automatically generates associated paths.

Download and more info on Sub-Pathauto — (Drupal 7)

9. Pathauto persistent state

The popular Drupal module Pathauto is useful for automatically creating nice URL’s. It is also possible to exclude particular content from an ‘automatic alias’ and then manually enter the URL.

Pathauto sometimes ‘forgets’ that the URL of certain articles was manually set, and creates them again automatically. As a result the URL of your page could change without you realizing it, not handy..

This Drupal module is solving this problem: it makes sure that Pathauto remembers for which articles you have turned off ‘automatic alias’.

Download and more info on Pathauto persistent state

10. Global redirect

Avoid duplicate content. Ensures for example that ‘node/123’ is no longer available, but only the search engine friendly URL. It also checks if clean URL’s are enabled and checks whether visitors have access before performing a redirect.

Download and more info on Global Redirect — (Drupal 7 — Drupal 8)

11. Redirect

It can happen that the title of an article needs to be changed, usually the URL is changing then as well. This module creates a 301 — Permanent redirect so that the users from an old URL are automatically redirected to the new path. This way Google also knows that the new URL needs to be indexed and that the old one can be removed.

Download and more info on Redirect — (Drupal 7 — Drupal 8 info)

12. XML sitemap

Necessary for an insight into your Drupal pages in Google’s Search console, see ‘Google Webmaster Tools / Search console’ above for more information.

Download and more info on XML sitemap (Drupal 7, Drupal 8 info).

13. HTML Purifier

Can clean the HTML of content so that it continues to comply with the W3C standards.

Download and more info on HTML Purifier — (Drupal 7, Drupal 8 info ).

14. Search 404

A standard 404 page (‘page not found’) is providing rather brief information for your visitor. This popular module is changing this: it does not show a static page, but will search in your Drupal system and will show visitors results of pages they might have been searching for.
 This feature will also have a positive influence on the SEO of your Drupal system.

Download and more info on Search 404 (Drupal 7 & Drupal 8)

15. Site verify

Useful mini module to verify your site in Google’s webmaster tools.

Download and more info on Site verify — (Drupal 7, Drupal 8 info).

16. Link checker

Analyse your content and detect dead links, important to fix them for your visitors and thus for Google.

Download and more info on Link checker — (Drupal 7, Drupal 8 info).

17. Taxonomy Title

Similar to the previously mentioned ‘Page title’, using this module you can among others change the (html) page title per term / tag.

Download and more info on Taxonomy Title — (Drupal 7)

18. Menu attributes

Add html elements to menu links: id, name, class, style and rel. This allows you to add among others ‘rel=nofollow’ to design the flow of links in your website better.

Download and more info on Menu attributes — (Drupal 7, Drupal 8 info).

Wrap up

Ok, enough SEO for now, hopefully you are not immediately conquering our ranking in Google ;-) Questions or feedback? Let me know in the comments.

Sep 18 2017
Sep 18

The Bootstrap HTML framework in Drupal, we love it. That’s why we build the front-end of Drupal distribution OpenLucius with it. So we love it, but why is that?

There are alternatives to integrate in Drupal websites. Below we will give you a few reasons why we currently prefer the Bootstrap framework.

Why a HTML framework

First of all, why should you use a HTML framework? These possibilities also exist:

1) Write everything fully by hand:

Nowadays responsiveness is required with almost every new website. Bootstrap is offering cross-browser compatibility for this. To build the required responsiveness every time from scratch would make no sense.

2) Ready-made Drupal themes

You can download free Drupal themes or buy them ready-made. This will take you quickly in the right direction, but ‘the devil is in the details’. The final details are usually difficult, but necessary to make your desired layout. The problems are usually caused by not knowing the code and the code is often not scalable designed for your purposes. It can become a kind of Rube goldberg machine to you.

Why Bootstrap

So a HTML framework is our weapon of choice. Specifically Bootstrap, 5 reasons why:

#1) Good documentation

It has become a widely used framework in Drupal. The Drupal Bootstrap base theme has currently almost 300.000 downloads and 50.000 installations. It is not only used in the Drupal community, other popular CMS systems, like Wordpress, also make extensive use of it.
As a result of this broad implementation, a lot of documentation is available and most questions are already answered on forums like StackOverflow.

#2) Good Drupal integration

Since we are a Drupal shop, scalability and flexibility of the integration are necessary. And of course this is offered, the technique of Drupal Bootstrap basis theme is excellent. It is even integrated with Bootswatch themes, so you can instantly choose from 14 ready-made templates.

We are gratefully using this in our Drupal distribution OpenLucius.

#3) Many ready-made free templates

Because it is used worldwide, there are many websites that offer paid and unpaid Bootstrap HTML templates, for example:

#4) Many components (snippets) are already available

Websites usually consist of similar content: homepage, list pages, news items, blog, contact, drop down menu, slider with pictures etc. But also think of elements such as a profile page, a timeline, or a login screen.
There are many websites that offer such components (snippets) within the Bootstrap HTML framework. Some examples:

A timeline

A profile page

A useful dropdown selector with filter function

We have used these in OpenLucius:

Data tables

Data tables are providing performance optimalisation compared to standard Drupal Views. Data tables are loading all ‘tabular data’ and creates pages using jQuery. This will make a difference in the server requests when requesting each new page.

#5) Integrates with WYSIWYG

When you are working with content managers, you like them to see the text format as the visitor gets to see them. In other words: the text in the wyiwyg editor must be consistent with the front end. With Bootstrap this is relatively simple.

Relevant Drupal modules

Get started with Bootstrap in Drupal, this will give you a kick start:

And many more. Not everything in this list is bootstrap integration, it also contains results of modules that say something about ‘Drupal’s bootstrap process’. But that’s another chapter :)

Wrap up

Alright, that’s it. As always, don’t hesitate to contact me in case of questions or feedback!

— Cheers, Joris

Sep 16 2017
Sep 16

While preparing for my DrupalCamp Belgium keynote presentation I looked at how easy it is to get started with various CMS platforms. For my talk I used Contentful, a hosted content as a service CMS platform and contrasted that to the "Try Drupal" experience. Below is the walk through of both.

Let's start with Contentful. I start off by visiting their website.

Contentful homepage

In the top right corner is a blue button encouraging me to "try for free". I hit the link and I'm presented with a sign up form. I can even use Google or GitHub for authentication if I want.

Contentful signup form

While my example site is being installed I am presented with an overview of what I can do once it is finished. It takes around 30 seconds for the site to be installed.

Contentful installer wait

My site is installed and I'm given some guidance about what to do next. There is even an onboarding tour in the bottom right corner that is waving at me.

Contentful dashboard

Overall this took around a minute and required very little thought. I never once found myself thinking come on hurry up.

Now let's see what it is like to try Drupal. I land on d.o. I see a big prominent "Try Drupal" button, so I click that.

Drupal homepage

I am presented with 3 options. I am not sure why I'm being presented options to "Build on Drupal 8 for Free" or to "Get Started Risk-Free", I just want to try Drupal, so I go with Pantheon.

Try Drupal providers

Like with Contentful I'm asked to create an account. Again I have the option of using Google for the sign up or completing a form. This form has more fields than contentful.

Pantheon signup page

I've created my account and I am expecting to be dropped into a demo Drupal site. Instead I am presented with a dashboard. The most prominent call to action is importing a site. I decide to create a new site.

Pantheon dashboard

I have to now think of a name for my site. This is already feeling like a lot of work just to try Drupal. If I was a busy manager I would have probably given up by this point.

Pantheon create site form

When I submit the form I must surely be going to see a Drupal site. No, sorry. I am given the choice of installing WordPress, yes WordPress, Drupal 8 or Drupal 7. Despite being very confused I go with Drupal 8.

Pantheon choose application page

Now my site is deploying. While this happens there is a bunch of items that update above the progress bar. They're all a bit nerdy, but at least I know something is happening. Why is my only option to visit my dashboard again? I want to try Drupal.

Pantheon site installer page

I land on the dashboard. Now I'm really confused. This all looks pretty geeky. I want to try Drupal not deal with code, connection modes and the like. If I stick around I might eventually click "Visit Development site", which doesn't really feel like trying Drupal.

Pantheon site dashboard

Now I'm asked to select a language. OK so Drupal supports multiple languages, that nice. Let's select English so I can finally get to try Drupal.

Drupal installer, language selection

Next I need to chose an installation profile. What is an installation profile? Which one is best for me?

Drupal installer, choose installation profile

Now I need to create an account. About 10 minutes I already created an account. Why do I need to create another one? I also named my site earlier in the process.

Drupal installer, configuration form part 1 Drupal installer, configuration form part 2

Finally I am dropped into a Drupal 8 site. There is nothing to guide me on what to do next.

Drupal site homepage

I am left with a sense that setting up Contentful is super easy and Drupal is a lot of work. For most people wanting to try Drupal they would have abandoned someway through the process. I would love to see the conversion stats for the try Drupal service. It must miniscule.

It is worth noting that Pantheon has the best user experience of the 3 companies. The process with 1&1 just dumps me at a hosting sign up page. How does that let me try Drupal?

Acquia drops onto a page where you select your role, then you're presented with some marketing stuff and a form to request a demo. That is unless you're running an ad blocker, then when you select your role you get an Ajax error.

The Try Drupal program generates revenue for the Drupal Association. This money helps fund development of the project. I'm well aware that the DA needs money. At the same time I wonder if it is worth it. For many people this is the first experience they have using Drupal.

The previous attempt to have simplytest.me added to the try Drupal page ultimately failed due to the financial implications. While this is disappointing I don't think simplytest.me is necessarily the answer either.

There needs to be some minimum standards for the Try Drupal page. One of the key item is the number of clicks to get from d.o to a working demo site. Without this the "Try Drupal" page will drive people away from the project, which isn't the intention.

If you're at DrupalCon Vienna and want to discuss this and other ways to improve the marketing of Drupal, please attend the marketing sprints.

Share this post

Sep 15 2017
Sep 15

Have you decided to move your website from Wordpress or Joomla to Drupal? Or maybe you are looking to upgrade Drupal 6 or 7 to Drupal 8?  If you answered ‘yes’ to either one of those questions, then a Drupal migration is the next step for you.

Excellent choice!

We know it wasn't easy for you to finally make this decision. We also understand that you now face a major challenge.

Drupal is a scalable and flexible solution that can be moulded into anything you need it to be. It has enterprise-level security and an innovative modular-type system. It also has a steep learning curve because of everything you can do with it. Because of this, it requires Drupal specific developers who have to know how to use it to its full potential. 

Optasy is here to make this transition smooth and time-effective. The goal is to have the least amount of impact on your company's daily activities as possible. Downtime = lost revenue and we don't want that to happen. 
 

Steps To Migrate Your Website To Drupal

  • Step 1: Your website will undergo a rigorous analysis. Our team of Drupal experts will take a close look at your current system's database. We perform functionality tests and deeply analyze the current framework. We then come up with a customized solution specific to your company's website needs.
     
  • Step 2: Decide which modules and design theme your current website can migrate to Drupal. Then we figure out which ones we'll develop from scratch and which ones simply need an upgrade.
     
  • Step 3: Once planning and analysis are complete, the migration of your website's components begins. This includes content, your database, usernames, emails, plugins, extensions and user groups. It also includes metadata so that you don't lose any previous SEO work completed. We handle this with the greatest caution. We secure your valuable data and make a smooth transition from one platform to another.

  • Step 4: Test, test and more testing. We test until we are 100% certain that your newly-built Drupal website runs perfectly. And with significantly improved performance.
     

A Smooth Migration Process

We guarantee you that the whole migration process will go smoothly. It won't interfere or slow down your team's workflow. It also won't cause any downtime on your website, so you won't lose out on profits. 

Our confidence relies on our access to using the best tools and resources. We also apply a proven efficient methodology based on many years of experience.

The migration process of your website happens on your server and behind the curtains. This guarantees zero impact on your daily workflow. It enables you to keep making sales or getting leads while your website migrates to Drupal's platform.
 

Benefits Of Optasy’s Drupal Migration Services

  • Faster website
  • Improve performance
  • No downtime
  • Experienced Drupal experts
  • Seamless data and content migration
  • Maintain SEO work previously completed
     

Upgrade To Drupal 8

Upgrading to the new Drupal 8 will make your website work (and look great) on any device. 

Some other key benefits of making the switch to Drupal 8 are:

  • Mobile-first ready. This version of Drupal has been designed to embrace the shift towards mobile.
  • Fully responsive web design right out-of-the-box.
  • Multilingual features. The platform is built to support any language.
  • Mobile friendly admin features. Now you can see everything right on your phone.
  • Supports mobile app development.
  • Easier to add content more than ever before.
  • Flexible content delivery. This enables you to create and deliver content to any channel, device, or application.
Sep 14 2017
Sep 14

UPDATE (Sept. 20, 2017): Drupal Commerce 2 has launched! Checkout our release day blog post and try a demo!

Hot off the press! Commerce Guys have announced the official launch date of Drupal Commerce 2.0, and it’s next week! That’s right, the first fully supported, stable release is upon us. When you ask? September 20, 2017. Put it in your calendar, grab a few wobbly pops, and get ready to celebrate!

A huge community effort

The development of Drupal Commerce 2 has been a major undertaking. The Commerce Guys and a huge number of individuals and agencies helped bring it to where it is today. Wow! That is an incredible community effort and really goes to show you just how strong the Drupal community is when focused together on a common goal.

To toot our horn a little bit, Acro has our developer hands in the pot too, and a lot of hands at that. As the Official North American Service Provider for Commerce Guys and North America’s #1 Drupal Commerce agency, our mission involves committing a ton of hours to help the development of Drupal Commerce. It’s our bread and butter, and we’re very excited to be at this point! Toot toot!

Celebrate with us!

We will definitely be geeking on the 20th with childish excitement! This has been a long time coming and it’s good to step back and enjoy the progress. If you’re in town, stop by! We’d love to show you around.

And it won’t just be us celebrating! A bunch of others around the world will be as-one. Here’s the list of all of the confirmed release parties. Get in touch with any of the following companies if you’re near by:

  • 1xINTERNET (Frankfurt, Germany)
  • Acro Media (Kelowna, BC, Canada)
  • Actualys (Paris, France)
  • Adapt (Copenhagen, Denmark)
  • Azri Solutions (Hyderabad, India)
  • Blue Oak Interactive (Asheville, NC, USA)
  • Circle WF (Pancevo, Serbia)
  • MD Systems (Zurich, Switzerland)
  • Motionstrand (San Diego, CA)
  • Ny Media (Trondheim, Norway; at Sept. 20th meetup)
  • Wunder (Helsinki, Finland)

DrupalCon Vienna

The Commerce Guys will be at DrupalCon Vienna later this month to show off the official release. So, if you’re in that area, or planning to attend, go see them! It’s taking place September 26-29, 2017.

A couple of our team will be there too. Our CTO, Shawn McCabe (smccabe) will be there. Feel free to contact us if you’d like to schedule in a meeting with him. We also have Vicki Spagnolo (quietone) and Rakesh James (rakesh.gectcr) there giving talks. Vicki and Rakesh will both be presenting on the topic of “Migrate Everything into Drupal 8,” which is now very relevant since both Drupal 8 and Commerce 2 will be officially released. Rakesh will also be giving a solo session on “Prophecise your phpunit tests”. Again, if you’re there, check it out!

Sep 13 2017
Sep 13

The Commerce Simple Order System (SOS) is a system that lets you place and manage orders through a simple UI. Drupal Commerce is powerful, flexible, complex and super awesome! However, the admin interface for creating and managing orders is challenging for a typical user and lacks simplicity. Ease of use was the primary goal when we designed the SOS interface. From creating a customer to making the final order payment, Commerce SOS has you covered.

A better order management UI

As the saying goes, innovation comes from necessity. And this simplicity was a necessity for one of our valuable clients who echoed the same sentiments; the order admin interface really needed a face lift. The current process of placing and managing orders was a bit frustrating and took a lot of effort.

There were many cases where customers were forced to call in and place phone orders because of issues they had placing it online. This was challenging right off the bat as the first thing our client had to do was find the cart of the customer. Most customers have no idea what their order ID is and it often took time and effort to locate it from the huge list of orders. Once they did locate it, the process got even more complicated. Is the customer a new user or an existing customer? If they were an existing customer, could the admin find them in the system? If not, they’d be creating another duplicate account for the same person.

Then there is the issue of making changes to the order, whether is was adding or removing products, applying discounts or shipping information. The whole process was simply too cumbersome. They wanted to cut down on the complexity and save their employees time and effort administering orders.

So, we put our heads together and came up with an admin ordering system that allowed them to do everything the current ordering system did, but in a simple and straightforward manner. Let’s take a look at what Commerce SOS has to offer.

Order ID visible to the customer

Imagine the same scenario where a customer calls your store and asks you to place an order for them. They might have already created a cart and the first thing you need to do is find the order. When Commerce SOS is enabled, the first thing the module does is add a header to the cart and checkout pages that displays the Order ID in big bold text. The customer will never have trouble finding it when you ask them what their cart ID is.

sos-01.jpg

Finding carts and orders

Now that we have the order ID, let’s look at the SOS to locate the order in the system. Commerce SOS comes with an order manager interface that lets you find orders based on a cart ID, order total, or customer email. In the image below we've found an order based on the Cart/Order ID.

sos-02.jpg

Once the system locates the cart you can Process Order, which essentially takes you to the SOS order edit page, or you can View the order, which takes you to the SOS order view page.

Anonymous customer management

Alternatively, if this order was an anonymous order you’d have a different set of links appear under the Operation column. One of those alternate links is Cust. Lookup. This button allows you to lookup a customer based on their email (as shown below), name, or street address and assign this anonymous order to that customer.

sos-04.jpg

Once you enter data in any of the fields the system will automatically find customers matching that criteria. The Use button will assign the order to that customer and take you to the SOS order edit page.

Another one of the alternate links, titled New Cust., gives you the option of creating a new customer and assigning the anonymous order to that customer. This link takes you to a page (shown below) where they can enter the details of the new customer, including billing and shipping addresses. The system creates the new user, sends them an email with a link to set their account password and assigns the order to the customer. Once done, you are taken to the SOS order edit page.

sos-05.jpg

Editing orders with ease

Many processes occur in the background when you’re using the SOS system, but you will not be bothered by any of them. Wit the SOS system you get a straightforward process to find a cart, assign the cart to a user either by creating a new customer or finding an existing customer, and continue to the SOS order edit page (shown below) which is where all the fun happens.

This page gives you a central place to manage the order. From here you can update the billing and shipping addresses using the UI, add products using the Find Products auto complete product search, update product quantity or remove entire products. You can also add discounts to each item, edit products, and change attributes and options like you would using the add to cart form. If certain product attributes or options cost extra, that extra amount will be updated in the product price as you select them.

sos-07.jpg

The vertical tabs below the product, shown in the image below, hold additional order management tools. You can add a fixed or percent discount to the entire order, search for coupons using an auto complete search and apply coupons to the order. You can select a shipping method for the order, add order notes, update the order status and modify any custom fields you have added to the order.

sos-08.jpg

The most powerful feature of the Commerce SOS module is the ability to modify the order and the order total continuously updates in real-time. The blue ribbon you see in the previous image is updated when a change is made. You can give the customer up-to-date information regarding order as you are making changes.

Finalizing the order

Once you and your customer are satisfied with the changes to the order, click on the Next: Review & Pay button. This takes you to the payment form (shown below) where you can collect credit information from the customer and process the payment. This can be a charge to a single credit card or charges to multiple credit card payments. If you have Commerce GC module enabled, the page will also display a gift card tab that will allow you to search and use gift cards as payments for the order. When payment is successfully processed, the system dynamically updates the remaining total you need to pay to complete the order, if applicable.

sos-09.jpg

Once the payment is completed, select the Finish: Pay Now button to immediately put the order in Pending state, adjust the stock levels, and send an order receipt to the customer. You can then fulfill the order as normal.

As you can see, we’ve just went from finding a user’s shopping cart, all the way to completing the entire checkout process with very few clicks. It’s a seamless process that keeps you moving through each step smoothly. We wanted this system to be one that could be used by everyone and anyone. Simplicity was our goal and we strongly believe that we’ve managed to achieve that with the Commerce Simple Order System module for Drupal Commerce 1.x.

Sep 08 2017
Sep 08

We think Drupal is the best CMS

Okay, we admit it. We love Drupal and have a bias towards it. We do know other CMS' (content management systems) have their benefits and purposes. But this post isn't about them. It's about why Drupal is the best.

Drupal isn’t for everyone. You do need a dev team to support your website to customize Drupal. And to be more specific, you need one that is well-versed in Drupal specific development

Every developer has his or her own personal favourites. After working on Drupal websites for many years, we have grown to love Drupal.

So here is our completely biased opinion on why Drupal is the best.
 

1. Drupal Is Customizable

Drupal allows for very high levels of customization. With Drupal, if you think it you can build it. The framework of the CMS itself never limits you.

With Drupal, it’s easy to customize your site to have app-like features. Websites have become more complex these days with a lot of various functionalities. Working with a flexible system has become important.
 

2. Some Of The Largest Sites Use It

Drupal is a powerful CMS, open source, that sites like Al Jazeera and The Economist use.

Drupal is structured like building blocks, which makes it flexible. The modular architecture makes it ideal to handle scale and continuous integration. Developers get more control over the code from the ground up (i.e. you can build anything).
 

3. Drupal Is Built For Scalability

Drupal’s modular building block system allows for easy scalability. Out of the box, it’s easy to integrate with other applications. This integration is usually needed at an enterprise level.

Another feature that makes it scalable is that you only select the modules you need on a per page basis. This eliminates a lot of excessive and messy code on pages that don’t need every module.

Drupal offers a series of articles on how Drupal can be configured for optimal performance and scalability.
 

4. Drupal Offers Enterprise-Level Security

Drupal offers enterprise-level security. High profile organizations like the White House and Nasa use it. Drupal’s core code base is very stable and secure.

Drupal has a security team comprised of a global group of web security experts. They take security very seriously. Their job is to analyze and report any security vulnerabilities.

Because most sites that run Drupal need an expert Drupal developer, the community is efficient at working together. There are over a million experts to review code and functionality. Any potential issue is quickly identified and dealt with before it becomes a threat.
 

5. Drupal Is Fast

One of the things that differentiate Drupal from other CMS’ is that it has built-in caching. In plain English, this allows for content to be delivered quickly.

What Drupal also does is allow you to select modules to run a per page basis. This eliminates unnecessary code that can slow a page down. Not everything needs to be a part of the site-wide template.

Keep in mind, there are other factors - not Drupal-specific - that can really slow things down. Things like the size of images, number of images on a page, number of requests to the server a page makes, and the number of modules running on a page.

There are helpful (and free) tools out there, like webpagetest.org, that provide lots of tips for helping to speed your site up.
 

6. Drupal Is Multilingual

Drupal modules come in 90 different languages. You can display your site in multiple languages and allows users to switch languages easily.

Here is a resource guide for configuring a multilingual site.
 

7. Drupal Is Good For SEO

If you know anything about SEO, you’ll know that Google is soon-to-be making a big switch to a Mobile First Index. (It’s a pretty big deal.)  Drupal 8 is also supported by a mobile-first philosophy, so it’s ready for the future of SEO. Drupal is very search engine friendly.

Here’s a good explanation of what Mobile First Indexing means.

Drupal offers excellent plugins for optimizing content. A couple of favourites are the Metatag module and the XML sitemap module.

Drupal provides a limitless platform for you to deliver amazing content. A solid framework – that can functionally do anything - is key to building your presence on search engines.

If you are looking for Drupal Web Developers for your next project, please get in touch. We are always happy to start a conversation.

Sep 05 2017
Sep 05

It is very common that the shipping costs for delivering products ordered online depend on the weight of the packaged products and the number of packages. Sometimes, however, store owners determine that shipping service costs need to be directly related to the value of the order. It is for such cases that Acro Media has recently sponsored the development of the Commerce Shipping Price Matrix module.

What does the module do?

The Shipping Price Matrix module provides a new shipping method that can be added in Drupal Commerce sites. A price matrix is a list of entries that define how much the cost of a shipping service should be depending on the value of the order. For example, you can create a price matrix that says:

  • Orders with a value less than $30 should have a shipping cost of $5
  • Orders between $30 and $70 should have a shipping cost equal to 10 percent of of the order subtotal with a minimum $5 cost
  • Orders between $70 and $150 should have a shipping cost of 8 percent of the order subtotal to a maximum of $10
  • Orders over $100 should have free shipping

Our price matrix may look like the following:

acro-blog-shipping-matrix-screen2.png

Price matrices can be conveniently uploaded as CSV files so that store owners can manage them outside of the website.

Advanced functionality

Some more advanced functionality has been cooked into the Shipping Price Matrix module. What if an order contains many products, one or more of which are eligible for free shipping? The module allows you to calculate the shipping costs based on the order subtotal, excluding those products. This can be done in two ways:

  1. You can exclude certain product types from the shipping cost calculation. Say you have a store selling T-shirts and jeans, among other things. You want to provide free shipping for all T-shirts, but not for jeans and other product types. You can do exactly that.
  2. You can also exclude individual products from the shipping cost calculation based on a custom field that you can add to your products. By default, this field would be set to “No” (meaning don’t exclude) but store owners can set it to “Yes” when editing individual products. Products marked with a “Yes” in the field will be excluded from the order subtotal that will be used to calculate the shipping costs.

Here’s an example of what the module’s configuration looks like:

acro-blog-shipping-matrix-screen1.png

What’s next?

We have just released the first version of the module, and we certainly look forward to getting feedback from store owners and the Drupal community. One piece of functionality we are looking to add is the ability to configure whether taxes or promotional discounts should be taken into account when calculating the shipping costs.

If you are looking for a way to calculate shipping costs based on a price matrix, this module might be exactly what you’re looking for! Reach out to our team and we can help you determine whether it’s the right fit for your site.

Aug 30 2017
Aug 30

To upgrade or to migrate? To keep supercharging your current Drupal 7 site with new cool features or to get it straight to the next league? A so much more than just another Drupal 7 vs Drupal 8 debate: it's a decision impacting your budget and future-proofing (or not) the enhancements that you're about to implement.

In this respect, our web development team in Toronto has done its best to “pile up” the crucial pros and cons for each one of the two paths that you're now challenged to choose from.

Think them through, give honest answers to all the strategically chosen questions included in our little “questionnaire” here and you'll find your (own) way of leveling up your website:
 

To Upgrade or to Migrate? And a Few Other Key Questions to Ask Yourself

So, here you are: facing the challenge of taking your Drupal 7 website to the next stage of its evolution! But which one is it: the upgrade phase or the migration one?

Now here are some preliminary questions to ask yourself right now. It's the answers to these particular questions that will weigh heavily, later on, on your decision-making process:

1. To what extent will this “maneuver” influence my website's stability, lifetime and level of flexibility?

An extra boost of flexibility, reflected in the “edit content on-the-go” functionality, or the perspective of ongoing support for many years to come will undoubtedly influence your decision!

2. Will my site's code get easier to maintain?

And this is a crucial question to be asking yourself at this phase of the whole decision-making process: how convenient will it be for your Drupal developers to maintain/update your site's code on a long term?

3. How many resources of time do I need to invest?

For time sure is money! How long will it take to implement those new enhancements on your website? Does it involve a lengthy training process for your team, as well?

4. How easy will it be for my administrators to manage content on my website?

A simplified content editing/publishing process is what will guarantee you an independent editorial team. Empower your editors and your site admins and you'll streamline all non-coding processes on your website!

With each question that you'll answer you'll be sketching your company's “specific context”. The one favoring either the upgrade or the migration way for ramping up your Drupal site!
 

Drupal 7 vs Drupal 8: Key Comparison Notes 

Does its “age” automatically give Drupal 7 an advantage over Drupal 8?

No doubt about it! Drupal 7 is now capable to “tempt” you with a heavier load of modules, stable modules and with a longer period of time that the Drupal community has spent constantly improving it.

And yet! Drupal 8, although “younger”, is taking advantage of Drupal 7's weaknesses and shortcomings. Basically, it's equipped with all the functionality that its predecessor lacked.

Speaking of which, here's what Drupal 8 brings new to the table:

  • top popular modules have been moved to core
     
  • an advanced, easy to handle configuration management system
     
  • mobile-friendly backend: jump on the “edit content on-the-go” trend
     
  • a new era for the “content as a service” movement, thanks to its API approach to content delivery
     
  • object-oriented code: by using Symfony and Twig Drupal 8 “surprises” you with a more logically structured code (do take into account, though, that your developers will have to be already familiar with object-oriented coding)
     
  • easier-to-edit content: the very essence of content management 
     
  • one-click code deployment: deploy your code faster and (therefore) as frequently as you have to
     
  • pre-built multilingual support: you no longer need to leverage a whole “fleet” of modules for supercharging your website with multilingual capabilities
     
  • ramped up performance and scalability: 2 enhancements you just can't underestimate especially if it's a large-scale, content-packed website that you own (one carrying a heavy ecosystem of third-party technologies “pomping” data into it) 
     
  • easier third-party integration
     

Your Final Decision Depends Greatly On...

  1. the number of custom-built elements on your current Drupal site: the more of them, the more complex (lengthy and pricey) moving it over to Drupal 8 will get
     
  2. the goals that you're aiming to achieve via your new enhancements: is it just a new basic feature (just a few hours' work) that you're planning to add or a major enhancement, which would justify the migration process?
     
  3. the “weight” of your Drupal 7 site's load of data: and its complexity, as well
     
  4. whether you have a standalone website or a multi-site: needless to add that you should have all your sites (if it's a “cluster” of sites that you own) running on the same version of Drupal 
     
  5. your company's resources of time and money: an upgrade of your current Drupal 7 website won't, indeed, impact your budget to the same extent as a migration process would 
     

Upgrade Your Current Drupal 7 Site If...

  1. it's mostly custom-built: it features custom modules, custom-made workflows which would take longer to recreate and to adjust to Drupal 8's particularities
     
  2. you need to have your new enhancement(s) up and running on your website in no time
     
  3. it's basic features only that you're planning to upgrade it with
     
  4. you're constrained by a tight budget: a factor which will weigh heavily in the Drupal 7 vs Drupal 8 balance
     

Make the Leap to Drupal 8 If...

  1. the specific workflow on your website depends greatly on a streamlined content editing process
     
  2. you need to make code deployments on a regular basis
     
  3. it's complex enhancements that you want to implement 
     
  4. your current Drupal 7 website is a low-complexity one
     
  5. the overall success of your upgrade strategy depends on high levels of performance and scalability
     
  6. you value the ongoing support which, well, the Drupal 7's support team will stop offering you at some point
     

So: Drupal 7 vs Drupal 8? Will you stick to the former or level up to the later? Which direction do our “questionnaire's” results point you in?            

Aug 29 2017
Aug 29

At Acro Media, we’re very attentive to the needs of our clients. We’re constantly looking for newer and better ways of helping them do “Drupally” things. So when our client came to us with a request to make the process of adding images to product variations less painful, we listened.

This client had a huge catalog of products, each of which had quite a few variations When their employees went to add products to the catalog, they would have to upload an image for each variation of that product, even if it was the same exact image as the previous product variation. Let’s say they had a helmet in three sizes and three colors. They would have to upload and save nine images. And if they had two different angles of the same product, that means they would need to upload these images 18 different times!

We agreed this process was worthy of streamlining. Our developers and designers got together and came up with a solution that would make things easier.

Commerce Images is an image management tool for Drupal Commerce that allows us to quickly upload and set images for products and their variations. It also greatly reduces the need to store unnecessary duplicate images.

Once you install Commerce Images and set which product displays this module should be enabled for, you get a “Product Images” tab for each display bundle. So when you’ve finished adding all the product variations and their details, you can click on the “Product Images” tab to get a new interface for uploading images (shown below).

Image Manager Module - Adding images

You get a list of the SKUs of the product variations that you’ve set up, with checkboxes next to them. In our case, we’ve got a helmet in three colors and three sizes. We’ll upload the image for the yellow colored helmet and use the checkboxes to select which SKUs this image should represent. Since the yellow helmet comes in three sizes, we’ll select those three SKUs, enter an alt text title, and save the new image. We have two more images for the two other colors of helmets, so we’ll do the same for those as well. And that’s it!

Image manager module - selecting skus the image represents

You can use this tab to easily upload and select the images the SKUs represent without having to manually upload and store the same image more than once.

Removing SKUs from images is just as easy. Just uncheck the SKUs that you don’t want an image to represent and click the “Save Changes” button. You can also take an image off the site using the “Remove” button.

acro-blog-image-manager-screen2.jpg

Now, going back to our example, if you do the math, you can see that we’d just need to upload the three images that we have and select all the SKUs those images should represent. So, instead of uploading nine times (3x3) and storing the images in nine different places (six of which are duplicates), we’ve reduced it to just three unique images stored. That’s a 67 percent reduction in space, storage, and time!

Finding simple solutions to complicated problems is something we really enjoy. What kind of pain points do you have with your ecommerce solution? Tell us! Maybe we can help.

Aug 29 2017
Aug 29

Putting this here because I didn’t see it mentioned elsewhere and it might be useful for others. Thinking about the history of the Islandora solution packs for different media types, the Basic Image Solution Pack was probably the first one written. Displaying a JPEG image, after all, is — well — pretty basic. I’m working on an Islandora project where I wanted to add a viewer to Basic Image objects, but I found that the solution pack code didn’t use them. Fortunately, Drupal has some nice ways for me to intercede to add that capability!

Step 1: Alter the /admin/islandora/solution_pack_config/basic_image form


The first step is to alter the solution pack admin form to add the Viewers panel. Drupal gives me a nice way to alter forms with hook_form_FORM_ID_alter().
/**
 * Implements hook_form_FORM_ID_alter().
 *
 * Add a viewers panel to the basic image solution pack admin page
 */
function islandora_ia_viewers_form_islandora_basic_image_admin_alter(&$form, &$form_state, $form_id) {
  module_load_include('inc', 'islandora', 'includes/solution_packs');
  $form += islandora_viewers_form('islandora_image_viewers', 'image/jpeg', 'islandora:sp_basic_image');
}

/** * Implements hook_form_FORM_ID_alter(). * * Add a viewers panel to the basic image solution pack admin page */ function islandora_ia_viewers_form_islandora_basic_image_admin_alter(&$form, &$form_state, $form_id) { module_load_include('inc', 'islandora', 'includes/solution_packs'); $form += islandora_viewers_form('islandora_image_viewers', 'image/jpeg', 'islandora:sp_basic_image'); }

Step 2: Insert ourselves into the theme preprocess flow


The second step is a little trickier, and I’m not entirely sure it is legal. We’re going to set a basic image preprocess hook and in it override the contents of $variables['islandora_content']. We need to do this because that is where the viewer sets its output.
/**
 * Implements hook_preprocess_HOOK(&$variables)
 * 
 * Inject ourselves into the islandora_basic_image theme preprocess flow. 
 */
function islandora_ia_viewers_preprocess_islandora_basic_image(array &$variables) {
  $islandora_object = $variables['islandora_object'];
  module_load_include('inc', 'islandora', 'includes/solution_packs');
  $params = array();
  $viewer = islandora_get_viewer($params, 'islandora_image_viewers', $islandora_object);
  if ($viewer) {
    $variables['islandora_content'] = $viewer;
  }
}

/** * Implements hook_preprocess_HOOK(&$variables) * * Inject ourselves into the islandora_basic_image theme preprocess flow. */ function islandora_ia_viewers_preprocess_islandora_basic_image(array &$variables) { $islandora_object = $variables['islandora_object']; module_load_include('inc', 'islandora', 'includes/solution_packs'); $params = array(); $viewer = islandora_get_viewer($params, 'islandora_image_viewers', $islandora_object); if ($viewer) { $variables['islandora_content'] = $viewer; } }

I have a sneaking suspicion that the hooks are called in alphabetical order, and since islandora_ia_viewers comes after islandora_basic_image it all works out. (We need our function to be called after the Solution Pack’s preprocess function so our 'islandora_content' value is the one that is ultimately passed to the theming function. Still, it works!

Aug 23 2017
Aug 23

One of our clients came to us with a problem: the process of ordering new stock for their business and updating the on-hand inventory as shipments came in was getting costly and arduous. It required a lot of manual labor and was often subject to human error.

Sound familiar?

Drupal Commerce offers retailers a wide array of useful features when it comes to selling products and fulfilling orders. But there was a bit of a void when it came to connecting stores with their suppliers. There really wasn’t a system that allowed store owners to automate the process of ordering products from vendors and updating the stock as it was received.

That’s why we created the new Purchase Order Manager module for drupal.org. At Acro Media, we strongly believe in contributing back to the Drupal community, and this was a great opportunity for us to do just that!

The Purchase Order Manager is a new back-end interface that helps the store owner track ordered and received products and update stock inventory. Its purpose is simple: make the process of ordering stock and receiving products as automated as possible.

We first created an interface that allows store administrators to view the status of existing purchase orders in the system (shown below). They can also view the order PDFs.

acro-blog-po-manager-screen4.png

Let’s say you need to create a purchase order. When you click the “+ New Purchase Order” link, you’re taken to a nice UI (shown below) that allows you to select which vendor this purchase order will be sent to. Once you choose a vendor, the email field will automatically populate with the email address of the vendor that exists in the system.

acro-blog-po-manager-screen1-971937-edited.png

Now you can go ahead and add products to the P.O. There are two ways to do this. One is by using an autocomplete text field (highlighted below) that allows you to search by the product title or SKU and select from the list of matching results.

acro-blog-po-manager-single_add_products.gif

The second way is through a bulk product search (shown above). Sometimes, entire brands or categories are supplied by a single vendor. The “Bulk Add Products” feature allows you to add products to the P.O. by searching for products that belong to a specific brand and/or category. (You can configure these fields when you set up the module.)

Add the quantity for each product and click on the “Add to P.O.” button. This will automatically add the products to the P.O.

acro-blog-po-manager-bulk_add_products.gif

A note about quantity: some suppliers ship products in bulk quantities. As the product lists are compiled, the module understands the different quantity types that some products are packaged in. For example, some products might be ordered in cases or lots, where a single case might actually be 12 of the item. The Purchase Order Manager automatically calculates the number and sends the vendor the correct quantity.

acro-blog-po-manager-add_lot_quantity.gif

After adding the products, you can either save the P.O. as a draft to come back to later, or go ahead and send the P.O. to the vendor.

If you choose to send the P.O., the module creates a PDF version of it and fires off a couple of emails to the vendor and store administrator. The PDF is included in the email and contains a summary of all the products in the order and further information about the store.

Once you get the shipments from the vendor, you can use the Purchase Order Manager to update the quantities received; this automatically updates the stock on-hand as well. The system also takes partial shipments into consideration. You can update only those products that were received and the system will continuously keep track of the quantity yet to be delivered. Once all quantities have been fulfilled, it will mark the P.O. as being complete. There’s also a nice log that you can view to see the purchase order history, right from creation to completion.

acro-blog-po-manager-quantity_received.gif

So, in a nutshell, the Purchase Order Manager offers an easy-to-use interface to automate the process of creating purchase orders and updating product quantity on-hand as shipments are received. It greatly reduces errors and saves a lot of headaches for store owners.

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