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

Aug 15 2017
Aug 15

In part two of our Webform tutorial, we’ll show you how to create multipage forms, apply conditional logic, create layouts and much more!

We’ll take the simple newsletter signup form created in part one of this tutorial and add additional pages. Then we’ll demonstrate how to show or hide an element depending on the selection made on another element. We’ll also look at layouts and then finish off with an overview of some of the other great features Webform has to offer.

Multipage Forms

For forms with many elements, it’s best to spread them across two or more pages. In this section, we’ll take the form we created in part one and move some of the elements to make a two page form. We’ll also add a preview page and make changes to the confirmation screen.

1. Starting from the Edit tab of the Webform created in part one, click on “Add page”.

Screenshot highlighting the Add page button which is above the first element.

2. Give the first page a title of “Your details”.

3. If you want to change the default “Previous page” and “Next page” text then you can do this in the “Page settings” section. We’ll stick with the defaults.

4. Click on Save to create the page.

5. Repeat the process to create a page called Feedback.

Screenshot showing the two new pages added at the bottom of the Webform elements.

6. On the Edit tab, drag the “Your details” page to the top.

7. Drag the “First name” and Email elements to the right a little so they are indented as shown below.

8. Drag the Feedback page above the checkboxes.

9. Drag the checkboxes and radio buttons to the right so they are also indented.

10. Click on “Save elements”.

Screenshot showing the pages moved to the correct places, as discussed in the text.

Clicking on the View tab will reveal a multipage form. You’ll see the page names on the progress bar at the top of the form. You can remove the progress bar in the form settings if you prefer.

Screenshot of the multipage Webform.

Preview and Submission Complete Pages

For long forms, it can be useful for users to preview the information before submitting it. Also, the default message a user receives after clicking on submit is “New submission added to Newsletter signup” or similar and so changing the message is normally a good idea. We can make both of these changes from the Settings tab for our Webform.

1. From the Edit tab of our form, click on the Settings sub-tab.

Screenshot highlighting the Settings sub-tab with is under the main Edit tab for a Webform.

2. Scroll down to the “Preview settings” section. The Optional radio button will allow users to skip the preview screen. We’ll select Required, so that users will always preview the information before submitting it. You can alter various aspects of the preview page but we’ll stick with the defaults.

3. Scroll further down the page to the “Confirmation settings” section.

4. It’s worth reading through the options under “Confirmation type”. We’ll stick with the default of Page as this will work well for our simple example.

5. For “Confirmation title”, enter “Newsletter signup successful”.

6. Enter “Thank you, [webform-submission:values:first_name]. You have signed up to our newsletter.” for the “Confirmation message”.

Screenshot of confirmation settings

7. Scroll down to the bottom of the page and click on Save.

When the “First name” element was initially added to the Webform, a key of first_name was created and we’ve used this in our confirmation message. You could also use the information from other form elements by replacing first_name with the appropriate key.

You can find the key listed on the Edit tab of the form, under the Key column, although that column may be hidden on smaller screens. Also, if you edit an element, you’ll see the key shown in small text to the right of the title.

Now if you click on the View tab and fill in the information on the form, you’ll have a preview screen. After signup, you’ll also have a personalized message.

Screenshot showing that the first name entered on the form becomes part of the confirmation message.

Conditional Logic

On page two of our wizard, we have a question asking about interests and then another specifically about JavaScript. Ideally, we only want to show the JavaScript question if the user has expressed an interest in it. This is where conditional logic helps. We can set the second question to respond to the results of the first.

1. From the Edit tab of our form, click on the Edit button for “Which JavaScript framework are you most interested in?”.

2. Scroll down to the “Conditional logic” section.

3. Change the State to Visible.

4. Select “JavaScript [Checkboxes]” under “Element/Selector”.

5. Under Trigger, select Checked.

Screenshot showing conditional logic being added.

6. Click on Save.

Now if you view the second page of the form, you won’t see the question about JavaScript frameworks unless you have selected the JavaScript checkbox.

Screenshot showing that the JavaScript library question only appears if the JavaScript checkbox in the first question is checked.

Conditional logic can be used to show or hide elements, disable them or make them required, depending on the state of other elements. It’s always worth testing that the logic performs as you expect it to, especially for complex forms.

Displaying Webforms

In this section, we’ll show how to change the default URL. We’ll also demonstrate how to attach a Webform to a node and how to display it in a block.

Changing the URL

By default, Webforms have a URL of “/form/name-of-form”, so in our case it’s “/form/newsletter-signup”. You can change the form part of the URL to another word for all forms within the global Webform Settings tab (administrative toolbar, Structure, Webforms). Instead of doing that, we’ll add an alias for our form.

1. From the Edit screen of the form, click on the Settings sub-tab.

2. Scroll down to the “URL path settings” section.

3. Here you can add URL aliases. We’re going to use “/signup” for the first box and “/signup-complete” for the second.

Screenshot showing the URL path settings being added.

4. Click on Save.

Now, both the form and the confirmation page will have a shorter URL.

Attaching a Webform to a Node

Webform also allows you to attach a form to a node. In this example, we’ll attach a node to the “Basic page” content type.

1. From the administrative toolbar, click on Structure and then “Content types”.

2. Click on “Manage fields” for “Basic page”.

3. Click on “Add field”.

4. Under “Add a new field”, select Webform.

5. Give the field a label, such as “Newsletter signup”.

6. Click on “Save and continue” and then “Save field settings” on the next screen.

7. You should now be on the Edit tab for the new field. In the “Default value” section, select “Newsletter signup” from the list.

8. Click on “Save settings”.

As with any field, you’ll be able to adjust its position relative to other fields, so you can move the Webform to any part of the node.

Now when you create new content using the “Basic page” content type, you’ll have the newsletter signup Webform attached.

Screenshot showing a node with a Webform attached.

Displaying a Webform in a Block

Another option for displaying a Webform is to create a block. This offers flexibility on where the Webform can be placed on the page.

1. Navigate to Structure on the administrative toolbar, and then “Block layout”.

2. Next to the appropriate region of your theme, click on “Place block”. We’re going to add the block to “Sidebar second” for our Bartik theme.

3. Find Webform in the list and click on “Place block” next to it.

4. Change the title to “Newsletter signup”.

5. Under Webform, type News and select “Newsletter signup” when it appears.

6. In the Visibility section, adjust the settings as you would with any block. We’re going to enter “/signup*” for “Hide for the listed pages” on the Pages tab, so the block will be hidden on the “/signup” and “/signup-confirmation pages”.

7. Click on “Save block” to complete the process.

The signup form now appears in a block on the right of our screen for most pages.

Screenshot of the Webform in a block.

Note that Webform adds another tab to the Visibility section for block configuration. This allows you to select which Webforms the block should be displayed on.

Creating Layouts

To simplify laying out elements on a page, Webform includes a variety of containers including divs, expandable details and fieldsets. If you add a new element, you’ll see all the containers listed together.

Screenshot listing the containers - Container, Details, Fieldset, Flexbox layout, Item, Label.

In this section, we’ll look at the Flexbox container and use it on the second page of the form. This will allow the two questions to sit side-by-side on a large screen, but they’ll automatically be vertically stacked on smaller screens.

1. From the Edit screen of our Webform, click on “Add element”.

2. Find “Flexbox layout” in the list and click on “Add element” on the same line.

3. Give the element a key, such as newsletter_interests.

4. The defaults will work fine for this example, so click Save to create the container.

5. Drag the new Flexbox layout element, so that it’s just below Feedback and make sure it’s indented.

6. The checkboxes and radio buttons should now be below the Flexbox layout element. Move them both to the right so they are further indented.

Screenshot showing flexbox layout with indented questions underneath.

7. Click on “Save elements” to complete the process.

Now when you fill in page two of the form, when the JavaScript box is ticked, the second question will appear to the right on large screens. If there isn’t enough room for the questions to be side-by-side then the second question will drop down below the first.

Screenshot showing two questions side-by-side.

This is just a simple example of what’s possible with layouts. Later in this tutorial, we’ll install the Webform Examples module and the “Example: Layout: Flexbox” form shows how many different elements can be displayed across a page.

Even More Features

We could carry on writing about the Webform module for weeks as it includes so many great features. In this section, we’ll give a brief overview of some other features that are definitely worth looking at.

Reducing SPAM

Any form on the internet will be a target for spammers so it’s essential to have systems in place to reduce this to a minimum. Webform works with the spam protection modules Antibot, CAPTCHA and Honeypot and using a combination of these should help cut down on unwanted messages.

Head to Structure on the administrative toolbar and then Webforms. Click on the Add-ons tab and then scroll down to the “Spam protection” section and find the links to each of the modules.

Once installed, to configure Antibot and Honeypot, click on Webform’s global Settings tab. Then expand “Third party settings” within the “Webform settings” section. For CAPTCHA, there is an element that can be added to any Webform.

YAML

The Edit tab on a Webform has a “Source (YAML)” sub-tab which exposes the underlying YAML markup. This allows you to copy code to another form, add more elements and make changes to forms. For forms that use a lot of similar elements, copying and pasting with the appropriate changes can be a lot quicker than manually adding each element.

In the code below, which is the first section of our YAML markup, we’ve added a Surname text field by copying the markup for first_name and editing it. We’ve also changed the title for the second page from Feedback to Interests.

your_details:
  '#type': wizard_page
  '#title': 'Your details'
  first_name:
    '#type': textfield
    '#title': 'First name'
    '#required': true
  surname:
    '#type': textfield
    '#title': 'Surname'
    '#required': true
  email:
    '#type': email
    '#title': Email
    '#required': true
feedback:
  '#type': wizard_page
  '#title': Interests

Saving the form and clicking on the View tab shows the new form element in place and the new name for the second page of our form.

Screenshot showing that Surname has been added and the second page is now called Interests.

If you’ve not used YAML before then be very careful with spaces. When items are nested then always use two spaces to indent. Thankfully the interface will point out any lines that have been incorrectly formatted. The screenshot below shows what happens when you add an extra space.

Screenshot showing that there is an indentation issue near surname in the YAML file.

Note that some changes made to the YAML markup will require you to remove data first. For example, if we had also changed the key for the Feedback page, which is shown as feedback: in the YAML code above, then we would have needed to clear submissions or delete the page in the UI and then re-create it.

You can find out more about exporting and importing Webforms using YAML in this video.

Debugging

To help track down issues, you can enable debugging for a form. Start off at the Edit tab of the form and click on the “Emails / Handlers” sub-tab. Then you just need to click on “Add handler” and follow through the screens to add a Debug handler. The screenshot below shows the type of information that will be displayed as you move through a form.

Screenshot showing debugging output with keys and values entered for each element.

The Examples Module

To get an idea of the capabilities of Webform, it’s a good idea to look at the Webform Examples module. You can enable this from the Extend tab of the administrative toolbar or by using Drush with the following command:

drush en webform_examples

This will install many Webforms that demonstrate different aspects of the module.

Screenshot listing the nine example Webforms available.

The “Example: Style Guide” is a good starting point as it shows all the different elements and also has some photos of cute kittens.

Settings, Modules and Add-ons

If you have been following along with this tutorial, you will have seen a huge array of settings. It’s worth spending some time looking through all the global settings available for Webform as well as the settings for individual Webforms and for different elements. These are just some of the settings available:

Screenshot listing some of the many Webform settings.

Webform includes a number of modules including starter templates and dev tools and you can view these on the Extend tab of the administrative toolbar by filtering using the word Webform. If you need to extend the functionality of Webform further, then the first place to look is the Add-ons tab.

Summary

In this part of the tutorial, we’ve looked at multipage forms and shown how to display Webforms in a variety of ways. We’ve used conditional logic to show or hide an element depending on the state of another element. We’ve also given an overview of some of the other great features included in the Webform module.

FAQ

Q: Is there an online demo of Webform?
You can test the features of Webform on simplytest.me.

Aug 09 2017
Aug 09
August 9th, 2017

We are excited to announce the completion of the second major development phase of our engagement with Forcepoint: improving the authoring experience for editors and implementing a new design.

Reimagining the Editorial Experience

Four Kitchens originally launched Forcepoint’s spiffy new Drupal site in January 2016. Since then, Forcepoint’s marketing strategy has evolved, and they hired a marketing agency to perform some brand consulting, while Four Kitchens implemented their new approach in rebuilding the site. We also took the opportunity to revisit the editorial experience in Drupal’s administrative backend.

Four Kitchens has been using Paragraphs on some recent Drupal 8 projects and found it to be a compelling solution for clients that like to exert substantive editorial control at the individual page level—clients like Forcepoint. Providing content templates for markup that works hand in hand with the component-driven theming approach we favor is a primary benefit we get from using Paragraphs for body content.

Editorially, the introduction of Paragraphs gives Forcepoint a more flexible means of controlling content layout for individual pages without having to rely as heavily on Panels as we did for the initial launch. We’re still using Panels for boilerplate and some content type specific data rendering, but the reduced complexity required for editors to layout body content will allow their content to evolve and scale more easily.

In addition to using paragraphs for WYSIWYG content entry, Forcepoint editors are now also able to insert and rearrange related content, Views, Marketo forms, videos, and components that require more complex markup to render.

We’re big proponents of carefully crafted content models and structured data. Overusing Paragraphs runs the risk of removing some or even a lot of that structure. Used judiciously however, it allows us to give clients like Forcepoint the flexibility they want while still enforcing desirable constraints inherent in the design.

Congratulations!

We’ve been working with Forcepoint for over a year now, and are incredibly proud of the solutions we’ve created with them. This kind of close relationship and collaboration is what we strive for with all of our partners. We thrive on understanding our partners’ underlying business challenges and goals, collaborating with their teams, and creating solutions that delight their customers.

The Forcepoint team was led by Chris Devidal as the project manager, working alongside Taylor Smith who acted as internal product owner. Jeff Tomlinson was technical lead and assisted Patrick Coffey who adeptly wrangled all the difficult backend issues. Significant frontend technical leadership was provided by Evan Willhite who worked with Brad Johnson to implement a challenging design. Props also go to Keith Halpin, Neela Joshi and Adam Bennett at Forcepoint for their many contributions.

Web Chef Jeff Tomlinson
Jeff Tomlinson

Jeff Tomlinson enjoys working with clients to provide them with smart solutions to realize their project’s goals. He loves riding his bicycle, too.

Aug 08 2017
Aug 08

It’s easy to forget that lots of ecommerce platforms don’t have a content management system (CMS). It’s something we take for granted, because Drupal Commerce was built on a CMS. That’s how it started out. But that’s not usually the case. If you want to build a CMS with Magento, for instance, you have to add on a CMS (incidentally, the recommended CMS to pair with Magento is Drupal).

So with most other ecommerce platforms, to get CMS functionality you have to pair them with WordPress or you have to pair them with SharePoint. Ecommerce platforms handle products, and that’s about it. They don’t handle tutorials, how-to videos, blog posts, or any of that other stuff.

This leads to the problem where you have a shop, and you have a catalog or brochure site. So you have all these product pages that explain all about the products with videos and guides and stuff, and then you have the separate shop. It doesn’t really make sense for it to BE separate; it’s only done that way because of the limitations of the technology. Apple is a classic offender: the Apple store is completely different from the Apple product pages.

The majority of ecommerce sites are set up that way, with one site that tells you about the products and an entirely separate site that lets you actually purchase the products. Sometimes you can fake it on the front end to make it look like they’re coming from the same place, but that’s far more difficult than just doing it properly on the back end.

On the other hand, Amazon is an example of an online retailer that doesn’t really do content. They just have product pages. If you want additional information on an Amazon product, you go somewhere else, like to the website of the manufacturer. Amazon basically assumes you’ve already decided to buy the product, and you’re just purchasing it from Amazon.

To summarize: Having the product pages and cart functionality truly meshed (the way they are in Drupal) is super cool. They’re built on the same platform, so you don’t need to think about combining them. It’s already done.

To learn more, check out our High Five episode “Drupal Commerce 2.x – CMS.”

Subscribe to our YouTube Channel for more Drupal Commerce goodness!

Aug 02 2017
Aug 02


Full name


Email


Phone number


Company


Location


Website


Project type


Estimated budget


Tell us about your project or idea

SUBMIT

Aug 02 2017
ao2
Aug 02

Drupal 8 is quite an improvement over previous versions of Drupal with regard to the reproducibility of a site from a minimal source repository.

The recommended way to set up a new Drupal 8 site is to use composer, and the most convenient way to do that is via drupal-composer/drupal-project, which brings in Drush and drupal-console as per-site dependencies; from there the site can be installed and managed.

However the fact that Drush and drupal-console are per-site dependencies poses a problem: they are not available until the site dependencies have been downloaded, this means that it's not really possible to add “bootstrapping” commands to them to make it easier to set up new projects.

This is what motivated me to put together drupal-init-tools: a minimalistic set of wrapper scripts which can be used when Drush and drupal-console are not available yet, or when they have to be combined together to perform a task in a better way.

drupal-init-tools has been developed mainly to speed up prototyping, and it is particularly useful to set up sites under ~/public_html when the web server is using something like the Apache userdir module; however I feel it could be useful in production too after some cleanups.

drupal-init-tools standardizes the setup and installation of new Drupal projects: for example the drin new command makes sure that the original drupal-composer/drupal-project repository is still accessible from an upstream git remote so that the developer can easily track changes in drupal-composer/drupal-project and keep up if appropriate for their particular project.

Some drin commands also provide a nicer interface for frequent and important tasks, like the actual site-install step, or the creation of an installation profile that could replicate the installed site.

Here are some examples of use taken from the drin manual.

Create and install a new Drupal project:

cd ~/public_html
drin new drupal_test_site
cd drupal_test_site
$EDITOR bootstrap.conf
drin bootstrap --devel

Create an installation profile from the currently installed project:

drin create-profile "Test Profile" test_profile

Clean and rebuild the whole project to verify that installing from scratch works:

drin clean
drin bootstrap

A quick way to test drupal-init-tools is this:

git clone git://git.ao2.it/drupal-init-tools.git
cd drupal-init-tools/
make local
./drin --help

Give it a go and let me know what you think.

If it proves useful to others I could have it packaged and uploaded to Debian to make it more “official”, IMHO it makes sense to have such a small meta-tool like drin as a system global command.

Aug 02 2017
Aug 02

To the average person on the street, a product is something you buy. Say Joe Blow is looking for a T-shirt. Specifically, he wants a blue T-shirt with the logo of his favorite sports team on the front. He goes to an online store, selects the T-shirt with the appropriate logo, chooses the blue color, and indicates the size he needs. Simple. He has now purchased a product.

But in the ecommerce world, a product is much more complicated.

Products: More Than Meets the Eye

If you’re the owner of that online store, you know that every size of that shirt is an individual product that has its own SKU. Knowing whether someone ordered a large or small shirt is important for inventory (so you know how many you have left in stock), pricing (maybe you sell different sizes at different price points), and processing (so you know exactly what has to be shipped). Different colors are also different versions of the same product. So a “product” is really a collection of a whole bunch of products. But when your customers are viewing it, they think of the collection as the single product.

How Drupal Commerce 2.x Handles Products

In 2.x, you have attributes that are used to make up these different products. Each different color is going to be a variation, and each different size is a variation, and each different size + color combination is also a variation. So when you build attributes (size, color, etc.), you actually build products.

You can also have customizations. If Joe Blow wanted his name on that back of that T-shirt, that isn’t really an attribute, because it doesn’t change the product stock. The store would just print his name on a standard T-shirt. That’s an option that gets applied to a product.

Commerce 2.x also lets you set product types, so you can handle physical, digital, and subscription products differently (you don’t need sizes and weights and things for a digital good, for instance).

How This Differs From Drupal Commerce 1

The main difference is that it’s more built in now. In Commerce 1, there were variations, and then you built your own product by making a node (which was actually pretty confusing to a lot of people). In Commerce 2.x, you set up a product, and add variations to it, and it’s a much more structured process that takes you through what you need to do.

The bottom line: products in Commerce 2.x are not vastly different; they’re more of an iterative improvement over Commerce 1.

To learn more, check out our High Five episode “How Drupal Commerce 2.x handles Products.”

Subscribe to our YouTube Channel for more Drupal Commerce goodness!

Aug 01 2017
Aug 01


Full name


Email


Phone number


Company


Location


Website


Project type


Estimated budget


Tell us about your project or idea

SUBMIT

Aug 01 2017
Aug 01

The Webform module in Drupal 8 makes it easy to create complex forms in no time. The basics are easy to learn but when you start digging below the surface, the huge power of the Webform module starts to reveal itself.

While the Contact module in Drupal 8 core does allow you to create simple personal and site-wide contact forms, functionality is limited. This is where Webform module steps in.

In the first part of this tutorial, we’ll use some Webform elements to create a simple but fully functioning form. We’ll show what you can do with the results of submissions and then add some additional elements. We’ll also demonstrate how one of the built-in JavaScript libraries can improve the look of form elements.

In part two, we’ll add additional pages to our Webform, apply conditional logic, show how to create great layouts and much more!

Getting Started

The simplest way to install Webform is to use Drush. The following three commands download and enable the Webform module and then download all the required libraries. This tutorial is based on Webform version 8.x-5.0-beta15.

drush dl webform
drush en webform webform_ui
drush webform-libraries-download

If you get “Unable to unzip” errors then install a command line tool capable of unzipping files and try again. On our minimal CentOS setup, we needed to install the unzip package.

Alternatively, you can download the module. Note, although it’s better to download the libraries, Webform will use a CDN if any libraries are not available locally.

To see what libraries are used and to check the status of each, from the administrative toolbar, click on Reports, then “Status Report” and look for the entries that start with “Webform library”. Specific libraries can be disabled within Webform’s Settings tab if required.

Screenshot showing the status of Webform libraries.

If you plan to allow users to upload files using a Webform then please read the note below about setting up private files. Incorrect configuration could be a significant security risk.

A Quick Tour of the Webform Interface

To add and manage Webforms, click on Structure on the administrative toolbar, then Webforms. You should see a screen similar to the one below.

Screenshot highlighting six different areas in the Webform interface.

Some of the points of interest are:

1. The tabs along the top are self-explanatory and we’ll look at these throughout the tutorials.

2. You’ll see “Watch video” buttons in various places in the Webform module. These short videos are a great way to learn about Webform features.

3. Add a new Webform.

4. The “How can we help you?” button is a quick way to find out more about the module, report issues and become involved with the Drupal community.

5. “Filter webforms” is useful if you have a large number of Webforms.

6. Buttons for each Webform allow you to download submissions and edit forms.

Creating a Simple Form

In this tutorial, we’ll start off with a very simple newsletter signup form and then later we’ll add more complex elements. We’ll initially create two elements – first name and email address. One way to do this would be to duplicate the existing Contact form by clicking on the down arrow on the Edit button and then selecting Duplicate. We could then edit the form. The other way is to create the form from scratch and we’ll show you how to do that here.

1. Click on the “Add webform” button.

2. Give the form a name such as “Newsletter signup” and an appropriate description if you want.

3. If you plan to have a lot of forms then adding categories can be useful. We’ll add a Newsletter category by selecting the “Other…” option.

4. Click on Save to create the form.

Screenshot of the add Webfrom screen.

On the next screen, we can start adding elements to our form.

1. Click on the “Add element” button.

2. Use the “Filter by element name” box at the top to find “Text field” and click on “Add element” next to that.

Screenshot of the text filter helping to find the text field element.

3. Enter “First name” for the title.

4. We’ll leave all the other settings as they are. Click on Save to finish.

5. Click on “Add element” again.

6. This time, find the Email element and click on “Add element”.

7. Enter a title of Email and click on Save.

Note, if you wanted to make sure the user entered their email address correctly then you can use the “Email confirm” element which adds an additional confirmation box. Many of the other elements also have variations, so it’s worth reviewing these to make sure you’ve picked the best element for your needs.

You should now have a screen that’s like this.

Screenshot of the edit tab after two elements have been added.

Click on the View tab to see the form.

Screenshot of the view tab after two elements have been added.

To keep matters simple to start with, we’ve used a lot of the default settings for the elements. While these settings work well for a lot of cases, it’s worth looking through the different options for each element type as there are a number of ways to customize the way an element appears.

There are a couple of things that would be good to change at this stage. Firstly, it may be better to change the Submit button text to Signup. Also, currently neither of the fields are required, so a user could submit a blank form.

1. Click on the Edit tab.

2. To the right of “Submit button(s)”, click on Customize.

Screenshot showing that the customize button is below the other elements.

3. Enter Signup under “Submit button label”. We’ve also changed the Title to Signup.

4. Click on Save.

5. Tick Required for both the first name and email elements and then “Save elements”.

Screenshot highlighting the required checkboxes next to each element.

Note, with a customized submit button you can adjust the position of it relative to other elements if you wanted to.

Now, when you click on the View tab, you should see that both fields are required and the submit button is labelled Signup.

Screenshot showing that the elements are now required and the submit button is now labelled Signup.

Testing the Form and Viewing Results

To test the form, you can either manually add data and submit it, or you can use the Test tab to generate data. If the Devel generate module is installed then you can use that to automatically generate Webform submissions.

Screenshot of the test tab with information automatically added.

Signup to the newsletter a few times and then click on the Results tab. You can click on the Customize button to change the columns shown if required. You can also mark particular submissions with a star or add administrative notes and we’ve done both for submission number 5. Looking at our list of automatically generated submissions, it appears that the Webform maintainers like The Beatles!

Screenshot of the webform submissions with first names of John, Paul, George and Ringo.

The Edit button next to each submission has a number of options including editing, viewing and deleting submissions. The Download sub-tab allows you to export the submissions in a variety of ways and you can filter based on date or submission ID, so you don’t need to download all the data in one go.

Screenshot of the download sub-tab.

Emailing Results

While the Results tab allows you to review submissions, it can also be useful for results to be emailed once submitted.

1. Head to the Edit tab and click on the “Emails / Handlers” sub-tab.

2. Click on “Add email”.

3. In the “Send to” and “Send from” sections, we’ll just use the default settings. This will use the email address and name that are configured for the site (administrative toolbar – Configuration, “Basic site settings”).

4. The email that’s sent can be customized in the Message section if required but we’ll just stick with the default message.

5. Click on Save to create the email handler.

Screenshot after the email handler added.

You can also add handlers to post submissions to a remote URL and enable debugging.

Adding Checkboxes and Radio Buttons

In this section, we’ll add checkboxes and radio buttons and enhance their appearance using the jQuery iCheck library. If you filter elements using the word “checkbox” then you’ll see five different options.

  • Checkbox – a single checkbox.
  • Checkboxes – a group of checkboxes using a custom or pre-defined lists.
  • Checkboxes other – a group of checkboxes with an “Other …” option to allow the user to enter their own information.
  • Entity checkboxes – checkboxes using entity references.
  • Term checkboxes – checkboxes using taxonomy terms.

We’re going to create checkboxes asking the user about their interests.

1. From the Edit tab, click on the Elements sub-tab, then “Add element”.

2. Use the filter to help find “Checkboxes other” and select “Add element”.

3. Give it a title of “What are your main interests?”.

4. With long titles, it’s often worth shortening the associated key as this will be used for CSS classes and referred to in other areas of Webform. Click on the Edit link to the right of the title and change the key to main_interests.

Screenshot of title and key for checkboxes other element.

5. Scroll down to the “Elements options” section.

6. The Options list allows you to select from pre-defined lists such as days of the week. For our example, we want to enter values, so leave Options set to “Custom…”.

7. For each option, we need to add a value and text pair. The “Option value” is used internally and you’ll see the values in the markup and CSS IDs and classes that are added. The “Option text” will appear to the user on the form. We’ve created three options with pairs html / HTML, css / CSS and js / JavaScript, as shown below.

Screenshot of value - text pairs.

8. Scroll down to the “Other option settings” section. These settings apply to an additional item that will be added to the end of the list of checkboxes. The default settings create an “Other…” checkbox with an additional textfield if other is selected. The settings are customizable but for our example we’ll stick with the defaults.

9. Click on Save to complete the process.

Note, in the “Elements options” section, the number of columns that checkboxes are displayed in can be adjusted. We’ve stuck with a single column as we’ll be showing how to layout two elements next to each other in part two of this tutorial.

Using a similar procedure, other elements such as radio buttons and select lists can be created. We’re going to add radio buttons.

1. Add the Radios element.

2. Give it a title of “Which JavaScript library are you most interested in?”.

3. Change the key to js_library by clicking on Edit to the right of the title.

4. Add options for jQuery, AngularJS and React as shown below.

5. Leave all the other options at their default settings and click on Save.

Screenshot of value - text pairs.

In part two of this tutorial, we’ll use conditional logic to show how you can hide this question unless someone selects the JavaScript checkbox under “What are your main interests?”.

Clicking on the View tab should reveal elements that look similar to this.

Screenshot of Webform view tab with checkboxes and radio buttons.

Enhancing Checkboxes and Radio Buttons

As you can see from the screenshot above, checkboxes and radio buttons have the default look. Thankfully, Webform includes the jQuery iCheck library and this makes it simple to enhance these elements. You can enable iCheck for individual elements by editing their properties and scrolling down to “Enhance using iCheck”, but we’ll show how to enable it globally.

1. From the administrative toolbar, click on Structure, Webforms and then the Settings tab.

2. Expand the “Element Settings” section.

3. Within that section you’ll find “Checkbox/radio settings”. Expand this also.

4. Select an option from “Enhance checkboxes/radio buttons using iCheck” that works with your theme (it’s worth trying the different styles). In our screenshots, we’ve used the “Square: Blue” option.

5. Scroll to the bottom of the screen and click on “Save configuration”.

Now our Webform has greatly enhanced checkboxes and radio buttons.

Screenshot with enhanced checkboxes and radio buttons.

Other Elements

We’ve only discussed a few elements from a very long list. It’s worth spending time looking through the full range of Webform elements and trying them out.

If you add any of the file elements then please ensure that you’ve followed advice about file uploads. Allowing non-trusted users to upload files to public folders can be a huge security risk. When using a private folder make sure you’ve secured the folder correctly and ideally, only allow trusted users to upload files. It’s worth reading “Drupal file upload by anonymous or untrusted users into public file systems – PSA-2016-003” before implementing file elements on a production server.

Summary

In this part of the tutorial, we’ve shown how to create a simple form and view submissions. We’ve discussed Webform elements and looked at how to enhance checkboxes and radio buttons.

In part two, we’ll show you how to create multi-page forms, use conditional logic to show and hide elements, create layouts and much more!

FAQs

Q: How can I get more information about Webform?
The Webform documentation page has lots of useful information and videos.

Q: What are the differences between Webform and the Contact module?
You can find a detailed comparison here.

Jul 31 2017
Jul 31


Full name


Email


Phone number


Company


Location


Website


Project type


Estimated budget


Tell us about your project or idea

SUBMIT

Jul 26 2017
Jul 26

If a customer comes to your Drupal Commerce site and goes to the trouble of going through the checkout process and entering their payment information, you really need to make sure that whatever they ordered actually arrives on their doorstep. That’s what OMS and fulfillment are all about.

What exactly is OMS and fulfillment?

OMS stands for Order Management System. Order management and fulfillment are two sides of the same coin, but there are some key distinctions.

Order management means managing the order as a customer service person—checking that the order is valid, filling it out, answering any customer questions, etc. Fulfillment is the actual act of getting the product to the customer—taking it off the shelf, putting it into a box, and getting it shipped out (or in the case of a digital good, making sure the product actually made it to the customer).

So order management and fulfillment are closely related, but you might use different systems or even different people for each aspect.

How does Drupal handle order management and fulfillment?

Drupal has full order management capabilities out of the box. You can edit orders, change orders, add products, put notes in, change taxes, all that kind of stuff.

Fulfillment is where Drupal is a bit weak. This is a key area for integration with a third party. Maybe you don’t even do your own fulfillment—maybe you process the orders and send them to Amazon, who actually handles shipping them out. Maybe you ship from 20 different locations and have to move products around, so you need a system that can handle such complexities. Commerce 2.x has the basic framework for fulfillment, but it’s early days, and more work needs to be done. But you can integrate with other systems that can take care of that function.

Are any fulfillment systems easier to work with than others?

Fulfillment integration is not usually too complex; normally you’re just pushing the order information to the other system. That said, you’ll want a modern system that has an API that can be worked with (Amazon and Brightpearl are just two examples). Fulfillment has existed since the early days of print catalog ordering and some of the software seems like it’s from that same era—it might be difficult or even impossible to integrate with some older systems.

The bottom line:

Drupal Commerce has good order management out of the box. It has OK fulfillment out of the box, but it can integrate with anything you want (except some crappy legacy systems from the 1970's).

To learn more, check out our High Five episode “Drupal Commerce 2.x – OMS & Fulfillment.

Jul 20 2017
Jul 20

One of my pet peeves is searching for a local event and finding details for that event… 3+ years ago.

Many Drupal sites feature some sort of event type node. It’s really anything with a start date, and likely, an end date. The problem is, most developers don’t take into account whether or not that content should live on once the end date has come and gone.

Perhaps, in some instances, keeping that content on your site makes sense. In most cases though, it does not.

For instance, my 3 year old was really into dinosaurs. I knew there was a dinosaur exhibit coming to town, but I didn’t quite remember the name. Searching online provided quite a few local results. And many of those results were for events in the past.

Examples

Discover the Dinosaurs (06/21/2014)
http://www.evansvilleevents.com/home/events/discover-the-dinosaurs
(event has since been unpublished!)

DISCOVER THE DINOSAURS ROARS INTO EVANSVILLE! (12/14/2012)
http://www.evansvilleevents.com/home/2012/12/discover-dinosaurs-roars-evansville
(event has since been unpublished!)

Dino Dig! (06/02/2015)
http://www.cmoekids.org/events/community-events/dino-dig

Event from 2 Years Ago

Discover the Dinosaurs Unleashed (02/18/????)
http://www.evansvilleliving.com/event/discover-the-dinosaurs-unleashed

Sometimes sites will even have past events ranking higher in search results than upcoming events.

There’s a whole other blog post I could write about how useful it is to have the year accompanying the day and month on web content — particularly tech blog posts. Was this written in February of this year or 2006? How can I know?!?

The Drupal Solution

For Drupal sites, there’s a relatively easy fix. It requires a small custom module and the contributed Scheduler module.

The Scheduler module is simple and great. Simply enable it for your content type, and enable, at the very least, the unpublish setting. Once that is set up, create a custom module and invoke the hook_entity_presave() function.

This code is pretty self explanatory. All I’m doing is checking to be sure it’s an event node type that’s being saved, and if so, find the start and end date values to be used when setting the “unpublish_on” field.

You’ll of course have to make sure your node type and field names match up.

Once that’s set up, any time an event is saved, your node is scheduled to unpublish one day after the end date.

If you have a Drupal 7 site, this same idea can be applied. The code in the hook_entity_presave() will be a bit different.

I wish I could start a massive movement to help clean up web content that should have been unpublished or removed long ago. Until then, hopefully this article finds a few devs so that they can ensure their site isn’t one of those sending out poor results.

Jul 19 2017
Jul 19

Acro Media Sprint Week has wrapped up for another year. For those who are new to this idea, each year we bring most of our staff together to have a week of fun that includes a lot of Drupal contrib work. Contrib work is community development of all aspects of the Drupal software, including code, design/UX, documentation and more. You can read a bit more about it on our pre-sprint week blog post.

Our goals for 2017 were pretty big. We had a lot of people grouped into several teams, each working on a different aspect. Overall, we think we did pretty good!

Keep reading or jump to a section below:

Services

One of the goals of this sprint was to open up services for the Drupal Commerce cart module by adding endpoints for decoupled Drupal or 3rd party usage. This sets the stage for better cart integration with 3rd party APIs.

The team got a good start and were able to accomplish the following:

  • Created /cart/init POST endpoint that will initiate a cart.
  • Created /cart/{order_id} GET endpoint that will return the current state of the cart.
  • Created /cart/{order_id} POST endpoint which accepts payload with items and quantities to be added to cart, and it updates the cart as per payload.
  • Created unit tests to verify the functionality of the code. This still needs some work but it's a good start.

We don’t have the code to share at the moment, but, this start will be further refined and pushed out at a later date. For those interested, you can read more and follow progress at https://www.drupal.org/node/2894400. 

UX

The UX team was our largest team this year. This team broke out into several smaller groups to tackle a number of items.

Material Admin Theme

Almost every single Drupal website has a custom theme that gives the website a unique look and feel. However, while the front end is custom, the majority of these sites use the default Drupal theme for the admin side of the site. This is the non-public facing part of the site.

Recently, we’ve wanted something a little more modern for the admin theme. Something that takes good design and pairs it with science based usability decisions. For this, we’ve turned to Google’s Material Design and have started work on a new admin theme using it as a foundation.

Here’s a before and after screenshot of the Material theme in action. We’re hoping to have a 1.0 release soon.

Content list page
(Default Drupal admin theme)

add-content-default.jpg

Content list page
(Material admin theme)

add-content-material.jpg

Drupal Commerce Dashboard

The main dashboard for Drupal Commerce is still pretty bare bones. It’s basically just a list of links and descriptions, which is Drupal’s default behavior for this type of thing. While this works, the dashboard is the first page many people see when using Drupal Commerce, so, we wanted something more intuitive and stylish.

Prior to Sprint Week 2017, one of our senior front end developers who is spearheading this initiative had already been conceptualizing the dashboard with the Drupal Commerce community. We wanted to take this and get started on the development. Progress was made and the new dashboard is starting to take shape.

View screenshots and follow progress at https://www.drupal.org/node/2885483

Drupal Commerce Setup Wizard

Starting from scratch with Drupal Commerce can be a little confusing if you haven’t done it a few times already. There are a lot of different pieces to a store and so finding all of the initial settings can be somewhat frustrating. This is the motivation behind creating a setup wizard to guide people through the initial setup of a store. A wizard helps get the necessary configuration done quickly and easily.

Some of our team had already done some design/UX groundwork ahead of time. Like the dashboard, this sprint we just wanted to get started on the code. Once completed, the wizard will give users a step by step interface for setting up store details, currencies, taxes, payment processors, etc. Once these initial settings have been completed, you should theoretically be able to get started with the content of the store, such as products.

View screenshots and follow progress at https://www.drupal.org/node/2878968

Currency Setup UX

Sometimes developers aren’t the best at communicating with the rest of the world. Luckily, the rest of the world is also helping to develop the software! This was the case when one of our project managers discovered some confusing language when setting up currencies in Drupal Commerce. What was expected vs. what actually happens when using the primary setup tools didn’t match up, leading to confusion. This has been resolved and will soon make its way into a dev release of Drupal Commerce.

View the details and patch status at https://www.drupal.org/node/289396

Documentation

Another big team this year was the documentation crew. While not very exciting, documentation is critical to the usability of Drupal as well as the ongoing development of it. The documentation team split into two groups, one for core Drupal 8 documentation and one for Drupal Commerce 2.x documentation. Some new pages were created while others were updated for Drupal 8.

Here’s a list of where progress was made. Note that some documentation is pending review and so may be updated.

Drupal 8 Core Documentation

Writing and contributing documentation

Server Scaling and Performance

Database API documentation port to Drupal 8

JavaScript API documentation

Form API confirmation form documentation

Managing content (reorganized documentation)

Installing Drupal 8 with Composer (updated documentation)

Drupal 8 installation

Drupal Commerce 2.x Documentation

Commerce content creation

Commerce configuration

How to contribute to commerce documentation

Added tab support to docs

Updated recipes layout and requirements

Commerce Install

The goal of this team was to create a prototype for a custom Drupal Commerce install. The idea is that a person could select options for their install, then, based on their selections a Composer file would be dynamically generated to make the initial Drupal Commerce install a snap. Pretty cool stuff.

This Commerce Install team was able to get a working prototype completed! There’s still some work to do before it’s released into the wild, but, it’s getting close. I’m sure we’ll toss up an announcement of some sort when it’s completed.

POS (point of sale)

The Point of Sale module provides an interface for Drupal Commerce to allow in-person interactions with a Drupal Commerce storefront. This is powerful because it allows a single solution for both online and brick and mortar stores.

Currently, the Point of Sale module is only available for Drupal 7. The POS team was tasked with starting to port it over to Drupal 8. They made some good headway! Here’s a recap.

Development Reference

Merged commits

Pending commits

UX issues reviewed or added

Sprint Week 2018

Now the focus shifts to 2018. We’d love to see others in the online community join us for next years Sprint! The Acro Media Sprint Week in 2018 will be happening the second week of July (9th to 13th). Mark your calendars and get in touch next year if you’d like to take part with us.

Jul 17 2017
Jul 17

For those who aren’t familiar with the concept of Pattern-Lab (or a Pattern Library), it’s essentially a living style guide; a common tool in modern web development. At their most basic, they are continuously updated documents that help documenting common design styles for web components, bringing together the intended look & feel with the images and codes to build them.

I started to look into this idea around a year and half ago because I found that each time a new project started, I needed to redo much of the same styling work. Even worse, when the main project was still in development, it was hard to keep an eye on the minor changes that affected other projects, so they would quickly get out of sync with each other. There wasn’t a centralised place to store reusable components. Unfortunately, my initial attempt to push a “shared Pattern-lab” idea didn’t work too well because we had difficulties integrating with various tools and workflows across teams.

example living style guideExample of a living style guide

Now that our technology stacks at Comic Relief have matured, with a major shift to JavaScript frameworks and CI automation tools, the integration is getting much easier for shared styling libraries. Through inter-team collaboration we managed to make it work with our main development workflows (Drupal and non-Drupal) plus provide a way to using it for non-NPM projects. The result is a Pattern-Lab solution designed to be usable by both our internal and third party teams. We’ve also open sourced it so anyone else can benefit from it too!

Our Pattern-lab reduced duplication of effort as it’s ensured we have a library of reusable components that are common through all our main products. Additionally, this is giving us more consistency in our newer sites therefore reducing the time it takes for us to deliver. It also means that we now have a one-stop reference guide for both designers and developers working on all our projects.

The Features

To summarise, the Pattern-Lab is built on Node and using NPM, with the styles themselves being written in SASS and style guide generated by KSS. Every time a pull request is opened on Github, a preview version of the Pattern-lab is deployed to Netlify with Visual Regression tests run with Travis. Once code has passed review and been merged into the master branch, the latest release is automatically pushed to NPM and deployed to production by Concourse.

More details and documentation can be found here:
https://www.npmjs.com/package/@comicrelief/pattern-lab

Visual Regression

One stand out feature for me are the visual regression tests we put in place. These make sure that existing styles aren’t accidentally changed unintentionally when we add a style or make a breaking change. A big benefit of this is that now they’re integrated into our CI pipeline, if the tests fail, the code will not be released. It’s particularly important to make sure that we don’t break one product’s styles while trying to fix another!

Example visual regression reportexample of backstopJS visual regression test report

One of the potential future additions is to extend this to include automated accessibility checks. These would ensure we do our best to make all our sites fully accessible while we can also add unit test coverage reports so we can make sure we cover any areas that have been missed by our regression test suite.

Summary

For me, it’s taken a long time to get this far, but I’ve been really happy with how various teams were able to work together to make the idea into reality. We’re getting a lot of great use out of our Pattern Lab and I hope it helps you if you ever encounter any similar issues.

GitHub: https://github.com/comicrelief/pattern-lab
NPM: https://www.npmjs.com/package/@comicrelief/pattern-lab
CI Pipeline: https://ci.apps.comicrelief.com/teams/main/pipelines/pattern-lab

Share this:

Like this:

Like Loading...
Jul 17 2017
Jul 17

Once upon a time, people had to thumb through thick tomes of printed material called “catalogs” to find the products they wanted to buy. If you’re old enough to remember looking through the Sears catalog at Christmas time looking for toys to ask Santa for, you know what I’m talking about. (And if you aren’t old enough to remember that, I don’t want to talk to you.)

While print catalogs have largely gone the way of the dinosaurs, the concept of letting people browse a selection of products has not. That’s where online catalog functionality comes in.

What is catalog functionality on a website?

Basically, it’s a listing of products. You need to display multiple products on a page so people can browse through them and pick the one they want. There can be filters and categories and various other ways of going from thousands of products down to a manageable number that people can actually scan through.

How does Drupal Commerce 2.x handle catalogs?

In Commerce 2.x, everything is just search results that come up, but it appears like a catalog. So if you filter by a specific tag or parameter, it presents like a catalog with nice rows of products. But since it’s really just a search result, you can apply all the filters that you would for a search. You can do a keyword search in a category, for instance. Or you can filter by price, brand, color, or any other parameter you care to use. Think of the kind of shopping experience you get on Amazon (only more specific), and you’ll get what we’re talking about here.

How do you know what’s going to be displayed?

There are lots of different options. You can choose to display everything with the “television” tag, for instance. Results can be displayed alphabetically, or you can have the top sellers display first, or you can have products come first and have accessories listed lower down. You can add manual weightings to products, or you can have weightings based on other tags or even on dynamic data. There’s a lot of adaptability.

How is this different from Commerce 1.x?

In Commerce 1, you could use views and display products that way, which allowed for some filtering, but it was pretty basic. In Commerce 2.x, catalogs are now searches, so they’re cool and flexible, and they can do whatever you want.

To learn more, check out our High Five episode “How Drupal Commerce 2.x handles Catalog Functionality.”

Subscribe to our YouTube Channel for more Drupal Commerce goodness!

Jul 13 2017
Jul 13
July 13th, 2017

When creating the Global Academy for continuing Medical Education (GAME) site for Frontline, we had to tackle several complex problems in regards to content migrations. The previous site had a lot of legacy content we had to bring over into the new system. By tackling each unique problem, we were able to migrate most of the content into the new Drupal 7 site.

Setting Up the New Site

The system Frontline used before the redesign was called Typo3, along with a suite of individual, internally-hosted ASP sites for conferences. Frontline had several kinds of content that displayed differently throughout the site. The complexity with handling the migration was that a lot of the content was in WYSIWYG fields that contained large amounts of custom HTML.

We decided to go with Drupal 7 for this project so we could more easily use code that was created from the MDEdge.com site.

“How are we going to extract the specific pieces of data and get them inserted into the correct fields in Drupal?”

The GAME website redesign greatly improved the flow of the content and how it was displayed on the frontend, and part of that improvement was displaying specific pieces of content in different sections of the page. The burning question that plagued us when tackling this problem was “How are we going to extract the specific pieces of data and get them inserted into the correct fields in Drupal?”

Before we could get deep into the code, we had to do some planning and setup to make sure we were clear in how to best handle the different types of content. This also included hammering out the content model. Once we got to a spot where we could start migrating content, we decided to use the Migrate module. We grabbed the current site files, images and database and put them into a central location outside of the current site that we could easily access. This would allow us to re-run these migrations even after the site launched (if we needed to)!

Migrating Articles

This content on the new site is connected to MDEdge.com via a Rest API. One complication is that the content on GAME was added manually to Typo3, and wasn’t tagged for use with specific fields. The content type on the new Drupal site had a few fields for the data we were displaying, and a field that stores the article ID from MDedge.com. To get that ID for this migration, we mapped the title for news articles in Typo3 to the tile of the article on MDEdge.com. It wasn’t a perfect solution, but it allowed us to do an initial migration of the data.

Conferences Migration

For GAME’s conferences, since there were not too many on the site, we decided to import the main conference data via a Google spreadsheet. The Google doc was a fairly simple spreadsheet that contained a column we used to identify each row in the migration, plus a column for each field that is in that conference’s content type. This worked out well because most of the content in the redesign was new for this content type. This approach allowed the client to start adding content before the content types or migrations were fully built.

Our spreadsheet handled the top level conference data, but it did not handle the pages attached to each conference. Page content was either stored in the Typo3 data or we needed to extract the HTML from the ASP sites.

Typo3 Categories to Drupal Taxonomies

To make sure we mapped the content in the migrations properly, we created another Google doc mapping file that connected the Typo3 categories to Drupal taxonomies. We set it up to support multiple taxonomy terms that could be mapped to one Typo3 category.
[NB: Here is some code that we used to help with the conversion: https://pastebin.com/aeUV81UX.]

Our mapping system worked out fantastically well. The only problem we encountered was that since we were allowing three taxonomy terms to be mapped to one Typo3 category, the client noticed some use cases where too many taxonomies were assigned to content that had more than one Typo3 category in certain use cases. But this was a content-related issue and required them to re-look at this document and tweak it as necessary.

Slaying the Beast:
Extracting, Importing, and Redirecting

One of the larger problems we tackled was how to get the HTML from the Typo3 system and the ASP conference sites into the new Drupal 7 setup.

The ASP conference sites were handled by grabbing the HTML for each of those pages and extracting the page title, body, and photos. The migration of the conference sites was challenging because we were dealing with different HTML for different sites and trying to get get all those differences matched up in Drupal.

Grabbing the data from the Typo3 sites presented another challenge because we had to figure out where the different data was stored in the database. This was a uniquely interesting process because we had to determine which tables were connected to which other tables in order to figure out the content relationships in the database.

The migration of the conference sites was challenging because we were dealing with different HTML for different sites and trying to get get all those differences matched up in Drupal.

A few things we learned in this process:

  • We found all of the content on the current site was in these tables (which are connected to each other): pages, tt_content, tt_news, tt_news_cat_mm and link_cache.
  • After talking with the client, we were able to grab content based on certain Typo3 categories or the pages hierarchy relationship. This helped fill in some of the gaps where a direct relationship could not be made by looking at the database.
  • It was clear that getting 100% of the legacy content wasn’t going to be realistic, mainly because of the loose content relationships in Typo3. After talking to the client we agreed to not migrate content older than a certain date.
  • It was also clear that—given how much HTML was in the content—some manual cleanup was going to be required.

Once we were able to get to the main HTML for the content, we had to figure out how to extract the specific pieces we needed from that HTML.

Once we had access to the data we needed, it was a matter of getting it into Drupal. The migrate module made a lot of this fairly easy with how much functionality it provided out of the box. We ended up using the prepareRow() method a lot to grab specific pieces of content and assigning them to Drupal fields.

Handling Redirects

We wanted to handle as many of the redirects as we could automatically, so the client wouldn’t have to add thousands of redirects and to ensure existing links would continue to work after the new site launched. To do this we mapped the unique row in the Typo3 database to the unique ID we were storing in the custom migration.

As long as you are handling the unique IDs properly in your use of the Migration API, this is a great way to handle mapping what was migrated to the data in Drupal. You use the unique identifier stored for each migration row and grab the corresponding node ID to get the correct URL that should be loaded. Below are some sample queries we used to get access to the migrated nodes in the system. We used UNION queries because the content that was imported from the legacy system could be in any of these tables.

SELECT destid1 FROM migrate_map_cmeactivitynode WHERE sourceid1 IN(:sourceid) UNION SELECT destid1 FROM migrate_map_cmeactivitycontentnode WHERE sourceid1 IN(:sourceid) UNION SELECT destid1 FROM migrate_map_conferencepagetypo3node WHERE sourceid1 IN(:sourceid) … SELECTdestid1FROMmigrate_map_cmeactivitynodeWHEREsourceid1IN(:sourceid)UNIONSELECTdestid1FROMmigrate_map_cmeactivitycontentnodeWHEREsourceid1IN(:sourceid)UNIONSELECTdestid1FROMmigrate_map_conferencepagetypo3nodeWHEREsourceid1IN(:sourceid)

Wrap Up

Migrating complex websites is rarely simple. One thing we learned on this project is that it is best to jump deep into migrations early in the project lifecycle, so the big roadblocks can be identified as early as possible. It also is best to give the client as much time as possible to work through any content cleanup issues that may be required.

We used a lot of Google spreadsheets to get needed information from the client. This made things much simpler on all fronts and allowed the client to start gathering needed content much sooner in the development process.

In a perfect world, all content would be easily migrated over without any problems, but this usually doesn’t happen. It can be difficult to know when you have taken a migration “far enough” and you are better off jumping onto other things. This is where communication with the full team early is vital to not having migration issues take over a project.

Web Chef Chris Roane
Chris Roane

When not breaking down and solving complex problems as quickly as possible, Chris volunteers for a local theater called Arthouse Cinema & Pub.

Jul 11 2017
Jul 11

The ability to create a form quickly and easily is a vital piece of functionality in any content management system. A content editor needs the capacity to create a form and add or remove fields.

The days of asking a developer to create a custom form are long gone. An editor should be able to spin up a form for whatever they need.

Luckily Drupal 8 has two good options for building forms: Contact and Webform.

Contact

The Contact module in Drupal 7 and below has always been the go-to module for basic forms as long as you’re happy with the hard-coded fields. If you need an extra field, you would have to write custom code to add it.

Now in Drupal 8, you’re no longer stuck with a single form. Instead, you can create different fieldable contact form types. You can create different contact forms and attach fields to them, the same way as you do on content types.

The Contact module won’t keep any form submissions in Drupal. It’ll send them to a designated email address. To store submissions use Contact Storage module.

Webform

Webform is the original form builder for Drupal. If content editors needed the ability to create forms then this is the module they would use. The module is suited for basic contact forms as well as long multi-page forms.

The 8.x-5.x version of Webform started out as YAML Form and it was decided to make YAML Form the Drupal 8 version of Webform.

Webinar on Contact and Webform

I recently recorded a webinar on Contact and Webform, where I cover both modules and show you how to create a form in each one.

Watch the webinar above or directly on YouTube.

Or jump to a specific section using the links below.

Contact Module

  • What’s new in Contact module (02:03)
  • Manage contact form types (04:34)
  • Create Contact form type (05:05)
  • Default fields on Contact form (06:37)
  • Add field to contact form (07:44)
  • View submission (09:01)
  • Configure “Manage display” (09:57)

Webform Module

  • What’s new in Webform module (12:25)
  • Install Webform (14:11)
  • Overview of Webform admin page (16:31)
  • Create form using Webform (18:33)
  • Adding elements to forms (18:56)
  • Add pages to forms (21:17)
  • Conditionally display fields (22:20)
  • Form settings (28:58)
  • Add email notification to form (31:15)

Webform Integration with Google Sheet

  • Introduction to Zapier (36:30)
  • Create zap in Zapier (38:40)
  • Configure Webform to send post to webhook (39:36)
  • Test integration with Google Sheets (43:27)

Questions

  • Question: how to prevent spam (46:08)
  • Question: Views integration with Webform (55:25)

Mentioned Resources

Jul 09 2017
Jul 09

With Buenos Aires Argentina user group we are organizing a meeting on Sat 22nd and Mon 24th of July

It's been a long time since our last camp was done on BsAs (2009) and thanks to the inspiration of Drupal Camp Chile we've been planning doing another for a while.

We finally put a day thanks to a visit from Enzo. We are calling it a "PicNic" and not a camp due to the extend it'll have, it will be two days:

  • On Saturday 22nd we'll have an sprint with mentoring
  • On Monday 24th there will be technical conferences

You can find more details on our event page.

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