As we near the end of 2019, choosing the right technology implementation partner has never been more important. According to a recent Gartner study, through 2021, 90 percent of global organizations will rely on system integrators (SIs), UX design agencies and channel partners to design, build and implement their digital experience strategies.

Before deciding on the right implementation partner, it’s integral to choose the right technology for that partner to implement. Drupal, an open-source technology option, is known for being the top choice for creating large, complex websites. Given today’s increasingly complex threat environment, Drupal is also a great technology option because of its built-in security protocols. According to a recent report, Drupal sites are some of the least hacked sites on the web. For large, security-conscious organizations, federal agencies and government institutions, look no further than Drupal. 

Infected Websites Platform Distribution: Q3 - 2016

Once you’ve made the decision to implement a Drupal site, the next question to ask yourself is who you should trust to design, build and implement your new site. That’s where a top DC UX design agency like Bluetext comes in. 

Here are our top 5 tips for finding the right Drupal development agency:

Look for a Partner Who Thinks Beyond the Implementation

Having a partner who focuses on the big picture of your project is integral to the success of your initiative. These days, any developer with a laptop and an internet connection can set up a website, but having a partner with a perspective on how that website fits into the broader marketing ecosystem and vision for your company’s future growth is paramount. A Drupal development company like Bluetext, with full-service capabilities, can be that partner. Bluetext, leveraging experience as a top DC UX design agency, will assess the project from a wider viewpoint and offer tried and tested solutions to positively impact your revenue streams and improve overall customer loyalty. 

For example, Bluetext partnered with Mindtree to develop the new Mindtree.com, which includes an intuitive, fully responsive user experience and leverages personalization to serve relevant content to each user. Powered by Drupal 8, the new website provides the flexibility and scalability a large enterprise needs to support its digital marketing efforts.

Is Your Team Ready for the Partner’s Style?

When working on a project, chemistry is everything. Your chosen partner might be the best in the business, but if they don’t wrap their processes around your needs, the entire engagement will be negatively affected on both sides of the table. Deadlines won’t be met, communication will feel forced and restricted, and overall, the project will suffer.  Bluetext, one of the best DC UX design agencies, works closely with each client we partner with, making sure we understand internal processes, all design and functional requirements, and priorities for the given timeframe. Bluetext adapts our processes to operate how our clients work best, employing different applications and modes of communication to ensure every client is happy and the end-product achieves set goals.

Make Sure Your Teams Fully Understand Their Roles

The key to any project’s success is communication. It is never wise to assume a member of the team fully understands the objectives they are tasked to manage and deliver. An open-source application such as Drupal can be a challenging system to get used to. Having a leading web agency like Bluetext on your side can make any project run smoothly. From week one, Bluetext makes sure every member of the team, on both sides of the engagement, has a clear understanding of their role. This means putting in the effort to define clear project objectives per phase, roles and responsibilities, a communication structure and even informal expectations. Put the work in at the beginning of an engagement, and you will reap the benefits as you toast the launch of your new website.

A Higher Price Doesn’t Necessarily Mean a Higher Quality

When choosing the right technology implementation partner, the cost of the implementation is important. Understanding how and where your budget will be spent before making your choice will lower the chance of setbacks as the project moves from start to finish. The higher-priced implementation partner will often spend longer amount of time on a project and will bring too many unnecessary team members to meetings. Contrarily, the cheaper implementation partners often lack the skill to produce consistent, quality work. 

At Bluetext, a leading web agency, we understand how ambiguous pricing may seem when it comes to implementing a new website. Bluetext is unique in our approach to pricing out technological implementations. Most digital web design agencies will conduct their business via an hourly billing budget. Bluetext ultimately views this process as inefficient and a hindrance to the client-agency relationship. Instead, we bill per deliverable, making our inefficiencies our problem. It doesn’t matter how many members of our team we bring to a client meeting or how many rounds of revisions a design takes to get right. The client always comes first and the work isn’t done until you are satisfied.

Past Track Record Counts

A company’s decision on which technology implementation partner to choose comes down to that partner’s previous experience. This makes sense, given that clients often look to case studies featuring previously executed work an example of what they can expect to receive at the end of the engagement. They also look to the reputation of agencies within their industry, so they know that that agency has knowledge of their industry and can get up to speed quickly. Bluetext, being a top UX & interface design company, has plenty of experience developing stunning, industry-leading, Drupal-based sites and has delivered on some of the most complex implementations to date.

For example, Bluetext partnered with XO on an enterprise-level Drupal 8 website deployment. Bluetext engineered a next-generation CMS re-platforming that included a first-time responsive website user-experience design. As XO’s SEO agency of record, Bluetext delivered a comprehensive SEO overlay as we dealt with the complexities of re-platforming, leveraging the Drupal content management capabilities to make XO.com an organic SEO over-achiever.

For more information on why Bluetext is one of the top DC digital web design agencies, check out our website, packed with examples of our work harnessing the power of Drupal.

In previous posts, we have provided tips and tricks for a successful Drupal migration from earlier versions of the content management system to the latest Version 8. In this installment of our series, we will talk about the Drupal 8 Migrate Plugin System.

About Drupal 8 Migrate

The migrate module has been moved into the core in Drupal 8, showing the community dedicated to making the process of upgrading between versions or migrating into Drupal an easier path to a successful move. The migrate module takes advantage of the Drupal 8 Plugin system, offering developers several Plugin types that they can implement: MigrateProcessPlugin, MigrateSourcePlugin, MigrateDestinationPlugin.

In an earlier blog post in this series, we dove into an introduction of the Migrate module in Drupal 8 and reviewed a basic setup of the migration mappings needed to get started. In this post, we will dive into MigrateProcessPlugins: what they are, how they work and examples on how to create your own.

What is a Drupal 8 Migrate Processor?

A migration processor is a plugin that is used to manipulate data that is being mapped from a source to a destination. These plugins are typically small, but very powerful. Processors are used in the “process” portion of your migration configuration file.

Drupal 8 comes with several migration processors out-of-the-box. Some of the more notable ones that you will likely use on a regular basis are:

  1. get – Default, 1:1 data migration plugin
  2. default_value – Allows you to define a default value for a field
  3. explode – Converts a string into an array of strings based on a delimiter
  4. iterator – Iterates over an array of values to perform a process on
  5. migration_lookup – Looks up an entity based on an ID from a source to a destination
  6. skip_on_empty – Skips the current field or row if the value is empty in the migration

What Are the Benefits of Using a Drupal 8 Migrate Processor?

Migration process plugins provide developers with more flexibility and reusability when working with migrations in Drupal 8. By utilizing the Drupal 8 Plugin system, the Migrate module allows users to create new processors that implement a generic interface and can essentially be plug and play. In addition, the OO design of the plugin system allows developers to utilize inheritance of abstract classes and enforcement of methods if they have several variations of a plugin, without reinventing the wheel or duplicating code every time.

In English, this means that I can develop my own processors that manipulate data from my data source in any way that I want, and then reuse it across any migration that needs to use it.

How Does a MigrateProcessPlugin Work?

If you are finding that the out-of-the-box MigrateProcessPlugin’s are not enough for your use case, you may want to consider creating a new custom MigrateProcessPlugin. Creating a new process plugin in Drupal 8 is a fairly simple task.  

Let’s take a look at a simple MigrateProcessPlugin as an example to get us started.

In the DefaultValue MigrateProcessPlugin, we only have one method that is implemented, called “transform”. Transform takes in a value that is passed in by the user, checks to see if it is set, and sets that value for the field in the destination mapping.

How Do I Use a Process Plugin in My Migration?

Using a process plugin in your migration is relatively simple. If you have written a migration before, you have used these without even knowing it. Let’s take a look at the example below:

In this example, you will notice several plugins are utilized:

  1. get: The “get” plugin is the default plugin. Any mapping that does not have a child element defining a plugin will utilize the “get” plugin
  2. default_value: In this example, we are setting the user ID of a blog_post to user 1

When am I Going to Need a Custom Processor Plugin?

Before you venture down the path of creating custom processors, ask yourself the following questions:

  1. Can any of the existing process plugins, or a combination of any of the existing process plugins, manipulate the data to the format I need?
  2. Is the data transformation something that follows a pattern?
  3. Is this processing/data manipulation something that will need to be used for more than one migration?
  4. Is this a transformation that other users/migrations may benefit from?

If the answer to any of the questions above is “YES”, it is worth your time to create a custom processor plugin.

Stay tuned for our next blog post in our migration series on custom processors. In this post, we will dive into what it takes to create a custom processor for a WordPress to Drupal migration.

Would you like help to create a more detailed plan for migrating your website to Drupal 8?

Contact Us – We would be happy to help!

About Drupal 8 Migrate

The migrate module has been moved into the core in Drupal 8, showing the community dedicated to making the process of upgrading between versions or migrating into Drupal easier. The migrate module takes advantage of the Drupal 8 Plugin system, offering developers with several plugin types that they can implement: MigrateProcessPlugin, MigrateSourcePlugin, and MigrateDestinationPlugin.

Quick Recap of our previous blog:

  1. Complete rewrite & moved into Drupal 8 core
  2. Out of the box support for D6 -> D8 and D7 -> D8
    1. Nodes, Users, Comments, Profiles, Taxonomies
    2. Content & Configuration
  3. Support for custom sources and destinations
  4. Processors for working with/manipulating data

Series Mapping:

Part 1: Migration Setup & Mappings

Part 2: Working with Processors

Part 3: Coming soon!

Drupal 8 Migrate Module Overview

The Drupal 8 migrate module that is shipped with core provides a set of API’s for setting up migrations. The module also provides extensible object-oriented base classes and interfaces for migration plugins including:

  1. Source & Destination Plugins
  2. Process Plugins
  3. Config Migration Mappings

While the migrate module has been moved into core, the contributed space still provides significant value and I wouldn’t recommend trying to build a migration without it:

  1. Migrate Plus: The Migrate Plus project provides extensions to core migration framework functionality as well as examples.
  2. Migrate Tools: The Migrate Tools module provides tools for running and managing Drupal 8 migrations.

Creating Migration Mappings

In Drupal 8 all of your migration mappings are done through configuration files. In Drupal 7 these migration mappings would have been done in classes through the $this->addMapping() function.

Configuration files provide the blueprint for the migrations, and there are two main types of configuration files that we will need to define:

  1. migrate_plus.migrate_group.<name>.yml
  2. migrate_plus.migrate.<name>.yml

Migration Group

The migration group is a configuration file and is similar to the idea of hook_migrate_api in Drupal 7. This configuration file defines a group of migration classes and configures global configuration/settings to be shared across the classes.  

  1. id – Unique identifier
  2. shared_configuration – Defines shared configuration between all migration classes that are part of this group. **Example: setting the source database to use
  3. dependencies – Sets the dependencies for this set of migration classes to function

Let’s see an example:

Migration Configuration File

The migration configuration file is similar to a migration class in Drupal 7. At a high level, the migration config file defines the metadata and field mappings for a particular migration in Drupal 8. There are 5 key concepts that you need to be aware of in the migration configuration file:

  1. Definition – The definition of this migration class, its dependencies, and what migration_group it belongs to
  2. Source – What migration source should be used for this migration when it is run (i.e. where am I migrating my content from?)
  3. Destination – The destination for the migration (i.e. where am I migrating my content to?)
  4. Field Mappings – The mappings from Source -> Destination
    1. Processors – The processing of the source data so that it can be consumed by the destination

Let’s see an example:


Stay tuned for our next blog post in our migration series on custom processors. In this post, we will dive into what it takes to create a custom processor for a WordPress to Drupal migration.

Would you like help to create a more detailed plan for migrating your website to Drupal 8?

Contact Us – We would be happy to help!

As one of the top Drupal firms in the market, we get a lot of questions around Drupal 8 and its broad range of functionality, including Drupal 8 Batch Processing. We thought to start out the new year, we would offer our primer on Drupal 8 Batch Processing.

What is a batch job?

A batch job or batch processing is the execution of a series of jobs in a program on a computer without manual intervention (non-interactive). Strictly speaking, it is a processing mode: the execution of a series of programs each on a set or “batch” of inputs, rather than a single input.

In English, this means that it allows a computer program to break up a series of tasks into smaller chunks or pieces that run without any manual intervention to trigger.

When would I want to use this?

Drupal 8 Batch Processing jobs are valuable to use when there could be large amounts of data or long processes running that utilize a significant amount of memory. An example would be regenerating all URL aliases on your website. The “pathauto” module sets up a batch process when doing this to regenerate 25 aliases at a time, instead of trying to regenerate an entire site (think 5,000 – 500,000 entities) at one time that might cripple the system.

Why would I want to use this?

Performance & Scalability are the biggest reason to utilize Drupal 8 Batch Processing in your development. Batch jobs allow the processing of large amounts of data without relying on a single process to complete the task from start to finish in a single execution. This allows your server resources to be utilized in smaller chunks and freed up after each batch execution finishes.

Here are some questions you can ask when determining if you might need to create a batch process:

  1. Does the action I need to perform against these items have a per-item resource cost?
    • If the action your performing requires loading or processing of each item individually, you should be looking to use batch processing to handle it. If you are performing a simple task, such as a bulk DB query that impacts all nodes in your database, it may not be required.
  2. Do I need to perform an action on a large number of entities?
    • If the answer is yes, than you will likely gain significant performance benefits by utilizing batch processing to work through your task.
  3. Is there a finite set of data that I am performing actions on or can the dataset grow?
    • If you are unsure about how big your data set will get, you should strongly consider batch processing. Not planning for this upfront could cause site downtime and lots of headaches later down the road.
  4. Even if your current data set is small, can it expand?
    • For example, maybe your site only has 30 nodes at the moment, but that number will increase in the future. If this is the case, or you are building a module that you may want to contribute back to the community, you will likely want to look at batch processing as an option for handling this action.

How do I do this?

Creating a batch process in Drupal 8 is relatively straightforward. Here is what you will need to get started:
Demo_batch

  • src/Controller/DemoBatchController.php
  • demo_batch.info.yml
  • demo_batch.routing.yml
  • demo_batch.mybatch.inc

Demo_batch.routing.yml

The routing file defines a route, the Controller to be used, and the requirements to use it.

DemoBatchController.php

The controller tells Drupal what to do when the route (defined above) is accessed. In this case, we are creating a Batch Controller which will handle the processing of the batch job.

demo_batch.mybatch.inc

This includes file provides the callback functions for the controller to handle execution of the job. In this example, we are running through a migration task.

Looking for help with your Drupal 8 development? Contact Us to find out how we can help.

Are you still on Drupal 6?

Whether you operate a blog, a small business page, or a large corporate website, if you are still operating on Drupal 6 it is past time for you to consider upgrading your operations. Drupal 6 officially reached End-of-Life on February 24th, 2016. Since then, the Drupal community has largely abandoned support for this version of Drupal.

Why does this impact me?

Anyone running their business on a Drupal 6 version should be concerned because the Drupal community has moved on. As an open source platform, the vitality of Drupal depends on contributors adding new components, modules, features and more. When the community moves on to new versions of Drupal, the older versions are no longer receiving the care and attention required to maintain modern content platforms.

By not adopting Drupal 8, you no longer have the community actively working on modules, bugfixes, improvements, and most importantly, security updates and improvements. The Security team is no longer providing Advisory updates for Drupal 6, and the majority of modules are no longer supported by the maintainers. The bottom line? If you are still operating on an old version of Drupal, you are exposing your site to unnecessary security risk.

Uh oh…so how do I make the switch to Drupal 8?

It’s easy! Upgrading your Drupal site using a migration approach. The first step is to decide how you want to handle your upgrade. Use these questions to help you get started:

  1. Am I happy with how my website functions and how it looks?
  2. Does my website/brand need a refresh or update?
  3. Do I want to refresh my content as part of this upgrade?
  4. What are the key functions that my website needs to perform?

Based on your answers to the questions above, you will likely fall into one of two categories: Lift & Shift or Website Rebuild.

Lift & Shift: As is migrations

Drupal 8 has made significant strides to make the upgrade process from Drupal 6 to Drupal 8 as smooth as possible. Mike Ryan and others have made a huge impact in this space, rewriting the migrate module from the ground up and including it in the Drupal 8 core. The fact that this was added as a Drupal core initiative speaks volumes of the importance that has been placed on this by the community.

If your site is mainly brochureware, the upgrade process from Drupal 6 to Drupal 8 should be quick and relatively painless. The new migrate module not only migrates content, but it will also migrate data structures through a configuration migration tool. Wait, what? I can migrate my content types and taxonomy terms so that I don’t need to rebuild them!? The answer is YES! (…with some caveats of course).

For more information about the Drupal 8 migrate initiatives and upgrade documentation, check out the “Upgrading from Drupal 6 or 7 to Drupal 8” section on Drupal.org.

Website Refresh: Rebuild Content, UI and UX

So, I don’t have a basic brochureware site but I really need to refresh my brand. Can I still use these tools to take some of the load off of my shoulders? The answer is yes, but in a more limited fashion.

Depending on the size of your website, utilizing the D6 to D8 migration tools may still save you time and money. This will ultimately depend on how significant the changes to your information architecture and content will be.

If you have a large number of pages (let’s say >1000) and some percentage of these pages will remain relatively in-tact from an information architecture perspective (Blogs, Resources, Press), then you will likely still benefit from investing time in migration scripts.

If you are planning to refresh/rewrite all of your content AND provide a new UI/UX on your website, the effort to create a migration script may be higher than handling the process manually.

So, how do I get started?

If you are planning to move forward with an upgrade, it will be useful to check out the following links before you start:

While the idea of being able to be generic enough to meet a wide variety of peoples needs, it is unlikely that your migration to Drupal 8 will be handled out-of-the-box. In the likely case that you will need to customize, here are some more useful links:

Would you like help creating a more detailed plan for migrating your website to Drupal 8? Contact Us – We would be happy to help!