Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Feb 11 2021
Feb 11

Last week one of our clients was asking me about how they should think about the myriad of options for website hosting, and it inspired me to share a few thoughts. 

The different kinds of hosting

I think about hosting for WordPress and Drupal websites as falling into one of three groups. We’re going to compare the options using an example of a fairly common size of website — one with traffic (as reported by Google Analytics) in the range of 50,000–100,000 visitors per month. Adjust accordingly for your situation. 

  • “Low cost/low frills” hosting — Inexpensive website hosting would cost in the range of $50–$1,000/yr for a site with our example amount of traffic. Examples of lower cost hosts include GoDaddyBluehost, etc.  Though inexpensive, these kinds of hosts have none of the infrastructure that’s needed to do ongoing web development in a safe/controlled way such as the ability to spin up a copy of the website at the click of a button, make a change, get approval from stakeholders, then deploy to the live site. Also, if you get a traffic spike, you will likely see much slower page loads. 
  • “Unmanaged”, “Bare metal”, or “DIY” hosting — Our example website will likely cost in the range of $500–$2,500/yr. Examples of this type of hosting include: AWSRackspaceLinode, etc. or just a computer in your closet. Here you get a server, but that’s it. You have to set up all the software, put security measures in place, and set up the workflow so that you can get stuff done. Then it’s your responsibility to keep that all maintained year over year, perhaps even to install and maintain firewalls for security purposes. 
  • “Serverless” hosting¹ — It’s not that there aren’t servers, they’re just transparent to you. Our example website would likely cost in the range of $2500–5000/yr. Examples of this kind of hosting: PantheonWP EngineAcquiaPlatform.sh. These hosts are very specialized for WordPress and/or Drupal websites. You just plug in your code and database, and you’re off. Because they’re highly specialized, they have all the security/performance/workflow/operations in place that 90% of Drupal/WordPress websites need.

How to decide?

I recommend two guiding principles when it comes to these kinds of decisions:

  1. The cost of services (like hosting) are much cheaper than the cost of people. Whether that’s the time that your staff is spending maintaining a server, or if you’re working with an agency like Four Kitchens, then your monthly subscription with us. Maybe even 10x.  So saving $1,000/yr on hosting is only worth it if it costs less than a handful of hours per year of someone’s time. 
  2. Prioritize putting as much of your budget towards advancing your organization’s mission as possible. If two options have a similar cost, we should go with the option that will burn fewer brain cells doing “maintenance” and other manual tasks, and instead choose the option where we can spend more of our time thinking strategically and advancing the mission.

This means that you should probably disregard the “unmanaged/bare/DIY” group. Whoever manages the site will spend too much time running security updates, and doing other maintenance and monitoring tasks. 

We also encourage you to disregard the “low cost” group. Your team will waste too much time tripping over the limitations, and cleaning up mistakes that could be prevented on a more robust platform.

So that leaves the “serverless” group. With these, you’ll get the tools that will help streamline every change made to your website. Many of the rote tasks are also taken care of as part of the package. 

Doing vs. Thinking

It’s easy to get caught up in doing stuff. And it’s easy to make little decisions over time that mean you spend all your days just trying to keep up with the doing. The decision you make about hosting is one way that you can get things back on track to be more focused on the strategy of how to make your website better.

¹ The more technical members of the audience will know that “serverless” is technically a bit different.  You’d instead call this “platform-as-a-service” or “infrastructure-as-a-service”. But we said we’d avoid buzzwords.

Making the web a better place to teach, learn, and advocate starts here...

When you subscribe to our newsletter!

Jul 30 2020
Jul 30

argument-open-source Over 500,000 businesses leverage Drupal to launch their websites and projects. From NASA to Tesla, public and private institutions regularly rely on Drupal to launch large-scale websites capable of handling their development and visual needs. But, starting a Drupal project doesn’t guarantee success. In fact, 14% of all IT projects outright fail, 43% exceed their initial budgets, and 31% fail to meet their original goals! In other words, if you want to create a successful Drupal project, you need to prepare. Don’t worry! We’ve got your back. Here are 5 things to keep in mind when starting a Drupal-based project.

1. GATHER REQUIREMENTS FROM STAKEHOLDERS EARLY AND OFTEN

According to PMI, 39% of projects fail due to inadequate requirements. Believe it or not, requirement gathering is the single most important stage of project development. In fact, it’s the first step Drupal itself takes when pushing out new projects (see this scope document for their technical document project). Gathering requirements may sound easy, but it can be a time-consuming process. We recommend using SMART (Specific, Measurable, Agreed Upon, Realistic, Time-based) to map out your specific needs. If possible, involve the end-user during this stage. Don’t assume you know what users want; ask them directly. Internally, requirements gathering should rally nearly every stakeholder with hefty amounts of cross-collaboration between departments. You want to lean heavily on data, establish your benchmarks and KPIs early, and try to involve everyone regularly. The single biggest project mistake is acting like requirements are set-in-stone. If you just follow the initial requirements to a “T,” you may push out a poor project. You want to regularly ask questions, communicate issues, and rely on guidance from stakeholders and subject matter experts (SMEs) to guide your project to completion.

2. PLAN YOUR SDLC/WORKFLOW PIPELINE

We all have different development strategies. You may leverage freelancers, a best-in-class agency, or internal devs to execute your Drupal projects. Typically, we see a combination of two of the above. Either way, you have to set some software development lifecycle and workflow standards. This gets complex. On the surface, you should think about coding standards, code flow, databases, and repositories, and all of the other development needs that should be in sync across devs. But there’s also the deeper, more holistic components to consider. Are you going to use agile? Do you have a DevOps strategy? Are you SCRUM-based? Do you practice design and dev sprints? At Mobomo, we use an agile-hybrid development cycle to fail early, iterate regularly, and deploy rapidly. But that’s how we do things. You need to figure out how you want to execute your project. We’ve seen successful Drupal projects using virtually every workflow system out there. The way you work matters, sure. But getting everyone aligned under a specific way of working is more important. You can use the “old-school” waterfall methodology and still push out great projects. However, to do that, you need everyone on the same page.

3. USE SHIFT-LEFT TESTING FOR BUG AND VULNERABILITY DETECTION

Drupal is a secure platform. Of the four most popular content management systems, Drupal is the least hacked. But that doesn’t mean it’s impenetrable. You want to shift-left test (i.e., automate testing early and often in the development cycle). Drupal 8+ has PHPUnit built-in — taking the place of SimpleTest. You can use this to quickly test out code. You can perform unit tests, kernel tests, and functional tests with and without JavaScript. You can also use Nightwatch.js to run tests. Of course, you may opt for third-party automation solutions (e.g., RUM, synthetic user monitoring, etc.) The important thing is that you test continuously. There are three primary reasons that shift-left testing needs to be part of your development arsenal.

  • It helps prevent vulnerabilities. The average cost of a data breach is over $3 million. And it takes around 300 days to identify and contain website breaches.
  • It bolsters the user experience. A 100-millisecond delay in page load speed drops conversions by 7%. Meanwhile, 75% of users judge your credibility by your website’s design and performance, and 39% of users will stop engaging with your website if your images take too long to load. In other words, simple glitches can result in massive issues.
  • It reduces development headaches. Nothing is worse than developing out completely new features only to discover an error that takes you back to step 1.

4. GET HYPER-FAMILIAR WITH DRUPAL’S API

If you want to build amazing Drupal projects, you need to familiarize yourself with the Drupal REST API. This may sound like obvious advice. But understanding how Drupal’s built-in features, architecture, and coding flow can help you minimize mistakes and maximize your time-to-launch. The last thing you want to do is code redundantly when Drupal may automate some of that coding on its end. For more information on Drupal’s API and taxonomy, see Drupal API. We know! If you’re using Drupal, you probably have a decent idea of what its API looks like. But make sure that you understand all of its core features to avoid headaches and redundancies.

5. SET STANDARDS

Every development project needs standards. There are a million ways to build a website or app. But you can’t use all of those million ways together. You don’t want half of your team using Drupal’s built-in content builder and the other half using Gutenberg. Everyone should be on the same page. This goes for blocks, taxonomy, and every other coding need and task you’re going to accomplish. You need coding standards, software standards, and process standards to align your team to a specific framework. You can develop standards incrementally, but they should be shared consistently across teams. Ideally, you’ll build a standard for everything. From communication to development, testing, launching, and patching, you should have set-in-stone processes. In the past, this was less of an issue. But, with every developer rushing to agile, sprint-driven methodologies, it can be easy to lose sight of standards in favor of speed. Don’t let that happen. Agile doesn’t mean “willy-nilly” coding and development for the fastest possible launch. It still has to be systematic. Standards allow you to execute faster and smarter across your development pipeline.

NEED SOME HELP?

At Mobomo, we build best-in-class Drupal projects for brands across the globe. From NASA to UGS, we’ve helped private, and public entities launch safe, secure, and exciting Drupal solutions. Are you looking for a partner with fresh strategies and best-of-breed agile-driven development practices?

Contact us. Let’s build your dream project — together.

Jul 28 2020
Jul 28

argument-open-source

DRUPAL MIGRATION PREPARATION AUDIT

All good things must come to an end. Drupal 7 will soon meet its end. Does your organization have your migration plan to Drupal 9 in order? Here’s what you need to know to keep your Drupal site running and supported. Talk to Our Drupal Migration Experts Now!

OUR APPROUCH TO DRUPAL MIGRATION.

  • Analyze 
  • Inventory
  • Migration
  • Revision
  • SEO

OVERVIEW

Staying up to date with Drupal versions is vital to maintaining performance to your site:

  • Future-proofing
  • Avoiding the end-of-life cut-off
  • Performance
  • Security

GOALS

  1. Catalog existing community contributed modules necessary to the project
  • Do these modules have a corresponding Drupal 8 version?
  • If the answer to the above question is no, is there an alternative?
  • Is there an opportunity to optimize or upgrade the site’s usage of contributed modules?
  1. Catalog existing custom built modules
  • Do these modules rely on community contributed modules that may not have a migration path to Drupal 8?
  • Do these modules contain deprecated function calls?
  • Are there any newer community contributed modules that may replace the functionality of the custom modules?
  1. Review existing content models.
  • How complex is the content currently—field, taxonomy, media?
  • What specific integrations need to be researched so content will have feature parity?
  1. Catalog and examine 3rd party integrations.
  • Is there any kind of e-commerce involved?
  • Do these 3rd party integrations have any Drupal 8 community modules?
  1. Catalog User roles and permissions
  • Do user accounts use any type of SSO?
  • Is there an opportunity to update permissions and clean up roles?

PRE-AUDIT REQUIREMENTS

  • Access to the codebase
  • Access to the database
  • Access to a live environment (optional)
  • Access to integrations in order to evaluate level of effort

DELIVERABLES

Module Report The module report should contain an outline of the existing Drupal 7 modules with the corresponding path to Drupal 8, whether that’s an upgraded version of the existing module or a similar module. This report should also contain a sheet outlining any deprecated function usage for the custom modules that will need to be ported to Drupal 8.

Content Model Report The Content Model report should contain an overview of the existing site’s content types, users, roles, permissions and taxonomic vocabularies with each field given special consideration. Recommendations should be made in the report to improve the model when migrating to Drupal 8.

Integration Report The integration report contains a catalog of the third party integrations currently in use and marks those with an existing contributed module from the community and those that will require custom work to integrate with the Drupal 8 system.

Our Insights on Drupal Our latest thoughts, musings and successes.

Contact us. We’ll help you expand your reach.

Mar 20 2020
Mar 20

On June 24, 2020 Drupal.org announced that Drupal 7’s end of life has been extended until November 2023 because of the impact of COVID-19 on budgets and capacity. This article still remains relevant — but please note that the dates have been pushed back a year

If you have a Drupal 7 website, you might have already heard that the official end-of-life date for Drupal 7 has been officially set for November 2021. Many organizations should upgrade their Drupal 7 sites before then. But that might not be required. Here’s how you figure out what you need to do.

“What does Drupal 7 end-of-life mean?”

First let’s talk about what EOL means for Drupal. The main thing is security updates. 

Drupal has a highly regarded security team who manage security for both core Drupal and thousands of public modules, themes and distributions that add additional features. When a security problem is found with Drupal core, the team fixes the problem and publishes advisories that explain vulnerabilities, along with steps to mitigate them. All of this is contributed publicly and freely, just like you would expect from open source software. 

The security team supports versions of Drupal until they reach their end-of-life. 

But after the EOL, the baton is passed along to an Extended Security Support team. This team is composed of pre-vetted Drupal agencies, and they are commercially funded by those clients who want to pay for the extended security support. They are mandated to publicly release fixes for most of the security vulnerabilities that they find. 

“Hold on. What level of security support do I need?”

Before we talk about what you should do about D7 EOL, you first need to think about how important security is for your website.

  • Are there people who are actively trying to attack your website (maybe because of your strong stance on a particular issue)?
  • Does your website process commercial transactions? (Most non-profit websites these days use third-party websites to process donations and event registrations.)
  • Does your website collect a lot of personally identifiable information (PII)? This relates back to the first point: if there’s lots of valuable PII, an attacker will be more interested in trying to steal it. 

If you answered “yes” to any of these questions, then security is of extra importance for you.

“I won’t have the budget for a big website rebuild before November 2021” 

It’s going to be okay, we’ve got a few options for you. You’ll fall into one of the following categories:

1. “Security is really important for our website, we need Extended Security Support”

Regardless of whether you are an existing client, or someone we’ve never worked with before, please reach out to us and let us know if we can help.

2. “Security is just as important to our website as it is for every other website, but not in an extra special way”

If your website does not have a reason for someone to actively try to attack it, then you only need to be guarded from publicly known security vulnerabilities. That way, you’re protected against the automated attacks that hit every website. Typically those kinds of automated attacks are either trying to use your web servers to mine bitcoin, or lock up your website and demand a ransom. 

When Drupal 6 reached end-of-life in 2016 we continued to support our Drupal 6 clients using the publicly released updates from the Extended Security Support team. Our last Drupal 6 client just got a new website a few months ago! 

We’ll do the same when Drupal 7 reaches end-of-life. When a Drupal 7 update is released, we’ll update your website, just like we already do for all of our Drupal and WordPress support and maintenance clients.

3. “Help, I have no idea what I need!”

No problem. We can help here too. Regardless of where you’re at — or where you’re going next — we’re here to help. Drop us a line.

Making the web a better place to teach, learn, and advocate starts here...

When you subscribe to our newsletter!

Jan 23 2020
Jan 23
Allan Chappell

Allan Chappell

Senior Support Lead

Allan brings technological know-how and grounds it with some simple country living. His interests include DevOps, animal husbandry (raising rabbits and chickens), hiking, and automated testing.

January 23, 2020

In the Drupal support world, working on Drupal 7 sites is a necessity. But switching between Drupal 7 and Drupal 8 development can be jarring, if only for the coding style.

Fortunately, I’ve got a solution that makes working in Drupal 7 more like working in Drupal 8. Use this three-part approach to have fun with Drupal 7 development:

  • Apply Xautoload to keep your PHP skills fresh, modern, and compatible with all frameworks and make your code more reusable and maintainable between projects.
  • Use the Drupal Libraries API to use third-party libraries.
  • Use the Composer template to push the boundaries of your programming design patterns.

Applying Xautoload

Xautoload is simply a module that enables PSR-0/4 autoloading. Using Xautoload is as simple as downloading and enabling it. You can then start using use and namespace statements to write object-oriented programming (OOP) code.

For example:

xautoload.info

name = Xautoload Example
description = Example of using Xautoload to build a page
core = 7.x package = Midcamp Fun

dependencies[] = xautoload:xautoload

xautoload_example.module

 'xautoload_example_page_render',
    'access callback' => TRUE,
  );
  return $items;
}

function xautoload_example_page_render() {
  $obj = new SimpleObject();
  return $obj->render();
}

src/SimpleObject.php

 "

Hello World

", ); } }

Enabling and running this code causes the URL /xautoload_example to spit out “Hello World”.

You’re now ready to add in your own OOP!

Using third-party libraries

Natively, Drupal 7 has a hard time autoloading third-party library files. But there are contributed modules (like Guzzle) out there that wrap third-party libraries. These modules wrap object-oriented libraries to provide a functional interface. Now that you have Xautoload in your repertoire, you can use its functionality to autoload libraries as well.

I’m going to show you how to use the Drupal Libraries API module with Xautoload to load a third-party library. You can find examples of all the different ways you can add a library in xautoload.api.php. I’ll demonstrate an easy example by using the php-loremipsum library:

1. Download your library and store it in sites/all/libraries. I named the folder php-loremipsum.

2. Add a function implementing hook_libraries_info to your module by pulling in the namespace from Composer. This way, you don’t need to set up all the namespace rules that the library might contain.

function xautoload_example_libraries_info() {
  return array(
    'php-loremipsum' => array(
      'name' => 'PHP Lorem Ipsum',
      'xautoload' => function ($adapter) {
        $adapter->composerJson('composer.json');
      }
    )
  );
}

3. Change the page render function to use the php-loremipsum library to build content.

use joshtronic\LoremIpsum;
function xautoload_example_page_render() {
  $library = libraries_load('php-loremipsum');
  if ($library['loaded'] === FALSE) {
    throw new \Exception("php-loremipsum didn't load!");
  }
  $lipsum = new LoremIpsum();
  return array(
    '#markup' => $lipsum->paragraph('p'),
  );
}

Note that I needed  to tell the Libraries API to load the library, but I then have access to all the namespaces within the library. Keep in mind that the dependencies of some libraries are immense. You’ll very likely need to use Composer from within the library and commit it when you first start out. In such cases, you might need to make sure to include the Composer autoload.php file.

Another tip:  Abstract your libraries_load() functionality out in such a way that if the class you want already exists, you don’t call libraries_load() again. Doing so removes libraries as a hard dependency from your module and enables you to use Composer to load the library later on with no more work on your part. For example:

function xautoload_example_load_library() {
  if (!class_exists('\joshtronic\LoremIpsum', TRUE)) {
    if (!module_exists('libraries')) {
      throw new \Exception('Include php-loremipsum via composer or enable libraries.');
    }
    $library = libraries_load('php-loremipsum');
    if ($library['loaded'] === FALSE) {
      throw new \Exception("php-loremipsum didn't load!");
    }
  }
}

And with that, you’ve conquered the challenge of using third-party libraries!

Setting up a new site with Composer

Speaking of Composer, you can use it to simplify the setup of a new Drupal 7 site. Just follow the instructions in the Readme for the Composer Template for Drupal Project. From the command line, run the following:

composer create-project drupal-composer/drupal-project:7.x-dev  --no-interaction

This code gives you a basic site with a source repository (a repo that doesn’t commit contributed modules and libraries) to push up to your Git provider. (Note that migrating an existing site to Composer involves a few additional considerations and steps, so I won’t get into that now.)

If you’re generating a Pantheon site, check out the Pantheon-specific Drupal 7 Composer project. But wait: The instructions there advise you to use Terminus to create your site, and that approach attempts to do everything for you—including setting up the actual site. Instead, you can simply use composer create-project  to test your site in something like Lando. Make sure to run composer install if you copy down a repo.

From there, you need to enable the Composer Autoload module , which is automatically required in the composer.json you pulled in earlier. Then, add all your modules to the require portion of the file or use composer require drupal/module_name just as you would in Drupal 8.

You now have full access to all the  Packagist libraries and can use them in your modules. To use the previous example, you could remove php-loremipsum from sites/all/libraries, and instead run composer require joshtronic/php-loremipsum. The code would then run the same as before.

From here on out, it’s up to your imagination. Code and implement with ease, using OOP design patterns and reusable code. You just might find that this new world of possibilities for integrating new technologies with your existing Drupal 7 sites increases your productivity as well.

Making the web a better place to teach, learn, and advocate starts here...

When you subscribe to our newsletter!

Apr 04 2013
Ed
Apr 04
Recently I have been looking at how we measure contributions to science in a way that is more well-rounded than the h-index and similar initiatives. Most of this relates to how we measure a user's contributions to projects such as Scratchpads, ViBRANT and eMonocot.

The "alternative metrics" movement has been around for a number of years now, and one of the more established outfits is Altmetric who provide badges for research articles showing how much attention that article has received on a number of purely social (Twitter, Facebook) and 'academic social' (Mendeley, Connotea) networks.

As the badges are pretty easy to implement I have made a small Drupal module that displays an Altmetric badge on Biblio node pages, and provides a configuration page to allow the badges to be customised. The module is available here: Drupal biblio altmetric.


Jan 16 2013
Ed
Jan 16
A new Drupal module: Biblio autocomplete.

Previsoulsy as part of eMonocot we started to use the IPNI webservice to autocomplete some fields in the Biblio content type. As one of the eMonocot objectives is to "Ensure that the tools developed are compliant with zoological nomenclature" I have extended this functionality to use the ZooBank API which is currently in a testing phase. In addition values for the autocomplete suggestions can be made from values previous entered in other Biblio nodes.

Instead of having either previsously entered values, IPNI or ZooBank attempt to autocomplete the field this module has been developed to allow any combination of these plugins to attempt the autocompletion. This will have uses in cases like the recent Lyme Regis Geo-BioBlitz where a single classification spand both animal and plant kingdoms (in this case the Dictioanry of UK Species).

The module is designed so that additional plugin modules can easily contribute results for other webservices.

This work was done as part of eMonocot as a contribution to the Scratchpads project.

Dec 02 2011
Dec 02
For a lot of my recent projects I have used the Omega theme as the base theme, I love the whole responsive design support and grid system. But when you create a Panels page and choose a layout you don’t get the same grid support as you do with Omega. Panels outputs its own grid … Continue reading "Custom grid panels layout with Omega theme"
Sep 22 2011
Sep 22
Update: I have written an updated version of this series over athttp://webwash.net. The updated version covers Display Suite 7.x-2.x. Configuring Layouts with Display Suite in Drupal 7 Handling View Modes and Regions with Display Suite in Drupal 7 This post is part of a Display suite series, Display suite part 1: Layouts and Styles andDisplay … Continue reading "Display suite part 2: View modes and fields"
Sep 11 2011
Sep 11
Update: I have written an updated version of this series over athttp://webwash.net. The updated version covers Display Suite 7.x-2.x. Configuring Layouts with Display Suite in Drupal 7 Handling View Modes and Regions with Display Suite in Drupal 7 The Display suite is a powerful module which allows you to customise the node view page without … Continue reading "Display suite part 1: Layouts and Styles"
Jul 01 2011
Jul 01
The Field Slideshow makes it easy to create a slideshow from just an image field. With Fields in core for Drupal 7 we also got a more powerful display formatters for fields. Fields now ship with their own formatter settings forms and make it really easy to change the display of a field, and Field … Continue reading "Create a slideshow using the Field Slideshow module"
Apr 29 2011
Apr 29
Update: This tutorial is out-of-date. Please go to Search API’s getting started page for up-to-date documentation. The Search API is a Drupal 7 search framework module. It allows you to create custom search pages on any URL and integrates with a few search backends. In this article I’ll show you how to setup Search API … Continue reading "How to setup Search API with Apache Solr"
Mar 30 2011
Mar 30
The backup and migrate module is an awesome module that you can use to create a MySQL dump file. You can use it to schedule database backups to the server filesystem, remote FTP server or even an amazon s3 bucket. In this post I’ll demonstrate how to setup a scheduled backup to a remote FTP … Continue reading "Backup to a remote FTP using the Backup and Migrate module"
Mar 21 2011
Mar 21
When I upgraded zugec.com to Drupal 7 I had to find another syntax highlighter because the previous one that I used in Drupal 6 was GeSHi but this module hadn’t been upgraded to Drupal 7 at the time. I searched around and found Syntax Highlighter module which uses the SyntaxHighlighter library. In this post I’ll … Continue reading "How to use the Syntax Highlighter module in Drupal 7"

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