Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Jul 25 2019
Jul 25

Submitted by karthikkumardk on Thursday, 25 July 2019 - 15:29:44 IST

file_scan_directory is deprecated and has been moved to the file_system service.

Before:

$files = file_scan_directory($directory);

After

if (is_dir($directory)) {
  $files = \Drupal::service('file_system')->scanDirectory($directory);
}

When possible, you should inject the FileSystemInterface into your constructor.

Original source - https://www.drupal.org/node/3038437

Jul 23 2019
Jul 23

Here at Phase2, we’re excited to participate in the premiere Drupal government event, Drupal GovCon, held at the National Institutes of Health campus in Bethesda, Maryland where we'll once again be a platinum sponsor.

We hope you will join us for one of North America’s largest Drupal camps, this week.  

You can find Phase2 at our sponsor booth and all over the session schedule:

Why Migrate To Drupal 8 Now

With Drupal 9’s release impending, there has been a resurgence of chatter around Drupal 6/7 migration. If your government organization is still on Drupal 6 or 7 you will won’t want to miss this session. You can read more about the subject here from our on-site presenters, Tobby Hagler, Director of Engineering, and Felicia Haynes, Vice President of Accounts.

Measuring What Matters: Using Analytics To Inform Content Strategy

Content Strategy is the backbone to any successful digital experience. It’s also rarely considered an analytical process, but it should be! Catch our session to learn more, and in the meantime, read about the top 3 content strategy tips for government ahead of Jason Hamrick’s session.

Accessible Design: Empathy In A World With No Average

Our Accessibility expert, Catharine McNally, has a special treat for her session’s attendees: she’ll be hosting some interactive empathy building exercises, to showcase the impact of accessible design for citizens. This is a unique opportunity for anyone involved in the design, content, and UX of their organization’s/agency’s digital experience.

Personalization & Government: The Odd Couple or The Perfect Match?

Personalization has become the new standard, across industries, for improving customer experience, but how can personalization be leveraged in government? Join our CEO, Jeff Walpole, and Vice President of Business Development, Ben Coit,  to explore use cases and how governments can continue thinking about the next generation of citizen experiences.

Read more about scaling personalization in our recent whitepaper

Jul 19 2019
Jul 19

Redis is an open-source, networked, in-memory, key-value data store that can be used as a drop-in caching backend for your Drupal

Add the Redis module from Drupal.org. You can install and enable the module from the command line.

Edit sites/default/settings.php to add the Redis cache configuration. These are the mandatory, required Redis configurations for every site.

// Use Redis for caching.
$conf['redis_client_interface'] = 'PhpRedis';
// Point Drupal to the location of the Redis plugin.
$conf['cache_backends'][] = 'sites/all/modules/redis/redis.autoload.inc';
$conf['cache_default_class'] = 'Redis_CacheCompressed';
$conf['cache_prefix'] = array('default' => 'pantheon-redis');
// Do not use Redis for cache_form (no performance difference).
$conf['cache_class_cache_form'] = 'DrupalDatabaseCache';
// Use Redis for Drupal locks (semaphore).
$conf['lock_inc'] = 'sites/all/modules/redis/redis.lock.inc';

Enable the module via from /admin/modules

Verify Redis is enabled by going to the Dashboard and clicking "Connection Info". If you see the Redis cache connection string, Redis is enabled

Visit /admin/config/development/performance/redis and open Connection Information to verify the connection.

And once the Redis server is connected, one could use the PhpRedis functions to set the key & value pairs on Redis as seen below

function _get_value_redis_cache($key) {
    try {
        $redis = Redis_Client::getClient();
        return $redis->get($key);
    }
    catch (Exception $exception) {
        watchdog('redis_cache', t('Error, while getting the value from redis cache.'), custom_log(array($key, $redis)), WATCHDOG_ERROR);
    }
}

function _set_value_redis_cache($key, $value) {
    try {
        $redis = Redis_Client::getClient();
        $redis->set($key, $value);
        $now = time();
        $redis->expireAt($key, $now + 900);
        $redis->save();
    }
    catch (Exception $exception) {
        watchdog('redis_cache', t('Error, while setting the value from redis cache.'), custom_log(array($key, $value, $redis)), WATCHDOG_ERROR);
    }
}

Once these generic functions are ready, one could utlize this functions for setting and getting the values based on the keys as seen below

$key = "_get_tmp_value_from_redis";
$tmp = _get_value_redis_cache($key);
if (empty($tmp)) {
    $tmp = get_actual_value_from_db();
    _set_value_redis_cache($key, $tmp);
    return $tmp;
}
else {
    return $tmp;
}

cheers :)

Jul 17 2019
Jul 17

The Migrate Drupal UI module provides a web browser user interface for upgrading from Drupal 6 / 7 to Drupal 8. There is a pre-upgrade analysis which displays a list of legacy modules that will be upgraded and will not be upgraded. Included in those that will be upgraded are modules that do not need an upgrade, such as the Help module. In order for this analysis to be correct, some Drupal 8 modules must provide information in a MODULE_NAME.migrate_drupal.yml file in the module's migrations/state directory.

This applies to Drupal 8 modules that:

  • Provide migrations from a Drupal 6 or Drupal 7 module, or
  • Intend to provide those migrations in the future, or
  • Are a successor to a Drupal 6 or Drupal 7 module and want to communicate that no migration is needed.

This does not apply to modules that are brand new in Drupal 8 and have nothing to communicate about any Drupal 6 or Drupal 7 modules.

Syntax

finished:
  6:
    source_module: destination_module
    source_module_2: destination_module
    source_module_3:
    - destination_module
    - destination_module_2

  7:
    source_module: destination_module
    source_module_3:
    - destination_module
    - destination_module_2

not_finished:
  7:
    source_module_2: destination_module

As can be seen above, the data in migrations/state/MODULE_NAME.migrate_drupal.yml consists of migration sets where each set is a source module for a legacy Drupal version (6 or 7), and one or more destination modules for the current Drupal version (8). The source module and destination modules correspond to the source_module and destination_module definitions in the migrations. And each set can be declared either 'finished' or 'not_finished'. For a set to be "finished", all of the migrations for the set must exist. If a module maintainer knows that they have not yet provided all of the migrations that are needed from a given source module to one or more destination modules, then they should declare that set as "not_finished".

Merging state across provider modules, source modules, and destination modules

Each module's migrations/state/MODULE_NAME.migrate_drupal.yml file defines the state of the migrations that are provided (or intended to be provided in the future) by that module. In most cases, destination modules are the sole providers of migrations to themselves. For example, the dblog module is the sole module that provides migrations from earlier versions of itself to itself. In some cases, modules provide migrations for other destination modules. For example, the Content Translation module provides migrations from earlier versions of the Statistics module to the current version of the Statistics module. This is in addition to the migrations provided by the Statistics module itself.

The Migrate Drupal module considers a source module / destination module pair as not finished if there is any provider that declares it as not finished. For example, in the above example, if the Content Translation module in its .migrate_drupal.yml were to declare that statistics: statistics were "not_finished", then Migrate Drupal considers that pair to be not finished, even if the Statistics module itself is finished with the migrations that it intends to provide.

Similarly, a given source module is considered not finished overall, if there exists at least one destination module for which it is declared as not finished. For example, there are migrations from the Drupal 6/7 Menu module to several Drupal 8 destination modules (System, Menu UI, and Custom Menu Links). If any one of those pairs (e.g., menu: system, menu: menu_ui, or menu: menu_link_content) were declared as not finished (by any provider module), then on the Migrate Drupal UI pre-upgrade review screen, the Menu module would be listed as "will not be upgraded".

Usage

If the Drupal 8 module is not providing migrations, now or in the future, for its legacy version then create a migrate_drupal.yml. Declare a finished migration for each legacy Drupal version. See scenario 1 below.

If the Drupal 8 module is or will be providing migrations for a legacy module then create a migrate_drupal.yml file. For each source_module:destination_module pair used by the migrations in your module do the following for Drupal 6 and Drupal 7.

  • If the migrations for the pair are complete add a line in the "finished" array for the relevant Drupal version.
  • If at least one migration for a pair exists but the pair is not finished add an entry to "not_finished" for the relevant Drupal version.
  • If the migrations needed for the pair do not exist then add a line in the "not_finished" array for the relevant Drupal versions.

Examples

Scenario 1. A successor to a legacy module that for any reason will not be providing a migration. Let's use Pirate as the example. Currently, if Pirate is enabled on the legacy site it will be displayed as will not be upgraded when it should be listed as will be upgraded. To make that happen simply declare a migration set with pirate as the source module and destination module as finished.

finished:
  6:
     pirate: pirate
  7:
     pirate: pirate

Scenario 2. The legacy version of your module has content and configuration that needs to be upgraded. Your module provides two migrations with the same source_module:destination_module pair for both Drupal 6 and Drupal 7 and all migrations are finished.

finished:
   6:
     google_analytics: google_analytics
   7:
     google_analytics: google_analytics

Scenario 3. Your module provides migrations. The Drupal 6 version is complete but the Drupal 7 is not. Note there may be zero or more migrations for Drupal 7 in your module but more are needed for it to be complete.

 finished:
    6:
      google_analytics: google_analytics
  not_finished:
    7:
      google_analytics: google_analytics

Scenario 4. Your module provides migrations for other modules with many pairs, such as Commerce Migrate Module.

finished:
    6:
      node: commerce_product
      system: commerce_store
    7:
      node: commerce_product
      commerce_product: commerce_product
      system: commerce_store
  not_finished:
    6:
      uc_orders: commerce_order
    7:
      uc_orders: commerce_order
      commerce_order: commerce_order

Scenario 5. Your module provides a migrate field plugin for a legacy field, such as Address Module.

  finished:
    6:
      adressfield: address
    7:
      adressfield: address

Scenario 6. Menu, JQuery UI, Blog, Color and many other modules moved directly into Core. These are denoted as 'core' for the destination and are treated specially. They are marked as finished since these do not have an upgrade path and site upgraders do not need to look for an equivalent project to install in Drupal 8.

finished:
  6:
    blog: core
    blogapi: core
    calendarsignup: core
    color: color
  7:
    blog: core
    bulk_export: core
    contextual: core
    ctools: core

Cheers :)

Jul 11 2019
Jul 11

On September 12–14, at Hilton Garden Inn Atlanta-Buckhead

Kaleem ClarksonKyle Mathews, 2019 DrupalCamp Atlanta Keynote

Trainings

Jul 08 2019
Jul 08

For the past three years, developers, IT, and marketing professionals have gathered in NYC for “Decoupled Days, a growing but impactful event with influential speakers and change agents from across the tech space, to share and learn about decoupled architecture solutions for some of the world’s leading brands and organizations.

While the topic of decoupled architecture solutions may seem hyper-specific for a two-day conference, there is an aggressively (growing) interest and investment in decoupled architecture strategies across industries, all to enable the digital brand experiences they require to stay competitive.

Decoupling the front end of an organization’s platform from their back end allows for more flexible design capabilities and the ability to update the design much faster at the speed that marketing teams need to move. When the back end of your website is decoupled, you can easily integrate and swap micro-services in and out to provide the latest and most useful tools and functionality without a complete site redesign.  

Here at Phase2, we work with many of our enterprise clients on decoupling their digital architectures to meet their brand experience goals. We’re thrilled to participate in the organization, sponsorship, and thought leadership of this event. If you plan to attend this year’s event, (and we think you should!), be sure to check out some of Phase2’s front-end leaders as they share best practices and cutting-edge tooling in the following sessions:

We hope you’ll join us July 17th-18th in NYC to learn more about business, technology, and diversity when it comes to decoupled architectures for seamless omnichannel brand experiences that inspire audiences.

Jul 01 2019
Jul 01

If you are running an old version of Drupal 8, it is likely that your site can be compromised by the known vulnerabilities. And to guard your site against possible hacks, you should update Drupal core to latest stable release in 8.x branch.

Drupal 8 Update | Joshi Consultancy Services

Updating Drupal 8 core

There are two ways to update Drupal 8 core:

1. Manually

2. Using composer

Below, we will learn how to use these methods to update Drupal 8 core.

1. Manually updating Drupal 8 core

If you are not using or managing your Drupal 8 website using composer, here are the steps to update your Drupal 8 core:

  • Tack backup of your site, both codebase and the Database. Download latest release of Drupal 8 core.
  • Copy all the files and directories from downloaded version except 'sites' and 'modules'. We assume you did not make changes to any core modules or themes. If you need to, take a backup of .htaccess and 'profiles' directory as well.
  • Overwrite your site codebase with copied files and directories.
  • Restore all the files that you previously modified.
  • Perform DB update and composer update.
  • At this stage, do not perform an update to contrib modules. Contrib module updates are not consistent and you can not rely on them to be act so. This is very efficient method when you did not alter any core or contrib module/theme files.

2. Using Composer

You can also update your Drupal 8 website using composer. This is most convenient way to update Drupal 8 website. You must have SSH access to sever in order to carry out the composer commands and update Drupal 8 core.

  • Execute composer update
  • Once done, execute drush updb
  • For consistency and to make sure everything is in order, execute drush cr

Congratulations! You have just updated your Drupal 8 website!!

Jun 23 2019
Jun 23
Starting a new Drupal 8 project? And the first thing you might do is to install a module, but which one first. There are a few obvious ones to install and sometimes these have no relation with the functionality of your project but they always help you in the background.
Jun 19 2019
Jun 19

(Available as freelancer)

Joris Snoek

Business Consultant
/ Drupal Developer

Last month we worked in a project where we implemented a progressively decoupled Drupal platform. We needed a React.js frontend to to all kind of magic that was less available in Twig. Also, this way frontend engineers and backend engineers could work more loosely together, which is great.

Main reason we choose progressive decoupled instead of fully decoupled is because we wanted to make use of Drupal's roles, permissions and authentication, plus some other Drupal native stuff that in fully headless would become very cumbersome to deal with.

Check out this blog on 'How to decouple Drupal in 2019' and find out if you also need Drupal beheading or not.

React libraries dynamically in Drupal

The target was to implement the React.js libraries in Drupal pages, so React would load withín Drupal and we could use all native Drupal goodies like authentication.

By the way: you can also use Drupal authentication when fully decoupled, check this article

So, the thing with React is: every time you release a new version of your App, you'll have to render a new build, that sort of looks like this:

More specifically, the .js and .css files we need to load in Drupal are defined in asset-manifest.json:

So, those files need to be loaded in Drupal, and change every time you run a new build in your React App for example with npm run build.

But you can't add these React javascript libraries to your theme's YOURTHEME.libraries.yml because with the next build the links be be different.

hook_library_info_build() to the rescue

Aaaah, so Drupal 8 provides us with hook_library_info_build() that will save our day (づ。◕‿‿◕。)づ

Now, how we did this:

Implement the Drupal hook in your .module file (For highlighting's sake, I added .php, loose that. #nobrainer):

As you see, it will read React's asset-manifest.json and registers all .js and .css files of React.js as a library in Drupal.

Next up, you can render this library for example in a Controller like this:

Wrap up

So that's how we integrated React.js within Drupal pages and combined the power of a React frontend with the power of Drupal goodies, in a 'progressively decoupled' way.

Please let me know if you have any questions.

Jun 12 2019
Jun 12

Some years ago, a frontend developer colleague mentioned that we should introduce SASS, as it requires almost no preparation to start using it. Then as we progress, we could use more and more of it. He proved to be right. A couple of months ago, our CTO, Amitai made a similar move. He suggested to use ddev as part of rebuilding our starter kit for a Drupal 8 project. I had the same feeling, even though I did not know all the details about the tool. But it felt right introducing it and it was quickly evident that it would be beneficial.

Here’s the story of our affair with it.

For You

After the installation, a friendly command-line wizard (ddev config) asks you a few questions:

The configuration wizard holds your hand

It gives you an almost a perfect configuration, and in the .ddev directory, you can overview the YAML files. In .ddev/config.yaml, pay attention to router_http_port and router_https_port, these ports should be free, but the default port numbers are almost certainly occupied by local Nginx or Apache on your development system already.

After the configuration, ddev start creates the Docker containers you need, nicely pre-configured according to the selection. Even if your site was installed previously, you’ll be faced with the installation process when you try to access the URL as the database inside the container is empty, so you can install there (again) by hand.

You have a site inside ddev, congratulations!

For All of Your Coworkers

So now ddev serves the full stack under your site, but is it ready for teamwork? Not yet.

You probably have your own automation that bootstraps the local development environment (site installation, specific configurations, theme compilation, just to name a few), now it’s time to integrate that into ddev.

The config.yaml provides various directives to hook into the key processes.

A basic Drupal 8 example in our case looks like this:

hooks:
  pre-start:
    - exec-host: "composer install"
  post-start:
    # Install Drupal after start
    - exec: "drush site-install custom_profile -y --db-url=mysql://db:[email protected]/db --account-pass=admin --existing-config"
    - exec: "composer global require drupal/coder:^8.3.1"
    - exec: "composer global require dealerdirect/phpcodesniffer-composer-installer"
  post-import-db:
    # Sanitize email addresses
    - exec: "drush sqlq \"UPDATE users_field_data SET mail = concat(mail, '.test') WHERE uid > 0\""
    # Enable the environment indicator module
    - exec: "drush en -y environment_indicator"
    # Clear the cache, revert the config
    - exec: "drush cr"
    - exec: "drush cim -y"
    - exec: "drush entup -y"
    - exec: "drush cr"
    # Index content
    - exec: "drush search-api:clear"
    - exec: "drush search-api:index"

After the container is up and running, you might like to automate the installation. In some projects, that’s just the dependencies and the site installation, but sometimes you need additional steps, like theme compilation.

In a development team, you will probably have a dev, stage and a live environment that you would like to routinely sync to local to debug and more. In this case, there are integrations with hosting providers, so all you need to do is a ddev pull and a short configuration in .ddev/import.yaml:

provider: pantheon
site: client-project
environment: test

After the files and database are in sync, everything in post-import-db will be applied, so we can drop the existing scripts we had for this purpose.

We still prefer to have a shell script wrapper in front of ddev, so we have even more freedom to tweak the things and keep it automated. Most notably, ./install does a regular ddev start, which results in a fresh installation, but ./install -p saves the time of a full install if you would like to get a copy on a Pantheon environment.

For the Automated Testing

Now that the team is happy with the new tool, they might be faced with some issues, but for us it wasn’t a blocker. The next step is to make sure that the CI also uses the same environment. Before doing that, you should think about whether it’s more important to try to match the production environment or to make Travis really easily debuggable. If you execute realistic, browser-based tests, you might want to go with the first option and leave ddev out of the testing flow; but for us, it was a desirable to spin an identical site on local to what’s inside Travis. And unlike our old custom Docker image, the maintenance of the image is solved.

Here’s our shell script that spins up a Drupal site in Travis:

#!/usr/bin/env bash
set -e

# Load helper functionality.
source ci-scripts/helper_functions.sh

# -------------------------------------------------- #
# Installing ddev dependencies.
# -------------------------------------------------- #
print_message "Install Docker Compose."
sudo rm /usr/local/bin/docker-compose
curl -s -L "https://github.com/docker/compose/releases/download/1.22.0/docker-compose-$(uname -s)-$(uname -m)" > docker-compose
chmod +x docker-compose
sudo mv docker-compose /usr/local/bin

print_message "Upgrade Docker."
sudo apt -q update -y
sudo apt -q install --only-upgrade docker-ce -y

# -------------------------------------------------- #
# Installing ddev.
# -------------------------------------------------- #
print_message "Install ddev."
curl -s -L https://raw.githubusercontent.com/drud/ddev/master/scripts/install_ddev.sh | bash

# -------------------------------------------------- #
# Configuring ddev.
# -------------------------------------------------- #
print_message "Configuring ddev."
mkdir ~/.ddev
cp "$ROOT_DIR/ci-scripts/global_config.yaml" ~/.ddev/

# -------------------------------------------------- #
# Installing Profile.
# -------------------------------------------------- #
print_message "Install Drupal."
ddev auth-pantheon "$PANTHEON_KEY"

cd "$ROOT_DIR"/drupal || exit 1
if [[ -n "$TEST_WEBDRIVERIO" ]];
then
  # As we pull the DB always for WDIO, here we make sure we do not do a fresh
  # install on Travis.
  cp "$ROOT_DIR"/ci-scripts/ddev.config.travis.yaml "$ROOT_DIR"/drupal/.ddev/config.travis.yaml
  # Configures the ddev pull with Pantheon environment data.
  cp "$ROOT_DIR"/ci-scripts/ddev_import.yaml "$ROOT_DIR"/drupal/.ddev/import.yaml
fi
ddev start
check_last_command
if [[ -n "$TEST_WEBDRIVERIO" ]];
then
  ddev pull -y
fi
check_last_command

As you see, we even rely on the hosting provider integration, but of course that’s optional. All you need to do after setting up the dependencies and the configuration is to ddev start, then you can launch the tests of any kind.

All the custom bash functions above are adapted from https://github.com/Gizra/drupal-elm-starter/blob/master/ci-scripts/helper_functions.sh, and we are in the process of having an ironed out starter kit from Drupal 8, needless to say, with ddev.

One key step is to make ddev non-interactive, see global_config.yaml that the script copies:

APIVersion: v1.7.1
omit_containers: []
instrumentation_opt_in: false
last_used_version: v1.7.1

So it does not ask about data collection opt-in, as it would break the non-interactive Travis session. If you are interested in using the ddev pull as well, use encrypted environment variables to pass the machine token securely to Travis.

The Icing on the Cake

ddev has a welcoming developer community. We got a quick and meaningful reaction to our first issue, and by the time of writing this blog post, we have an already merged PR to make ddev play nicely with Drupal-based webservices out of the box. Contributing to this project is definitely rewarding – there are 48 contributors and it’s growing.

The Scene of the Local Development Environments

Why ddev? Why not the most popular choice, Lando or Drupal VM? For us, the main reasons were the Pantheon integration and the pace of development. It definitely has the momentum. In 2018, it was the 13th choice for local development environment amongst Drupal developers; in 2019, it’s at the 9th place according to the 2019 Drupal Local Development survey. This is what you sense when you try to contribute: the open and the active state of the project. What’s for sure, based on the survey, is that nowadays the Docker-based environments are the most popular. And with a frontend that hides all the pain of working with pure Docker/docker-compose commands, it’s clear why. Try it (again), these days - you can really forget the hassle and enjoy the benefits!

Jun 05 2019
Jun 05

The latest version of Drupal is version 8.7.2. You’re familiar of course. In fact, you’ve been on pins and needles ever since version 8.7.1(a). I’m sure you’ve been instasnaptweeting ever since it was issued.

OK, back to reality: You’re definitely more concerned with getting the data you need, driving great brand interactions, and maintaining costs (and keeping your InfoSec or IT teams happy)—than the latest CMS version.

However, what if I told you that your outdated Drupal 6 or 7 instance could actually hinder you from innovating, drain your budget, and potentially cause unnecessary security risks? And that once you get to Drupal 8, migration costs, security updates, and best-of-breed functionality (like content management and media libraries) from core Drupal contributions will help you deliver the audience experiences that grow your business.

So, should you migrate to Drupal 8 immediately? Yes.

Here’s why:

  • More languages? Not a problem: multilingual capabilities - It doesn’t take an engineering background to know that creating a multilingual site is not an easy task. Taking a step back, there are so many questions to consider:

    • Should content be displayed in a single native language?

    • What percentage of your site traffic is in English vs. other languages?

    • How should you handle media files?

    • Is there a risk if changes are incurred by translations?

    • Will the translations be handled properly? Who will handle translations?

The good news is that creating a multilingual site became a lot easier with Drupal 8 with benefits for both site admins and end users. Drupal 8 is now part of “core” (the basic features). In previous versions of Drupal, you needed to install extra modules (collection of files that contain some functionality)  just to support multilingual, which meant a lot more work, added costs and additional maintenance. Drupal 8 brings multilingual support to core with 4 modules, localized content (which makes usability and translations easier so that content translation can be possible for all types, including taxonomies, field types et al) and there are 100+ default languages included.

  • Ease of content editing - Building layouts has never been more intuitive than with Layout Builder! The tl;dr for Layout Builder allows fielded content on the back-end, but a true drag and drop front-end editing experience. There are even more added benefits including a flexible, admin interface, use of contextual links while keeping structured data. And you can now create layouts for templated content with Layout Builder. Many of Drupal’s competitors don’t allow such a templated approach to be done in browser.  (P.S. Learn more on this fantastic page-editing experience from my colleague, Caroline Casals here.)

  • Responsiveness for all - Responsive behavior is no longer a nice-to-have, but de rigueur.  This was an add-on in Drupal 7, but a built-in feature with Drupal core includes built-in themes that are mobile responsive. Additional web services now allow for content to be accessible from Alexa, Siri, and other virtual assistants.

  • Speed matters! - Drupal 8 has features that will make your websites faster without the need for a lot of technical experience. “Cache tags” are used making caching more efficient and also page loads faster.

  • More robust security - Drupal 8 is the stable version of Drupal; functionalities and major modules have been ported over and are now supported by the Drupal open-source community.

  • Integration friendly - Drupal 8 is set-up so that site administrators can easily use APIs to connect to a number of digital tools. Think: your deep integrations, like web analytic platforms, customer relationship management (CRM), email campaigns, social networks and marketing automation systems; you can rest easier that they’ll perform and communicate in concert.

So why else should you invest now? Drupal 7 is currently on life support.  As of November 2021, Drupal 7 will reach it’s “end of life” (EOL) which means that the version will no longer be supported by core maintainers.  

“No longer being supported” also means the following:

Drupal 9 is scheduled to be released next year (2020) which gives companies about a year to upgrade to Drupal 8. Don’t panic, but develop a reasonable plan for when you'll stop investing in your Drupal 7 platform, keep your site as up-to-date as you can (this will help security), and get on Drupal 8 as fast as you can. Still have questions? Give me a shout.

Jun 04 2019
Jun 04

Historically, migrating your content management system (CMS) or content platform from one major version of Drupal to the next was nothing short of a Herculean task.

Every new version of Drupal meant rebuilding existing functionality, converting (or migrating) your content, and accepting significant changes along the way. Because of this, it’s become commonplace to see stakeholders want to leapfrog Drupal versions (e.g., 5 to 7, or 6 to 8), to extend the life of both their old and new platforms for as long as possible for the least amount of transitional pain.

But this is no longer the case.

If you’ve been swimming in Lake Drupal for the last year, you’ve already heard the clarion call to prepare for Drupal 9, due to release in June of 2020. Most of the messaging has been tailored towards planning ahead for your migration, regardless of what version your CMS sits on today.

All too often, many of those plans call for waiting until Drupal 9 is ready before migrating away from your older platform… you know, to leapfrog ahead and save yourself the pain of CMS migration more frequently than you need.

And that’s only half the story.

If you’re not already on Drupal 8, the time to migrate is now. Drupal 9’s release within a year marks the end of life for Drupal 7. You could be incurring unnecessary security risks, all manner of technical debt, and a deluge of growing time-to-cost barriers — all while missing out on the most useful Drupal 8 features for marketers and developers like Layout Builder, an extensible media management system, and editorial workflow. Most importantly, Drupal 8 is essentially Drupal 9, so you’ll be ready for that upgrade when the time comes without another major effort.

Read: When the time comes, your Drupal 8 site can become Drupal 9 without migrating again.

TL;DR: Migrate Out of 6 or 7 Before 9 Drops

If you already know you need to migrate from Drupal 6 or Drupal 7, but you’re not sure where to begin, read this primer to help you scope, identify, and take steps to start the process.

If you’re still not convinced why you should already be migrating, here’s why it’s critical to begin migration ASAP.

If you’re on 6

  • Drupal 6 support has already ended (as of February 2016). If you’re still on this version, you’ve got unmitigated security risks that, if left unchecked, could cost your organization unforeseen resources or damages.

  • Migration from Drupal 6 will not be part of Drupal 9 core. It will be deprecated in Drupal 8.8 and removed in Drupal 9 to become a contrib module.

  • Core migration maintainers will manage the contrib module and support it for a while, but it will eventually become community owned. That leaves the future direction of that module unclear.

If you’re on 7

  • Support ends in 2021 (and that’s not too far off!). If you haven’t planned or budgeted for this, it’s time to start now, especially if your budget planning is a traditional calendar year

  • You might have painful memories of past Drupal migration. While previous versions were, in fact, incompatible across migrations, this is not the case from Drupal 7 to Drupal 8

  • This is the “last great migration.” Migrating from Drupal 8 to future versions (Drupal 9 and beyond) won’t require a similar migration effort. Upgrading from Drupal 8 to Drupal 9 will be more or less a drop-in-replacement as a version bump. Relatively speaking, there will be significantly less effort in upgrading from Drupal 8.9 to Drupal 9.0 than in previous core versions.

  • You don’t want to spend the next 12-16 months on an old system that you’re already wanting to upgrade. Just rip the band-aid off now. Drupal 9 is essentially a version of Drupal 8 — so the wait is needless, and will only be more complex and costly when making a two-version jump.

  • When Drupal 7 support is officially dropped, security updates will only be managed by third-party vendors.

[Note for developers: here’s how to navigate some of the more complex aspects of 8 on D7.]

[Note for marketers: even two years ago, we hosted a webinar on the benefits of Drupal 8 for marketers.]

But Drupal 8 Isn’t Drupal 9, Yet

On the day of release, Drupal 9.0 will be the same as Drupal 8.9, but with these significant differences:

  • External dependencies (such as Symfony) will be upgraded to the latest major version.

  • Deprecated code in Drupal 8 will be removed, potentially breaking custom or contrib modules still using that code.

Otherwise, there will be no significant core API breaking changes (as in previous major version upgrades), maintaining all the same core features and functionality. This means that you can effectively upgrade from Drupal 8 to Drupal 9 without overhauling your CMS or migrating content, simply by updating a point release.

Migrating to Drupal 8 now will prepare you for Drupal 9, but you will still need a Drupal 9 readiness plan. Knowing what is being deprecated and how that affects your CMS is essential to your roadmap. However, with a readiness plan in hand, your Drupal 8/9 platform’s lifespan will be significantly increased.

Bottom-line: The thing that you’re waiting for is already here. Don’t cling to an old system that doesn’t meet your needs anymore — and is potentially costing you more time, money, and increasing your security risk. 

Resource Bank:

May 27 2019
May 27
Damn you, DEV-MASTER! jflynn Mon, 05/27/2019 - 16:12 Category Development Tags Drupal Planet Comments Generic
May 20 2019
May 20

We are on our journey to master the Drupal performance, after having our previous Part 1: Caching published a couple of weeks ago, we've been lucky enough to get into Issue 386 of TheWeeklyDrop newsletter, Planet Drupal, and got much love and good feedback on Twitter.

If you haven't already read the first part of the series, the ultimate guide for faster Drupal: Part 1 Caching, please feel free to read that article too.


Note: You don't necessarily have to do all of these, some items listed here are replaceable with each other as well, so proceed with caution!

Faster Drupal - Part 2: Aggregation and CDN

  • The one and the only holy grail: Advanced CSS/JS Aggregation
    On every Drupal optimization post you’d read you have to setup and configure AdvAgg module, but you gotta do what you gotta do!
    AdvAgg features and core benefits are listed on the module page completely, so go ahead and read them all, configure it the way that works best for you and move on
    Advanced CSS/JS Aggregation Drupal module

    Note: If you have Mod Pagespeed you might not need AdvAgg module, make sure that you don't overlap your own work

    But that’s not all, if you are on Drupal 7, you should consider checking Speedy module as well, in some areas, this might work a bit better so make sure to check it out as well
    Speedy module

  • For good JavaScript minification in Drupal, you can use modules such as minify but we’d like to recommend minifyJS instead, they listed the differences and benefits on their module page so check it out
    Drupal MinifyJS module

  • CDNize the whole project, as much as you can! You may use CDN module too

  • Move JavaScript to the footer if necessary, some JS files need to be rendered in the head based on the use case and what does the JS do! Also in Drupal 8, it’s quite easy to append your necessary library (Read it JS files) in the footer in twig template files

  • Consider if you can make your own scripts defer/async (a new challenge when it comes to Drupal js aggregation)

Okay, this round was much easier thanks to AdvAgg module for taking care of half of the things we need to do for us! Note that on the frontend side you can Uglify, Minify and make sure everything that you code, will become compressed, whether it’s CSS, JS or even images or SVG files! Now let's get to it, Image optimization. 

Image optimization

  • Drupal 8: Use the Responsive Image module wherever possible and create the appropriate styles. It uses the tag which is what we really want

  • One might say we have one too many image optimization modules in Drupal, which is a good thing! For that we tested some, experienced with some of them and here’s what we suggest: Use blazy and lazyload_images (Drupal 8 that uses IntersectionObserver instead of scrolling events), Also consider: lazyloader and image_lazy_loader when using the picture module for responsive images in Drupal 7. There is also a lazy loading option that works well

  • Image optimization: for main images/icons used in the design (Yes you can optimize SVG files as well), also the best tool for that is not in Drupal, try ImageOptim desktop app, Also there’s an API-based service available with a Drupal 7 module, take a look here, might worth setting/selling this up to clients

    Also in the same context, we can use ReSmush.it which is free (But should donate some beer to them)
    Drupal 7 Module, Drupal 8 Module

  • Image formats like JPEG 2000, JPEG XR, and WebP often provide better compression than PNG or JPEG, which means faster downloads and less data consumption. There's a really good module that help you serve WebP, it's called, you guessed it; WebP.

  • Serve WebP images with your web server with the MOD PageSpeed by Google for Apache and Nginx.
    Or conditionally serving WebP images with Nginx.
     

Bonus tip: Even favicons should be optimized. Sometimes people ignore the weight of a favicon file. You shouldn’t! 

 

For the next week, we will be covering subjects regarding Drupal database/web server tweaks & improvements, stay tuned.

Written by Sohail LajevardiSohail Lajevardi
Developer at Ramsalt Lab

May 18 2019
May 18

So I needed the latest git checkout of the source code from external entities Drupal module. Its latest is 8.x-2.x

Using composer require drupal/external_entities is not enough as that will download the latest released version in this case 8.x-2.0-alpha1

Using composer require drupal/external_entities:8.x-2.x is not a valid version for composer as Drupal versions are not semantic versioned.

We should use as version 2.x which is a Drupal 8 compatible branch . SemVer can work with dev versions using 2.x-dev so using composer require drupal/external_entities:2.x-dev we get the latest dev. But still as zip

By altering composer.json setting a preferred-install for the module we finally get the latest git checkout.

"config": {
    "preferred-install": {
        "drupal/external_entities": "source",
        "*": "dist"
    },
    "autoloader-suffix": "Drupal8"
}

After running composer require drupal/external_entities:2.x-dev we get a git checkout but it is a detached head.

cd modules/contrib/external_entities
git status
HEAD detached at 809e275
nothing to commit, working tree clean

The final step is to do git checkout origin and you can create patches.

Refs

May 02 2019
May 02

Part of me is suspecting that I may be one of the lucky 10,000 today but I figure it's worth putting this out there because if I wasn't aware of this then there may be others too. It turns out that the version of Drush that you just installed may not be the version of Drush that executes your command.

So, as it happens there's a number of ways to install Drush. Older OSs may have it in the package management system, you may have just installed it globally using the instructions on the site, or, if your project is managed by composer it may have been installed as a site-local version. In my case I had messed it up just a little and had multiple versions hanging around and, despite having definitely downloaded and installed drush 8.2.3 to /usr/local/bin/drush and I confirmed that this was being called via which drush when I ran drush --version it informed me I was running version 9.6.2.

The thing that I didn't know... Drush will check the directory the site is in to see if there is a local-site version installed and pass off the request to that. So despite having Drush 8.2.3 installed and called from the command line the request was finding the local copy and returning results from that. If it wasn't for the fact that this was a Drupal 7 site and I'd inadvertently installed Drush 9.x locally via composer. If it wasn't for the fact that Drush 9.x doesn't support Drupal 7.x I'd never have known that this was how it worked.

Big thanks to Kirill for correcting my brain meat on this.

Apr 26 2019
Apr 26

 

 

In the first part of this blog, we had completed the installation and had also created blocks for custom block types. In this part, we will see how to configure the TB mega menu so that we can get the structure of the menu ready as per our design.

 

Configuring the TB mega menu and placing the TB mega menu block in a region are two separate things.

 

The TB mega menu can be configured for an existing menu. So, you need to ensure that you have a complete hierarchy of menu ready before you begin the configuration. However, you can modify the links later on from the TB mega menu configuration page.

 

If you already have a menu that you want to use then you are already a step ahead! If not, then go to /admin/structure/menu and click on the Add menu. Create the menu as you normally would.

 

For demonstration purposes, we will be using the below menu structure. Let the name of this menu be Example menu:

 

Parent 1

    -Child (1)

        -Child (1) content

    -Child (2)

        -Child (2) content

        -Sub child (1)

            -Sub child (1) content (This content will be displayed over the child (2) content)

        -Sub child (2)

            -Sub child (2) content (This content will be displayed over the child (2) content)

    -Child (3)

    -Child (4)

Parent 2

    -Child (1)

    -Child (2)

        -Sub child (1)

            -Sub child (1) content (This content will be displayed over the child (2) content)

        -Sub child (2)

            -Sub child (2) content (This content will be displayed over the child (2) content)

    -Child (3)

Parent 3

    -Child (1)

    -Child (2)

    -Child (3)

Implementation

Now that we have a clear idea of how we want our menu to look like we can start implementing the TB mega menu.

 

Before we do so, one thing we had noticed earlier is that there were contents embedded in the menu itself for certain menu items. The contents include:

  1. Title

  2. Image

  3. Description

 

Some of the block contents had all of the above fields while some of the block contents may only have the title and description. Also, we need another content which would have neither of the above. We would come to this part later on.

 

Since we know what the hierarchy of the menu is and what content the menu items need to have let us create these contents first so that we have the block ready (more on this later) when we start configuring the menu.

 

The contents we have for the menu items are rendered via a block. These blocks will be later on placed while configuring the menu.

 

Flashback time

 

Let’s rewind time! Earlier we had created a block type with certain fields. These fields were left on the user to create as it is a pretty straight forward process. For this demonstration purpose let us create the following fields for our block type.

  1. To create fields for the block type, go to admin/structure/block-types and click on Add block type.  Specify the Label and a description. Once done, click on Save block type.

  2. Next, you will be taken to the block type listing page which is /admin/structure/block-types. On this page you will have the option to Manage fields. You can add, edit or delete the fields for the particular block type from here.

  3. Once you click on the Manage fields option, you will be redirected to a page wherein you will be able to add or modify the fields.

  4. Initially you will have the following fields present by default:

    1. Label: this field corresponds to the name of the block.

    2. Title: this field corresponds to the title of the block.

    3. View mode: this field corresponds to the view mode of the bean.

    4. Revision settings: this field corresponds to the revision of the block.

    Note: these fields are provided by the bean module itself.

  1. Add the following fields by specifying a label and selecting the type:

    1. Menu item image:

      1. Label: Menu item image

      2. Field type: Image

      3. Widget: Image

You can add an image style to this field by going to the Manage display tab. Over there, click on the gear icon to the extreme right of this image field.

d8_manage_display

Once you do so, further configuration options will open. You will see an option to provide an Image style. Click on it and select the image style you want. Additionally, you can link this image to the content or the file. To do so, click on the Link image to option and select the desired option from the dropdown menu. Once done, click on Update and save the block type.

 

d8_update_save

 

    1. Menu item description:

      1. Label: Menu item description

      2. Field type: Long text

      3. Widget: Text area (multiple rows)

        The below image shows where you can create a field.

 

       

d8_menu_item

 

  1. Once done, save it and you will have your block type ready with the fields.

  2. Now you are ready to create the content for the block.

 

Creating content for the blocks

  1. To create the content for a menu item, go to /block/add/menu-item-content-block

  2. Fill out the below fields:

    1. Label: This is a mandatory field. This field corresponds to the blocks name i.e. this is the name of the block.

    2. Menu item image: This is an optional field. If we want to have an image in the content then that needs to be inserted here. On clicking browse, the media browser opens from where we can select the image file from our local storage or that residing on the server itself.

    3. Title: This refers to the title of the content.

    4. View Mode: This is a mandatory field. This field provides the default view mode for the bean. It would have a default option selected. Leave it as it is. This does not need to be modified.

    5. Menu item description: This refers to the description of the content.

    6. After the necessary information has been filled up, save the block.

  3. Now, the content for a particular menu item has been created as a block. Similarly, we can create blocks for other menu items. There can be a case where a particular menu item does not have an image. It only has a title, description and a link. In such a case, while creating the contents in the block as we did above, leave out the Menu item image blank i.e. without uploading anything in it. For another case, we would also require a common empty block, which would have nothing other than the block label. I will address this later on as where we exactly need it.

 

Now that we have the content ready we can start configuring the TB mega menu.

 

Configuring the TB mega menu

 

Initial configuration

  1. To configure the TB mega menu go to /admin/structure/tb-megamenu.

  2. Click on the config link for the menu that you want to be displayed.

  3. A page like the one below would open.

d8_initial_config

 

  1. This lists the 1st tier of menu items which we are referring to as the Parent menu item links with some options. The options include:

    1. Style: leave it as default.

    2. Animation: this might be selected as none. Change it to fading or some other animation style. This is because if no animation is selected then all the menu item contents would appear one above another and not only on hover, which is not what we want.

    3. Delay (ms): specify an animation delay as required.

    4. Duration (ms): specify an animation duration as required.

    5. Auto arrow: to hide the arrows next to items that have a submenu.

    6. Always show submenu: collapse submenus when browsing on small screens.

  2. This is all that we need to configure for the initial items visible when this page loads for the 1st tier (Parent) menu items.

  3. Now, let us move inside these links.

Creating child menu links

  1. Each of the child menu links is wrapped in containers. Let us name them for ease of use:

    1. Let us call the box that contains all the elements as the Container.

    2. Let us call the box that contains the elements directly as the Wrapper.

    3. Let us call the menu items as Elements.

  2. A visual representation will better support the explanation:

    1. Container.

             

d8_child_menu

 

  1. Wrapper.

 

d8_wrapper

 

  1. Element.

 

d8_element

 

  1. If there is a need to modify a certain menu link then that can be done by clicking on the Edit Links option on the right-hand corner of the page. This will redirect you to the menu link configuration page. Let us see below where it is

 

d8_edit_links

 

Add content to child (1)

  1. Click on Parent 1.

  2. Click on the first Element which is the child (1).

d8_parent1

 

  1. You will be able to see the option of Sub menu above. The value will be set as No. Toggle this option to Yes and a submenu for the child (1) will appear.

 

d8_child(1)

 

  1. Note: This submenu does not correspond to menu item links i.e. this is not for displaying a child menu link or any menu link to be precise. This submenu is for placing the content as a block. Menu items which have child menus will automatically appear under the respective menu items as they have been configured in /admin/structure/menu or by going into Edit Links as discussed above.

  2. We had earlier created a content for this which we would be placed as a block here. To do so, now you have to click on the submenu Element.

  3. Then click on the option which says Blocks: Select Block.

 

d8_blocks

 

  1. On doing so a drop down will appear with all the blocks.

 

d8_drop_down

 

  1. Select the block which has the content for this child menu item.

  2. In doing so the content will appear and look something like this:

 

d8_content_appear

 

  1. Do not worry if the design seems to break. This is just the configuration page and the design can be handled entirely through the CSS.

  2. Hence we have created content for a child menu.

Add content & submenu to the child (2)

Our design had a child (2) menu item which had two submenu links as well as content. This is a bit tricky. The functionality we sought was that:

  1. Hovering on the child (2) would display:

    1. The submenu links.

    2. The content for the child (2).

  2. Hovering on the submenu link for the child (2) would display:

    1. The content for the submenu links instead of the child (2) content, also for the second child menu link.

 

Let us see how we can achieve this.

  1. As per our menu structure, on clicking on the child (2) Element a sub menu link should appear.

  2. According to our design, the content should be placed just beside the submenu link for the child (2).

  3. To do so, select the Wrapper of the submenu link and an option will appear which says Add/remove Column.

  4. Click on the “+” sign for the Add/remove Column to add a column beside it.

  5. On doing so a column will be added beside the menu item link.

d8_column

 

  1. Now we need to add content to this block. So, like we had previously added, we can add content for the same by clicking on the Blocks option.

Note: the submenus may appear a bit too small. This could be easily fixed with custom CSS. For demonstration purposes, I had given a fixed width of 600 to the submenu Container.

  1. To do that, select the submenu Element of the child (2) and toggle the Sub menu to Yes

 

d8_sub_menu

 

  1. Once the block is added it will look something like this:

 

d8_block_added

Add no content for submenu of the child (2) of Parent 2

  1. Child (2) has two submenus:

    1. Submenu 1 (has its own content).

    2. Submenu 2 (does not have its own content).

  2. The tricky part is the second submenu not having content. In that case, the content of the child (2) will be shown when we hover on submenu 2. But this should not be the case as hovering on submenu 2 should show empty.

  3. To do this we need to place an empty block which we had created earlier

 

d8_empty_block

 

  1. Doing this would mean that when we hover on the submenu then no content will be shown and it would appear empty

 

Once done, click on the Save button to save the configuration.

 

The TB mega menu that we created should look something like this:

  1. With the menu looking like this:

d8_mega_menu

 

  1. The underlying menu links looking like this:

 

d8_underlying_menu
  1. The menu links with its submenu links and contents looking like this:

d8_menu_links

 

  1. The submenu links with its content look like this:

 

d8_S_links

The blocks might appear like the ones above but with CSS this can be easily fixed and the blocks can appear in one particular place.

 

This TB mega menu that we have configured is essentially a block. Once done, save it. Then go to /admin/structure/block, select the TB mega menu that you configured and place it in the desired region according to your theme region. Voila! You have your TB mega menu ready!

 

There are some points to take note of.

  1. Remember to turn on animation. It would be none initially. If an animation is not set then all the blocks that you place for the menu items will all appear at once, one on top of another.

  2. Remember to provide permission to the bean block else, it will not appear for the anonymous user. To do so:

    1. Go to /admin/people/permissions.

    2. Search for this term your_bean_block_name block (where your bean block name is the name of your block).

    3. Look for the your_bean_block_name block: View Bean.

    4. Tick mark the checkbox for anonymous user.

    5. Clear all cache and check the site for the anonymous user. You will have the block in the TB mega menu shown for the anonymous user.

 

You now have a completely configured TB mega menu on your site! You can add images, videos, texts quite easily now through blocks.


P.S: If you have missed out the 1st part of this blog, you can check it over here.

Apr 26 2019
Apr 26

The world as we know it did not always come with the TB mega menu for Drupal 7. Traditional menu implementations included writing the entire HTML and designing it as per the needs or using default drupal menu parallelly with other contrib modules to support different requirements This would often take days or even weeks to implement. Even after completion, the client may ask you to make changes and things may go haywire. Changing every HTML element is a daunting task! Another approach may be to use certain modules offered by Drupal to create a menu. The problem with this approach is that, though the menu might look simple, it would be a daunting task to make it completely configurable within a small time frame.

 

This is where TB mega menu comes in to save the world!

 

“TB Mega Menu allows you to create a mega menu with an innovative back-end user interface and synchronized with Drupal core menu.” - drupal.org

 

The TB mega menu gives the user an option for a completely configurable approach in terms of building a menu from scratch. Today we are going to discuss this implementation over Drupal 7. It allows the user to create a mega menu with images, text, video, using a block.

 

There is one dependency though that these things can be inserted via a block.

 

The installation and implementation are pretty straight forward but there are certain hairpins that can be the cause of a car crash if not carefully configured.

The problem

Recently, one of our clients had requested a menu which will have content like images, videos, links, text, etc. for each of the respective menu links, while being completely configurable at the same time. Now, this was a task which called up for challenges. It might appeal to one, to create the menu with bootstrap. The only problem with this being, it wouldn’t be so much of a configurable option for the user. Anytime there would be any changes needed to be made, the client would have had to come to us and wouldn’t be able to directly change it themselves. To have such a configurable option is a pretty daunting task!

 

This is where the TB mega menu module stepped into our help. The content we talked about earlier i.e. images, videos, texts, etc. essentially could be placed in the menu through blocks. Great isn’t it? Well not so much. You will see later on why.

 

As one dilemma seemed to hit the exit gate, another stepped in to fill its shoes. The basic block Drupal 7 offers give the user the option to enter details for the following fields only:

  1. Block title

  2. Block description

  3. Block body

 

And that’s essentially it. If you were to insert an image, video or a link then you would be stuck. One thing you could do is to create a block programmatically with the required fields but that’s one block. What if you needed every content you place in the mega menu for each of the respective links to be different?

 

This problem has been addressed in Drupal 8 with the concept of block types. Block types are essentially like content types wherein you can add fields of different type and later on add content for that particular block type respectively. You can have multiple block types with each block type having a different set of fields. These blocks can then be placed anywhere you like. But this is for Drupal 8. Fortunately, Drupal 7 presents a module which allows users to do the same. The module named bean now comes to the rescue!

 

“What is Bean?

Think of a Bean as a method to provide new types (compared to node this would be a content type) which then provides an add the content interface to create as many blocks as you require (see screenshot below). The bean content can then be placed around the site just like any other block.-drupal.org

 

Through this bean module, we can create a block type with the required fields and then have multiple blocks of that block type.

 

We now know what are the things required to kickstart the implementation we seek. So, let us now start the implementation.

Installation

  1. First, we need to install the TB mega menu.

  2. Then we need to install the bean module.

  3. Check if bean_admin_ui is enabled. If not then enable it. This will give us the UI to create the block type.

 

Before we start with the implementation of TB mega menu we need to have our content ready for the respective menu items.

Creating a block type

When the bean and bean_admin_ui modules are enabled, there will be an option to create block types understructure. To create a block type,

  1. Go to /admin/structure/block-types/add.

  2. Specify a name and description for the block and save it.

  3. Saving the block type will take you to the block type listing page (/admin/structure/block-types). Here you will be able to see all the block types that you have created.

  4. Now, that you have created a block type, you have to add fields to it. Similarly, like in content types, here, you have to click on the manage fields link in the block type listing page.

  5. From here you can create the fields you want. After doing so save the block type.

  6. Now, you have a block type created with fields in it. You can choose to add a block for this block type as we would do for content. We will be looking at it soon.

  7. Similarly, you can create as many block types as you want.

 

Adding a block for a block type

  1. Now, that you have a block type ready, you can add the content for it i.e. creating the blocks.

  2. To add a block go to block/add. Here you will be presented with a list of block types that you had created. From here you can choose to add a block for a respective block type. You can also go to /admin/content/blocks, which is the block listing page for the blocks created for custom block types, and click on Add block.  One thing to note here is that you would not be adding a block by going into /admin/structure/block/add because this is for adding the default block that Drupal 7 provides.

  3. Fill in the required fields and save. A block will be created.

 

You now have your content ready to be placed in the TB mega menu as a block.

 

Creating a menu

TB mega menu uses the menu that you already have on your system and lets you configure that accordingly. Creating a menu is a straightforward approach and you need to create the menu as you normally would by going into /admin/structure/menu and then click on the Add menu.

 

Configuring the TB megamenu

You have two essential things ready:

  1. The blocks (the contents that need to be placed in the menu).

  2. The menu itself.

 

Let us start configuring the TB mega menu!

 

  1. Go to /admin/structure/tb-megamenu.

  2. The TB mega menu is configured upon an existing menu (refer above). Select the menu that you want to configure by clicking on the respective menu’s config option.

  3. The menu links can also be modified from this configuration page. If you need to modify the links you can do so by clicking on the Edit links option.

  4. The config page shows 6 options initially:

    1. Style

    2. Animation

    3. Delay

    4. Duration

    5. Auto arrow

    6. Always show submenu

  5. The first level of menu items is shown initially. Let us, for example, take this as:

    1. Parent 1

    2. Parent 2

    3. Parent 3

  6. On clicking on Parent 1, we would have the option to

    1. Add a submenu

    2. Add an extra class

    3. Icon

    4. Item caption

  7. The child menu links will appear in the same order and relation as created in the menu /admin/structure/menu.

  8. This Parent 1 menu item will have it’s child menu links shown in a container.

  9. On clicking on this container, we will have the option to

    1. Add a row below this container

    2. Hide when collapse

    3. Specify a width

    4. Align the items as we like

    5. Add an extra class

  10. The container further contains a wrapper which contains the child menu links. We have an option to:

    1. Add/remove columns. We can add a column in parallel to the child menu links if we want

    2. Hide when collapse

    3. Set grid size for the column

    4. Insert a block in that column that we added

    5. Show block title

    6. Add an extra class

  11. On moving further and clicking on the child menu link we are presented with the option to

    1. Add a submenu. If we add a submenu we would have the option to insert a block in that submenu

    2. Group the submenus. This means that the submenus would appear below the child menu links

    3. Break column

    4. Add an extra class

    5. Icon

    6. Item caption

  12. On moving further into the sub-menu we would be able to see that the sub-menu is wrapped in a wrapper. On selecting the wrapper, we would be able to

    1. Add a row

    2. Hide when collapse

    3. Specify the width of this sub-menu

    4. Align text

    5. Add an extra class

  13. On moving further and selecting the block in the sub-menu we would have the option to

    1. Add/remove a column

    2. Hide when collapse

    3. Set grid size

    4. Add a block

    5. Show the block title

    6. Add an extra class

  14. You can have as many child menu items as you want and blocks with them.

Placing the block

The TB mega menu that you created is essentially a block. So you would have to place it in a region like other blocks.

  1. Go to /admin/structure/blocks.

  2. Search for the TB mega menu block that you created and place it in the desired region and save it.

  3. On the specified page the TB mega menu will appear.

Note

Blocks permission

You have implemented the blocks with bean module by creating block types with and then creating blocks (the content that we need to show) for it. This block needs to be given permission. To do so:

  1. Go to /admin/people/permissions.

  2. Search for this term your_bean_block_name block (where your bean block name is the name of your block).

  3. Look for the your_bean_block_name block: View Bean permission option.

  4. Check the permission for the anonymous user.

  5. Clear all cache and check the site for the anonymous user. You will have the block in the TB mega menu shown for the anonymous user.

All blocks inside TB megamenu appearing at once

  1. One thing to keep in mind is that when creating a TB mega menu for the first time if there are sub-menus and blocks inside them then they would all appear one on top of each other.

  2. This is because the animation is set to none.

  3. You would have to select the animation as fading or any other animation style. It is only then that on hovering, the blocks would appear else not.

Apr 19 2019
Apr 19

What we learned from our fellow Drupalists

Lisa Mirabile

On April 7th, our team packed up our bags and headed off to Seattle for one of the bigger can’t miss learning events of the year, DrupalCon.

“Whether you’re C-level, a developer, a content strategist, or a marketer — there’s something for you at DrupalCon.” -https://events.drupal.org/

As you may have read in one of our more recent posts, we had a lot of sessions that we couldn’t wait to attend! We were very excited to find new ideas that we could bring back to improve our services for constituents or the agencies we work with to make digital interactions with government fast, easy, and wicked awesome. DrupalCon surpassed our already high expectations.

At the Government Summit, we were excited to speak with other state employees who are interested in sharing knowledge, including collaborating on open-source projects. We wanted to see how other states are working on problems we’ve tried to solve and to learn from their solutions to improve constituents’ digital interactions with government.

One of the best outcomes of the Government Summit was an amazing “birds of a feather” (BOF) talk later in the week. North Carolina’s Digital Services Director Billy Hylton led the charge for digital teams across state governments to choose a concrete next step toward collaboration. At the BOF, more than a dozen Massachusetts, North Carolina, Georgia, Texas, and Arizona digital team members discussed, debated, and chose a content type (“event”) to explore. Even better, we left with a meeting date to discuss specific next steps on what collaborating together could do for our constituents.

The learning experience did not stop at the GovSummit. Together, our team members attended dozens of sessions. For example, I attended a session called “Stanford and FFW — Defaulting to Open” since we are starting to explore what open-sourcing will look like for Mass.gov. The Stanford team’s main takeaway was the tremendous value they’ve found in building with and contributing to Drupal. Quirky fact: their team discovered during user testing among high-school students that “FAQ” is completely mysterious to younger people: they expect the much more straightforward “Questions” or “Help.”

Another session I really enjoyed was called “Pattern Lab: The Definitive How-to.” It was exciting to hear that Pattern Lab, a tool for creating design systems, has officially merged its two separate cores into a single one that supports all existing rendering engines. This means simplifying the technical foundation to allow more focus on extending Pattern Lab in new and useful ways (and less just keeping it up and running). We used Pattern Lab to build Mayflower, the design system created for the Commonwealth of Massachusetts and implemented first on Mass.gov. We are now looking at the best ways to offer the benefits of Mayflower — user-centeredness, accessibility, and consistent look and feel — to more Commonwealth digital properties. Some team members had a chance to talk later to Evan Lovely, the speaker and one of the maintainers of Pattern Lab, and were excited by the possibility of further collaboration to implement Mayflower in more places.

There were a variety of other informative topics. Here are some that my peers and I enjoyed, just to name a few:

Our exhibit hall booth at DrupalCon 2019Talking to fellow Drupalists at our booth

On Thursday we started bright and early to unfurl our Massachusetts Digital Service banner and prepare to greet fellow Drupalists at our booth! We couldn’t have done it without our designer, who put all of our signs together for our first time exhibiting at DrupalCon (Thanks Eva!)

It was remarkable to be able to talk with so many bright minds in one day. Our one-on-one conversations took us on several deep dives into the work other organizations are doing to improve their digital assets. Meeting so many brilliant Drupalists made us all the more excited to share some opportunities we currently have to work with them, such as the ITS74 contract to work with us as a vendor, or our job opening for a technical architect.

We left our table briefly to attend Mass.gov: A Guide to Data-Informed Content Optimization, where team members Julia Gutierrez and Nathan James shared how government agencies in Massachusetts are now making data-driven content decisions. Watch their presentation to learn:

  1. How we define wicked awesome content
  2. How we translate indicators into actionable metrics
  3. The technology stack we use to empower content authors

To cap it off, Mass.gov, with partners Last Call Media and Mediacurrent, won Best Theme for our custom admin theme at the first-ever Global Splash awards (established to “recognize the best Drupal projects on the web”)! An admin theme is the look and feel that users see when they log in. The success of Mass.gov rests in the hands of all of its 600+ authors and editors. We’ve known from the start of the project that making it easy and efficient to add or edit content in Mass.gov was key to the ultimate goal: a site that serves constituents as well as possible. To accomplish this, we decided to create a custom admin theme, launched in May 2018.

A before-and-after view of our admin theme

Our goal was not just a nicer looker and feel (though it is that!), but a more usable experience. For example, we wanted authors to see help text before filling out a field, so we brought it up above the input box. And we wanted to help them keep their place when navigating complicated page types with multiple levels of nested information, so we added vertical lines to tie together items at each level.

Last Call Media founder Kelly Albrecht crosses the stage to accept the Splash award for Best Theme on behalf of the Mass.gov Team.All the Splash award winners!

It was a truly enriching experience to attend DrupalCon and learn from the work of other great minds. Our team has already started brainstorming how we can improve our products and services for our partner agencies and constituents. Come back to our blog weekly to check out updates on how we are putting our DrupalCon lessons to use for the Commonwealth of Massachusetts!

Interested in a career in civic tech? Find job openings at Digital Service.
Follow us on Twitter | Collaborate with us on GitHub | Visit our site

Apr 12 2019
Apr 12

For us, the Paragraphs module is the holy grail of structured content creation.

With Paragraphs it is relatively uncomplicated to define prefabricated content elements that define the structure of the corresponding content. These can then simply be placed in the desired content by editors.

Paragraphs default display

This allows editors to create clearly structured content without a lot of effort and to fall back on recurring content structures. The editors simply select the desired element from the list of available content elements, fill in the corresponding fields and the content is output in the specified structure. This is extremely helpful when creating more complicated page layouts where you want to use the same structures over and over again.

Is there a better way?

We have asked ourselves and our clients' editors how to further simplify and improve the input using Paragraphs, or what might interfere with the editorial process when using Paragraphs.

It has often been mentioned here that it is quite annoying to have to drag the content elements to the desired position after adding them. This is especially cumbersome for content with many content elements. It would be much better to be able to insert the element right at the corresponding position.

Paragraphs with add_in_between

Fortunately, there is the Paragraphs Features module from the Thunder Core team. This module extends Paragraphs by inserting a button between each content element to open the modal dialog for adding more elements. 

Using these buttons, editors can insert the elements in the correct position as desired and do not have to move them first.

 

Beautiful. But is there an even better way?

Editors always add the same elements to certain content. The question arose whether these content elements could not be inserted preferentially, i.e. without first having to open the dialog.

In addition, some editors were disturbed by the large number of buttons: after each single content element a button for adding further elements appears. *sigh*

So we thought about how to make the buttons less annoying. 

Buttons you don't see don't interfere. Accordingly, with our new module Paragraphs Editor Enhancements, we have simply hidden the buttons. 

With some applications and tools (e.g. Apple Mail or Slack) the buttons for certain actions only become visible when you point the mouse over a certain area. Exactly this function has also been implemented for the buttons: only when you point the mouse over an existing content element, the buttons for adding become visible above and below the element.

new styling for Paragraphs add_in_between

In addition, the most important content elements should also be able to be inserted directly with a click. 

So we had to add two new buttons for the most important content elements to the button to open the dialog.

Editors are no longer disturbed by the large number of buttons and can simultaneously insert the most important content elements with just one click.

Great! But can you make it even much better?

Another often mentioned improvement suggestion concerned the dialog for adding content elements themselves.

Paragraphs dialog

If you have many elements to choose from, the dialog quickly becomes confusing. In addition, editors often find it difficult to find the right elements. On the basis of the title of a content element one cannot always immediately conclude on the actual purpose of the element and cannot imagine how the element is represented in the content.

With Paragraphs Editor Enhancements we have completely redesigned the dialog. We've added the ability to filter the list of content elements so editors can quickly find the desired elements through the title and description of the element.

redesigned Paragraphs dialog

In addition, the representation of the elements in the dialog has been revised. Each element shows the title and the description as well as an image (if uploaded in the element's configuration).
As an alternative to displaying the elements as tiles, you can also display the elements as a list.

As a bonus, you can create categories for content elements and assign the individual elements to one or more categories. 

This gives editors a faster and better overview of the available content elements and allows them to find the desired element more quickly and easily.

Whew. Do you have any more?

We wouldn't be undpaul if that was all.

Some time ago, one of our clients was faced with the problem of having to add the same elements in the same order over and over again. 

As a simple example, one can imagine this as follows: an introductory text followed by an image, then a two-column text and finally a text with an image.

For the editors, this meant that the corresponding content elements had to be inserted in the correct order for each individual content item. 

Wouldn't it be great if you could add the desired elements with just one click, so that the editorial staff could concentrate on entering the actual content?

redesigned Paragraphs dialog with Paragraphs Sets

The solution to this problem was the Paragraphs Sets module.

Paragraphs Sets are used to define groups of content elements. These groups can be added to the content just like the usual elements.

This saves editorial members the hassle of searching out and inserting individual elements and allows them to start entering the corresponding content directly.

Of course, Paragraphs Editor Enhancements and Paragraphs Sets also work together. The element groups of Paragraphs Sets are displayed in a separate category in the dialog and can also be found using the filter function. 

Apr 04 2019
Apr 04

Responsive images overview

As screen resolutions and pixel densities continue to climb year after year, it's becoming more important to deliver the best possible image quality to your visitors. The easy way out is to deliver a single high resolution image, but this can have a real impact on page load time & bandwidth usage, especially for visitors on mobile devices & networks. The better solution is to deliver the appropriately sized image based on the screen width/resolution of the browser. So, instead of always delivering a super high res image to mobile device users (who's browsers will be forced to downsize the image to fit anyway), deliver an image that's better sized for that screen. Smaller resolution images have a much smaller filesize, so your visitors won't have to download as much data and the image will download faster.

Thankfully, a native HTML solution for delivering different images for different browser viewports has existed for years: using the "srcset" and "sizes" attributes of the existing element.

To quickly demonstrate how it works, let's take this super simple scenario of an image on your site that will always be displayed at 100% width of the browser. This is how the image element would look:

The srcset attribute provides your browser a list of images and how wide each is in real pixels. The sizes attribute tells the browser how wide the image will be displayed after it's been laid out and CSS rules applied to it.

But wait, don't browsers already know how wide an image will be when it's rendered on a page? It's responsible for rendering the page after all! Why can't it just figure out how wide the image will be rendered and then just select the most appropriate image source from the "srcset" list? Why is this "sizes" attribute needed at all?

Well, it's true that browsers know this information, but they don't know it until they have completed parsing all JS and CSS on the page. Because processing the CSS/JS takes a while, browsers don't wait and will instead begin downloading images referenced in your HTML immediately, meaning they need to know what image to download immediately.

In the simple scenario above, the site is designed to always render the image at 100% width via CSS, so we indicate as such by adding a single value "100vw" (vw stands for viewport width) to the sizes attribute. The browser then decides which image to load depending on the width of the viewport when the page is loaded. An iPhone 8 in portrait mode has a "CSS" width of 375 pixels, but it has a 2:1 pixel density ratio (a "retina" screen), which means it can actually display images that are double that width at 750px wide. So the browser on this phone will download the lower resolution version of the image which happens to match exactly at 750px wide. On a 1080p desktop monitor the browser will be wider than 750px wide, so the larger resolution image will be downloaded.

Responsive images delivered in this manner work really well for this simple use case.

Things start to get more complicated when the image being displayed on your site does NOT take up the full width of the browser viewport. For example, imagine a site design where an image is displayed 1500px wide at the desktop breakpoint, but is displayed at 50% width at tablet/mobile breakpoints. Now the image element changes to this:

The sizes attribute has changed to indicate that if the viewport width is at least 1500px wide, then the site's CSS is going to render the image at 1500px and no larger. If the viewport width is lower, then that first rule in the sizes attribute fails, and it falls back to the next one, so the site will render the image at 50% viewport width. The browser will translate that value to an actual pixel width (and take into account pixel density of the device) to select the appropriate image to download.

The problem this creates for dynamic layout builders

Now, imagine a dynamic layout builder tool on a content management system, like the new Layout Builder module for Drupal 8:

layout builder edit page

This great layout tool allows site builders to dynamically add rows and columns to the content region of a page and insert blocks of content into the columns.

One of the "blocks" that can be inserted into a column is an image. How do you determine the value of the "sizes" attribute for the image element? Remember, the sizes attribute tells the browser how wide the image will be when it's rendered and laid out by your CSS. Let's just focus on desktop screen resolutions for now, and say that your site will display the content region at a width of 1500 CSS pixels for desktops. A site builder could decide to insert an image in any of the following ways:

  • Into a single column row (image displays at 1500px wide)
  • Into the left-most column of a 50% - 25% - 25% row (image displays at 750px wide)
  • Into the right-most column of a 33% - 33% - 33% row (image displays at 500px wide)

The value of the "sizes" attribute differs for each of those three scenarios, which means that when Drupal is generating the image element markup, it needs to know the width of the column that the image was placed in.

The Drupal-specific problem is that (to my current knowledge) there's no practical way for the code that generates the image element markup to know information about the column the image was inserted in. Without this knowledge transfer, it's impossible to convey an accurate value for the "sizes" attribute.

Things get even more complicated if you're developing a solution that has to work with multiple different themes, where each theme may have different breakpoints and rules about the width of the content region at various breakpoints. What if some pages on your site have a sidebar menu, and others don't? That affects the the width of the content region and can easily throw off your sizes attribute calculations as well.

Moving forward

I think this is a new and interesting challenge, and I don't know that anyone has put much thought into how to solve it yet. I'm certainly hoping others read this and provide some ideas, because I'm not sure what the best solution is. The easy solution is of course to just not output the image responsively, and just use a single image src like the old days. In the example above, the image would need to be 1500px wide to account for the largest possibility.

Apr 04 2019
Apr 04
Julia Gutierrez

DrupalCon2019 is heading to Seattle this year and there’s no shortage of exciting sessions and great networking events on this year’s schedule. We can’t wait to hear from some of the experts out in the Drupalverse next week, and we wanted to share with you a few of the sessions we’re most excited about.

Adam is looking forward to:

Government Summit on Monday, April 8th

“I’m looking forward to hearing what other digital offices are doing to improve constituents’ interactions with government so that we can bring some of their insights to the work our agencies are doing. I’m also excited to present on some of the civic tech projects we have been doing at MassGovDigital so that we can get feedback and new ideas from our peers.”

Bryan is looking forward to:

1. Introduction to Decoupled Drupal with Gatsby and React

Time: Wednesday, April 10th from 1:45 pm to 2:15 pm

Room: 6B | Level 6

“We’re using Gatsby and React today on to power Search.mass.gov and the state’s budget website, and Drupal for Mass.gov. Can’t wait to learn about Decoupled Drupal with Gatsby. I wonder if this could be the right recipe to help us make the leap!”

2. Why Will JSON API go into Core?

Time: Wednesday, April 10th from 2:30 pm to 3:00 pm

Room: 612 | Level 6

“Making data available in machine-readable formats via web services is critical to open data and to publish-once / single-source-of-truth editorial workflows. I’m grateful to Wim Leers and Mateu Aguilo Bosch for their important thought leadership and contributions in this space, and eager to learn how Mass.gov can best maximize our use of JSON API moving forward.”

I (Julia) am looking forward to:

1. Personalizing the Teach for America applicant journey

Time: Wednesday, April 10th from 1:00 pm to 1:30 pm

Room: 607 | Level 6

“I am really interested in learning from Teach for America on how they implemented personalization and integrated across applications to bring applicants a consistent look, feel, and experience when applying for a Teach for America position. We have created Mayflower, Massachusetts government’s design system, and we want to learn what a single sign-on for different government services might look like and how we might use personalization to improve the experience constituents have when interacting with Massachusetts government digitally. ”

2. Devsigners and Unicorns

Time: Wednesday, April 10th from 4:00 pm to 4:30 pm

Room: 612 | Level 6

“I’m hoping to hear if Chris Strahl has any ‘best-practices’ and ways for project managers to leverage the unique multi-skill abilities that Devsigners and unicorns possess while continuing to encourage a balanced workload for their team. This balancing act could lead towards better development and design products for Massachusetts constituents and I’d love to make that happen with his advice!”

Melissa is looking forward to:

1. DevOps: Why, How, and What

Time: Wednesday, April 10th from 1:45 pm to 2:15 pm

Room: 602–604 | Level 6

“Rob Bayliss and Kelly Albrecht will use a survey they released as well as some other important approaches to elaborate on why DevOps is so crucial to technological strategy. I took the survey back in November of 2018, and I want to see what those results from the survey. This presentation will help me identify if any changes should be made in our process to better serve constituents from these results.”

2. Advanced Automated Visual Testing

Time: Thursday, April 11th from 2:30 pm to 3:00 pm

Room: 608 | Level 6

“In this session Shweta Sharma will speak to what visual testings tools are currently out there and a comparison of the tools. I am excited to gain more insight into the automated visual testing in faster and quicker releases so we can identify any gotchas and improve our releases for Mass.gov users.

P.S. Watch a presentation I gave at this year’s NerdSummit in Boston, and stay tuned for a blog post on some automation tools we used at MassGovDigital coming out soon!”

We hope to see old friends and make new ones at DrupalCon2019, so be sure to say hi to Bryan, Adam, Melissa, Lisa, Moshe, or me when you see us. We will be at booth 321 (across from the VIP lounge) on Thursday giving interviews and chatting about technology in Massachusetts, we hope you’ll stop by!

Interested in a career in civic tech? Find job openings at Digital Services.
Follow us on Twitter | Collaborate with us on GitHub | Visit our site

Mar 27 2019
Mar 27

Less than two weeks remain until the start of DrupalCon Seattle and the Event Organizers have a packed schedule. We’ve been meeting virtually throughout the year, and we’re all looking forward to the opportunity to meet in person and dig into the conversations further. Here’s a list of where we’ll be—from “official” organizer events, to sessions and BoFs that are of interest for organizers. Whether you’re an event organizer, interested in starting an event in your area, or just want to flag one of us down, here’s where to look.

Tuesday, April 9

Wednesday, April 10

Thursday, April 11

Thanks to Kaleem Clarkson (of DrupalCamp Atlanta) for all of his hard work on organizing the organizers and John Rearick (of DrupalCorn) for digging through the schedule to find many of these sessions.

We'll see you at DrupalCon!

Mar 13 2019
Mar 13

Note: This post refers to Drupal 8, but is very applicable to Drupal 7 sites as well

Most Drupal developers are experienced building sitewide search with Search API and Views. But it’s easy to learn and harder to master. These are the most common mistakes I see made when doing this task:

Not reviewing Analytics

Before you start, make sure you have access to analytics if relevant. You want to get an idea of how much sitewide search is being used and what the top searches are. On many sites, sitewide search usage is extremely low and you may need to explain this statistic to stakeholders asking for any time-consuming search features (and yourself before you start going down rabbit holes of refinements).

Take a look for yourself at how the sitewide search is currently performing for the top keywords users are giving it. Do the relevant pages come up first? You’ll take this into account when configuring boosts.

Using Solr for small sites

Drupal 8 Search API comes with database search included. Search API DB has come a long way over the years and is likely to have the features you need for smaller sites. Using a Solr backend is going to add complexity that may not be worth it for the amount of value your sitewide search is giving. Remember, if you use a Solr backend you have to have Solr running on all environments used in the project and you’ll have to reindex when you sync databases.

Not configuring all environments for working Solr

Which takes us to this one. If you do use Solr (or another server-side index) you need to also make sure your team has Solr running on their local environments and has an index for the site. 

Your settings.php needs to be configured to connect to the right index on each environment. We use Probo for review sandboxes so we need to configure our Probo builds to use the right search index and to index it on build.

Missing fields in index or wrong type

Always included the ‘Rendered HTML’ field in your search index rather than trying to capture every text field on all your content types and then having to come back to add more every time you add a field. Include the title field as well, but don’t forget to use ‘Fulltext’ as its field type. Only ‘Fulltext’ text fields are searchable by word.

Not configuring boosts

In your Processor settings, use Type-specific boosting and Tag-boosting via HTML filter. Tag boosting is straightforward: boost headers. For type-specific boosting you’re not necessarily just boosting the most important content types, but also thinking about what’s in the index and what people are likely looking for. Go back to your analytics for this. 

For example, when someone searches for a person’s name, are they likely wanting the top result to be the bio and contact info, a news posting mentioning that person, or a white paper authored by the person? So, even if staff bios are not the most important content on the site, perhaps they will need to be boosted high in search, where they are very relevant.

Not ordering by relevance

Whoops. This is a very common and devastating mistake. All your boost work be damned if you forget this. The View you make for search results needs to order results by Relevance: Descending.

Using AJAX

Don’t use the setting to ‘Use AJAX’ on your search results View. Doing so would mean that search results don’t have unique URLs, which is bad for user experience and analytics. It’s all about the URLs not about the whizzbang.

Not customizing the query string

Any time you configure a View with an exposed filter, take the extra second to customize the query string it is going to use. ‘search’ is a better query string than ‘search_api_fulltext’ for the search filter. URLs are part of your user interface.

No empty text

Similarly, when you add an exposed filter to a search you should also almost always be adding empty text. “No results match your search” is usually appropriate.

Facets that don’t speak to the audience

Facets can be useful for large search indexes and certain types of sites. But too many or too complex facets just create confusion. ‘Content-type’ is a very common facet, but if you use it, make sure you only include in its options the names of content types that are likely to make sense to visitors. For example, I don’t expect my visitors to understand the technical distinction between a ‘page’ and a ‘landing page’ so I don’t include facet links for these.

A screen shot of facets in DrupalYou can exclude confusing facet options 

Making search results page a node

I tell my team to make just about every page a visitor sees a node. This simplifies things for both editors and developers. It also ensures every page is in the search index: If you make key landing pages like ‘Events Calendar’ as Views pages or as custom routes these key pages will not be found in your search results. 

One important exception is the Search Results page itself. You don’t want your search results page in the search index: this can actually make an infinite loop when you search. Let this one be a Views page, not a Views block you embed into a node.

Important page content not in the ‘content’

Speaking of blocks and nodes, the way you architect your site will determine how well your search works. If you build your pages by placing blocks via core Block Layout, these blocks are not part of the page ‘content’ that gets indexed in the ‘Rendered HTML.’ Anything you want to be searchable needs to be part of the content. 

You can embed blocks in node templates with Twig Tweak, or you can reference blocks as part of the content (I use Paragraphs and Block Field.)

Not focusing on accessibility

The most accessible way to handle facets is to use ‘List of Links’ widget. You can also add some visually hidden help text just above your facet links. A common mistake is to hide the ‘Search’ label on the form. Instead of display: none, use the ‘visually-hidden’ class.

Feb 25 2019
Feb 25

This PSA is now out of date. Read: Extending Drupal 7's End-of-Life - PSA-2020-06-24

Drupal 7 was first released in January 2011. In November 2021, after over a decade, Drupal 7 will reach end of life (EOL). (More information on why this date was chosen.) Official community support for version 7 will end, along with support provided by the Drupal Association on Drupal.org. This means that automated testing services for Drupal 7 will be shut down, and there will be no more updates provided by the Drupal Security Team.

When this occurs, Drupal 7 will be marked end-of-life in the update manager, which appears in the Drupal administrative interface. Updates, security fixes, and enhancements will no longer be provided by the community, but may be available on a limited basis from select commercial vendors.

If you have a site that is running on Drupal 7, now is the time to start planning the upgrade. Note that the transition from Drupal 8 to Drupal 9 will not be the significant effort that the transition from 7 to 8 was. In fact, the first release of Drupal 9 will be identical to the last release of Drupal 8, except with deprecated code removed and dependencies updated to newer versions. (See Plan for Drupal 9 for more information on Drupal 9.)

What this means for your Drupal 7 sites is, as of November 2021:

  • Drupal 7 will no longer be supported by the community at large. The community at large will no longer create new projects, fix bugs in existing projects, write documentation, etc. around Drupal 7.
  • There will be no more core commits to Drupal 7.
  • The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 core or contributed modules, themes, or other projects. Reports about Drupal 7 vulnerabilities might become public creating 0 day exploits.
  • All Drupal 7 releases on all project pages will be flagged as not supported. Maintainers can change that flag if they desire to.
  • On Drupal 7 sites with the update status module, Drupal Core will show up as unsupported.
  • After November 2021, using Drupal 7 may be flagged as insecure in 3rd party scans as it no longer gets support.
  • Best practice is to not use unsupported software, it would not be advisable to continue to build new Drupal 7 sites.
  • Now is the time to start planning your migration to Drupal 8.

If, for any reason, you are unable to migrate to Drupal 8 or 9 by the time version 7 reaches end of life, there will be a select number of organizations that will provide Drupal 7 Vendor Extended Support (D7ES) for their paying clients. This program is the successor to the successful Drupal 6 LTS program. Like that program, it will be an additional paid service, fully operated by these organizations with some help from the Security Team.

The Drupal Association and Drupal Security Team will publish an announcement once we have selected the Drupal 7 Vendor Extended Support partners.

If you would like more information about the Drupal release cycle, consult the official documentation on Drupal.org. If you would like more information about the upcoming release of Drupal 9, join us at DrupalCon Seattle.

Information for organizations interested in providing commercial Drupal 7 Vendor Extended Support

Organizations interested in providing commercial Drupal 7 Vendor Extended Support to their customers and who have the technical knowledge to maintain Drupal 7 are invited to fill out the
application for the Drupal 7 Vendor Extended Support team. The application submission should explain why the vendor is a good fit for the program, and explain how they meet the requirements as outlined below.

Base requirements for this program include:

  • You must have experience in the public issue queue supporting Drupal 7 core or Drupal 7 Modules. You should be able to point to a history of such contribution. One way to measure this is issue credits, but there are other ways. You must continue this throughout your enrollment in the program. If you have other ways to show your experience, feel free to highlight them.
  • You must make a commitment to the Security Team, the Drupal Association, and your customers that you will remain active in this program for 3 years.
  • As a partner, you must contribute to at least 20% of all Drupal 7 Vendor Extended Support module patches and 80% of D7ES core patches in a given year. (Modules that have been moved into core in Drupal 8 count as part of core metrics in Drupal 7) .
  • Any organization involved in this program must have at least 1 member on the Drupal Security Team for at least 3 months prior to joining the program and while a member of the program. (See How to join the Drupal Security Team for information.) This person will need a positive evaluation of their contributions from the Security Working Group.
  • Payment of an Drupal 7 Vendor Extended Support annual fee for program participation is required (around $3000 a year). These fees will go to communication tools for the Drupal 7 Vendor Extended Support vendors and/or the greater community.
  • Payment of a $450 application fee is required.
  • Your company must provide paid support to Drupal 7 clients. This program is not for companies that don't provide services to external clients.
  • Application review process:

  1. We will confirm that each vendor meets the requirements outlined above and is a good fit for the program.
  2. If the Security Working Group does not think you are a good fit, we will explain why and decline your application. If you are rejected, you are able to reapply. Most rejections will be due to Organizations not having enough ongoing contribution to Drupal 7 and Organizations not having a Drupal Security Team member at their organization.
  3. The Drupal Association signs off on your participation in the program.
  4. If you are accepted, you will be added to the Drupal 7 Vendor Extended Support vendor mailing list.
  5. The Security Working Group will do a coordinated announcement with the vendors to promote the program.

If you have any questions you can email [email protected]

Feb 23 2019
Feb 23

This Public Service Announcement is a follow-up to SA-CORE-2019-003. This is not an announcement of a new vulnerability. If you have not updated your site as described in SA-CORE-2019-003 you should do that now.

There are public exploits now available for this SA.

Update, February 25: Mass exploits are now being reported in the wild.

In the original SA we indicated this could be mitigated by blocking POST, PATCH and PUT requests to web services resources, there is now a new way to exploit this using GET requests.

The best mitigation is:

This only applies to your site if:

  • The site has the Drupal 8 core RESTful Web Services (rest) module enabled.
  • OR

  • The site has another web services module enabled, like JSON:API in Drupal 8, or Services or RESTful Web Services in Drupal 7, or custom code that allows entity updates via non-form sources.

What to do if your site may be compromised

Take a look at our existing documentation, ”Your Drupal site got hacked, now what”.
We’ll continue to update the SA if novel types of exploit appear.

Feb 06 2019
Feb 06

Mass.gov dev team releases open source project

Moshe Weitzman

The Mass.gov development team is proud to release a new open source project, Drupal Test Traits (DTT). DTT enables you to run PHPUnit tests against your Drupal web site, without wiping your database after each test class. That is, you test with your usual content-filled database, not an empty one. We hope lots of Drupal sites will use DTT and contribute back their improvements. Thanks to PreviousNext and Phase2 for being early adopters.

Mass.gov is a large, content-centric site. Most of our tests click around and assert that content is laid out properly, the corresponding icons are showing, etc. In order to best verify this, we need the Mass.gov database; testing on an empty site won’t suffice. The traditional tool for testing a site using an existing database is Behat. So we used Behat for over a year and found it getting more and more awkward. Behat is great for facilitating conversations between business managers and developers. Those are useful conversations, but many organizations are like ours — we don’t write product specs in Gherkin. In fact, we don’t do anything in Gherkin beside Behat.

Meanwhile, the test framework inside Drupal core improved a lot in the last couple of years (mea culpa). Before Drupal Test Traits, this framework was impossible to use without wiping the site’s database after each test. DTT lets you keep your database and still test using the features of Drupal’s BrowserTestBase and friends. See DrupalTrait::setUp() for details (the bootstrap is inspired by Drush, a different open source project that I maintain).

Zakim Bridge at Night, North End Boston. Photo by David Fox.
  • Our test cases extend ExistingSiteBase, a convenience class from DTT that imports all the test traits. We will eventually create our own base class and import the traits there.
  • Notice calls to $this->createNode(). This convenience method wraps Drupal’s method of the same name. DTT deletes each created node during tearDown().
  • Note how we call Vocabulary::load(). This is an important point — the full Drupal and Mink APIs are available during a test. The abstraction of Behat is happily removed. Writing test classes more resembles writing module code.
  • See the DTT repo for details on how to install and run tests
  • Typically, one does not run tests against a live web site. Tests can fail and leave sites in a “dirty” state so it’s helpful to occasionally refresh to a pristine database.

If you have questions or comments about DTT, please comment below or submit issues/PRs in our repository.

More from Moshe: Our modern development environment at Mass.gov

Interested in a career in civic tech? Find job openings at Digital Services.
Follow us on Twitter | Collaborate with us on GitHub | Visit our site

Jan 30 2019
Jan 30

Why not just use the .gitignore file?

Kaleem ClarksonPhoto by Tim Wright on Unsplash

As many of you know, I am a huge Pantheon hosting fanboy and can still remember the days during the beta launch of being blown away that I have three different environments out of the box, with dev, test and live. Another great service they added recently is that all sites receive SSL certificates automatically and all you have to do is redirect all traffic to use HTTPS. In Drupal 8 they suggest doing this in your settings.php file.

After adding the redirect code everything works great until you fire up your local environment (I am currently using Lando) and you are getting a blank screen. After further investigation, you notice it’s the redirect to HTTPS that is causing the issue. My first thought was to make sure my settings.local.php file was correctly being used but for the life of me, I could not get that file to override the redirect code in my settings.php file. If you are reading this and have a better idea on to how to accomplish this then let me know in the comments :)

My next thought was to simply add the settings.php file to my .gitignore file but when I went to my production website I was prompted to reinstall my Drupal site. When adding a file to .gitignore the repo pretends it doesn’t exist so therefore Drupal was telling me to reinstall. Whoooops, my production site kind of needs this file hahahah. So I thought to myself,

How can I ignore my settings.php file in my local repo but still have the original file on production?

Now that we understand what git update-index does, the real magic happens with the options that you can add to the command. In this case, the option that Ian Gloude suggested is the --skip-worktreeoption. The Git documentation explains that the skip worktree bit tells the git index to assume the file is unchanged from this point on regardless if there is an actual change. So what does this mean for us? It means you can change your file on your local environment while the original file on your production server remains unchanged.

Here is the command I use prior to uncommenting out the pantheon redirect code.

git update-index --skip-worktree /sites/default/settings.php

When I need to make some changes to the production settings.php file I can tell Git to watch the file again with this command.

git update-index —-no-skip-worktree web/sites/default/settings.php

Anyway, I hope this helps you keep your local and production environments running smoothly while maintaining your settings differently.

Jan 22 2019
Jan 22

This article was previously posted on Medium (Nov 2018). 27 Attendees representing 18 Drupal events from around the world. It’s been almost one month since I wrote the blog post, “DrupalCamp Organizers Unite: Is it Time for Camp Organizers to Become an Official Working Group” and a ton of things have transpired that will catapult us into 2019 with some great momentum. With the support of the many Drupal evangelists, over 50 Drupal event organizers from around the world signed up to attend our first official / unofficial video call.

Then on Friday, November 8, a few hours leading up to the video call, The Drupal Governance Taskforce 2018 Proposal was released. This proposal was put together by the Governance Taskforce in an effort establish a community directive that helps create the next generation of Drupalers. One of the recommendations in this proposal was to provide in-person events, more support, and to establish a Drupal community events working group. The timing of the proposal was perfect for our call. It was really great to see that us organizers were not the only ones who acknowledged that our community events are crucial to Drupal adoption.

Are you a Drupal Event Organizer? Well, join us at our next meeting on Tuesday, January 8, 2019, at 12 pm (EST). Register Here

When the time came to start the call I was a little nervous that not very many people would attend and then all of a sudden the chimes started going off and faces appeared on the screen. After 5 minutes we had 25 people on the call. It was inspirational to be a part of something big. It felt like we were the United Nations :).

Countries Represented
Canada, Mumbai, Netherlands, Switzerland, United Kingdom, United States.

Drupal Events Represented
BADCamp(2), Drupal Association(2), Drupal North, Drupal Camp Asheville, DrupalCamp Atlanta, Drupal Camp Chattanooga, DrupalCamp Colorado, DrupalCorn(2), Drupaldelphia, Drupal Mountain Camp, Drupal Camp Mumbai, DrupalCamp New Jersey, Florida Drupal Camp (2),Frontend United, GovCon, MidCamp(2), NED Camp(4),Victoria BC Meetup.

Major Points from the November 9th Meeting

  1. The next meeting will be held on Tuesday, January 8, 2019, at 12 pm (EST). Register Here
  2. Comment on Governance Taskforce Proposal Issue 
    To help Dries Buytaert, prioritize the recommendation of creating a Community Events Working Group, we need as many people as possible to comment on this issue. Please view the issue and indicate why you believe this working group is critical to the success of Drupal. Comment now!
  3. DrupalCamp Website Starter Kit 
    Out of all of the discussions, the common pain point is that the website takes up too much of our limited resources. The idea of an event starter kit, instead of a distribution, was really intriguing to us all. We also discussed all of the events donating funding to hire a professional project manager to scope out what a starter kit would look like.
  4. Drupal.org Events Website 
    Many of us use the great Drupical to let us know what events are happening. But if you don’t know about that website there is nowhere on Drupal.org that is easily accessible that promotes Drupal events. The idea that was brought to the table was to design a new section of the community page that is a space specifically for promoting and producing Drupal events.
  5. A Centralized Drupal Event Statistics Hub
    Another website related item that was brought up was the idea of centralized data hub that event organizers could submit crucial data of events (attendance, budget, programing etc.) so that Drupal.org could display the data and allow for data manipulation. For example, it would be great to know how many people attended Drupal events in one year. This data would be extremely powerful as it could help organizers to compare events, drive corporate sponsorships and adoption, and get more people involved with Drupal.
  6. DrupalTV — A website with all Drupal Videos
    The topic around Drupal video content came up and one of the biggest issues was that videos are all over the place and are not organized. To solve this problem, the idea of a centralized website (DrupalTV) where videos were tagged by topic, presenter, module, etc.. would allow for content to be easily found. This idea was started before our meeting and you can see a proof of concept here.

I was very happy to be a part of this first meeting and I hope that Drupal leadership also sees the work we do as critical and will make us an official working group. There were a lot of great conversations that took place so I am sure that I have missed something. Feel free to comment and let me know and I will update the post.

Are you a Drupal Event Organizer? Well, join us at our next meeting on Tuesday, January 8, 2019, at 12 pm (EST). Register Here

You can also join the Drupal Event Organizers Slack community. You can also register for any of our meetings to be added to our emailing list.

Jan 22 2019
Jan 22

This article was previously posted on Medium (Nov 2018).  You Can’t Put a Price Tag on Visibility, Creditability, and Collegiality. Organizing a DrupalCamp takes a lot of commitment from volunteers, so when someone gets motivated to help organize these events, the financial risks can be quite alarming and sometimes overwhelming. But forget all that mess, you are a Drupal enthusiast and have drummed up the courage to volunteer with the organization of your local DrupalCamp. During your first meeting, you find out that there are no free college or community spaces in the area and the estimated price tag is $25,000. Holy Batman that is a lot of money!

Naturally, you start thinking about how we are going to cover that price tag, so you immediately ask, “how many people usually attend?” Well unless you are one of the big 5, (BADCampNYCCampDrupal GovConMidCamp or FloridaCamp) we average between 100 and 200 people. Then you ask, “how much can we charge?” You are then told that we cannot charge more than $50 because camps are supposed to be affordable for the local community and that has been the culture of most DrupalCamps.

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00pm (EST)? RSVP Here.

If Drupal is the Enterprise solution why are all of our camps priced and sponsored like we are still hobbyist in 2002?

Why Don’t We Treat DrupalCamps Like It’s the Enterprise Solution?

Drupal is the Enterprise solution. Drupal has forgotten about the hobbyist and is only concerned about large-scale projects. Drupal developers and companies make more per hour than Wordpress developers. These are all things I have heard from people within the community. So if any of these statements are valid, why are all the camps priced like it is 2002 and we are all sitting around in a circle singing Kumbaya? In 2016 for DrupalCamp Atlanta, we couldn’t make the numbers work, so we decided to raise the price of the camp from $45 to $65 (early bird) and $85 (regular rate). This was a long drawn out and heated debate that took nearly all of our 2 hours allotted for our google hangout. At the end of the day, one of our board members who is also a Diamond sponsor said,

“when you compare how other technology conferences are priced and what they are offering for sessions, DrupalCamps are severely under-priced for the value they provide to the community.

If a camp roughly costs $25,000 and you can only charge 150 people $50, how in the world are DrupalCamps produced? The simple answer, sponsors, sponsors, and more sponsors. Most camps solely rely on the sponsors to cover the costs. One camp, in particular, BADCamp has roughly 2,000 attendees and the registration is FREE. That’s right, the camp is completely free and did I forget to mention that it’s in San Francisco? Based on the BADCamp model and due to the fact the diamond sponsorship for DrupalCon Nashville was $50,000, getting 10 companies to sponsor your camp at $2,500 will be no sweat. Oh and don’t forget Drupal is the enterprise solution, right?

With all of your newfound confidence in obtaining sponsorships, you start contacting some of the larger Drupal shops in your area and after a week nothing. You reach out again maybe by phone this time and actually speak to someone but they are not committing because they want some more information as to why they should sponsor the camp such as, what other perks can you throw in for the sponsorship, are we guaranteed presentation slots, and do you provide the participant list. Of course, the worst response is the dreaded no, we cannot sponsor your conference because we have already met our sponsorship budget for the year.

At this point, you feel defeated and confused as to why organizations are not chomping at the bit to fork over $2,500 to be the sponsor. Yep, that’s right, twenty-five hundred, not $25,000 to be the highest level, sponsor. Mind you many Drupal shops charge anywhere between $150 — $250 an hour. So that means donating 10–17 hours of your organizations time to support a Drupal event in your local community. Yes, you understand that there are a lot of DrupalCamps contacting the same companies for sponsorship so you ask yourself, what has changed from years past?

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00 pm (EST)? RSVP Here.

What Do Companies Expect to Gain From DrupalCamp Sponsorships?

At DrupalCon Nashville, I got an awesome opportunity to participate in a session around organizing DrupalCamps. It was really interesting to hear about how other organizers produce their camp and what were some of the biggest pain points.

During this session, we were talking about a centralized sponsorship program for all DrupalCamps (that I personally disagree with and will save that discussion for another blog post) and an individual asked the question,

“why should my company sponsor DrupalCamp Atlanta? There is nothing there for me that makes it worth it. We don’t pick up clients, you don’t distribute the participant list, so why should we sponsor the camp?”

Needless to say, they caught me completely off guard, so I paused then replied,

“DrupalCamp Atlanta has between 150–200 people, most of them from other Drupal shops, so what is it that you are expecting to get out of the sponsorship that would make it worth it to you? Why do you sponsor any DrupalCamps?”

Have Drupal Companies Outgrown the Need to Sponsor DrupalCamps?

On the plane ride back to the ATL it got me thinking, why does an organization sponsor DrupalCamps? What is the return on their investment? I started reminiscing of the very first DrupalCamp that I attended in 2008 and all the rage at that time (and still is), was inbound marketing and how using a content strategy and or conference presentations can establish your company as thought leaders in the field, therefore, clients will find your information useful and approach you when its time to hire for services. Maybe this is why so many camps received a ton of presentation submissions and why it was easy to find sponsors, but that was over 10 years ago now and some of those same companies have now been established as leaders in the field. Could it be, that established companies no longer need the visibility of DrupalCamps?

What happens to DrupalCamps when companies no longer need the visibility or credibility from the Drupal community?

The Drupal community thrives when Drupal shops become bigger and take on those huge projects because it results in contributions back to the code, therefore, making our project more competitive. But an unintended consequence of these Drupal shops becoming larger is that there is a lot more pressure on them to raise funding thus they need to spend more resources on obtaining clients outside of the Drupal community. Acquia, the company built by the founder of Drupal, Dries Buytaert, have made it clear that they are pulling back on their local camp sponsorships and have even created their own conference called Acquia Engage that showcases their enterprise clients. Now from a business perspective, I totally understand why they would create this event as it provides a much higher return on their investment but it results in competing with other camps (ahem, this year’s DrupalCamp Atlanta), but more importantly the sponsorship dollars all of us depend on are now being redirected to other initiatives.

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00 pm (EST)? RSVP Here.

Why Should Established Companies Sponsor a DrupalCamp?

The reality of the situation is that sponsoring these DrupalCamps are most likely not going to land your next big client that pays your company a $500,000 contract. So what are true reasons to sponsor a DrupalCamp:

  • Visibility
    When sponsoring these DrupalCamps most of us organizers do a pretty good job of tweeting thanks to the company and if the organization has presenters we usually promote the sessions as well. In addition, most camps print logos on the website, merchandise, and name after parties. Yes, its only a little bit but the internet is forever and the more you are mentioned the better off you are. But you are from a well established Drupal shop so you don’t need any more visibility.
  • Credibility 
    Even the companies who are have been established need their staff to be credible. There will always be some amount of turnover and when that happens your clients still want to know if this person is talented. And if your company is new, being associated with Drupal in your local community does provide your company a sense of credibility.
  • Collegiality 
    I saved the best for last. Collegiality is highly overlooked when looking at sponsoring camps. Most companies have a referral program for new hires and when the time comes for you to hire, people tend to refer their friends and their professional acquaintances. There is no better place to meet and interact with other Drupalist than a DrupalCamp. What about employee engagement? In a recent focus group I participated in with a Drupal shop, many of the staff wanted more opportunities for professional development. These local camps are affordable and can allow staff to attend multiple events in a year when you have small budgets.

I must end by saying, that there are so many great Drupal companies that I have had the pleasure to work with and if it were not for the Acquia’s of the world Drupal wouldn’t exist. I understand that CEO’s are responsible for their employees and their families so I don’t want to underestimate the pressures that come with making payroll and having a client pipeline. The purpose of this post was to explain how it feels as a volunteer who is doing something for the community and the frustrations that sometimes come with it.

If you are interested in sponsoring a DrupalCamp check out Drupical and sponsor a camp today! All of us organizers need your help!!

Are you interested in attending the first online DrupalCamp Organizers Meeting, on Friday, November 9th at 4:00 pm (EST)? RSVP Here.

If you are also interested in contributing to the Atlanta Drupal Users Group (ADUG) Medium Blog publication, please feel free to reach out to us at [email protected]

Jan 20 2019
Jan 20

This article was previously posted on Medium (Oct 2018). Community, community and more community. One of the common themes we hear when it comes to evaluating Drupal against other content management systems (CMS), is that the community is made up of over 100,000 highly skilled and passionate developers who contribute code. And in many of these application evaluations, it’s the community, not the software that leads to Drupal winning the bid. We have also heard Dries Buytaert speak about the importance of the community at various DrupalCons and he is quoted on Drupal.org’s getting involved page:

“It’s really the Drupal community and not so much the software that makes the Drupal project what it is. So fostering the Drupal community is actually more important than just managing the code base.” — Dries Buytaert

My First Encounter with the Drupal Community

With this emphasis on community, I tried to think back to how and when I first interacted with the community. Like so many others, my first introduction to Drupal was at a local Meetup. I remember going to this office building in Atlanta and the room was packed with people, plenty of pizza, soda and, of course, laptops. It was a nice relaxed atmosphere where we introduced ourselves and got a chance to know each other a little bit. Then the lights dimmed, the projector turned on and the presentations kicked off, highlighting some new content strategy or a new module that can help layout your content. After that first meetup, I felt energized because until that point, I had never spoken with someone in person about Drupal and it was the first time that I was introduced to Drupal professionals and companies.

DrupalCamps Play An Integral Role in Fostering Community

After attending a few meetups, I joined the email list and I received an email announcing DrupalCamp Atlanta was going to be held at Georgia Tech and the call for proposals was now open for session submissions.

I purchased a ticket for a mere $30 and added it to my Google calendar. On the day of the event, I remember walking in the front door and being blown away by the professionalism of the conference as there were sponsor booths, giveaways, and four concurrent sessions throughout the day. But it wasn’t until I was inside the auditorium during the opening session and saw the 200 or so people pile in that made me realize this Drupal community thing I heard about was for real. Over the next couple of years, I decided that I would attend other camps instead of DrupalCon because the camps were more affordable and less intimidating. My first camp outside of Atlanta was Design4Drupal in Boston, DrupalCamp Charlotte, DrupalCamp Florida and BADCamp were all camps I went to before attending a DrupalCon. All of these camps were top notch but what I really loved is that each camp had their own identity and culture. It’s exactly what I think a community should be and for the very first time, I felt that I was a part of the Drupal community.

Why Establish the DrupalCamp Organizers Council?

As provided in my previous examples, one of the advantages of Drupal comes from the great community and DrupalCamps are an important aspect in fostering this community. Running any event can be challenging, but to pull off a respectable DrupalCamp you have consider so many things such as the website, credit card processing, food, accepting and rejecting sessions, finding a keynote speaker, the afterparty, pre-conference trainings, oh and did I mention the website? You get my drift, it's a lot of work. Many of these tasks just roll off my tongue from past experience so ask yourself;

  • Where can I share my knowledge with other people who organize camps?
  • What if there was some way that all of us DrupalCamp organizers could come together and implement services that make organizing camps easier?
  • How could we provide camp organizers with resources to produce great camps?

During the #AskDries session at DrupalCon Nashville (listen for yourself), Midwest DrupalCamp Organizer Avi Schwab asked Dries the following question;

“... giving the limited funding the Drupal Association has, where should we go in trying to support our smaller local community events?” — Avi Schwab

Dries then responded with:

“That’s a great question. I actually think its a great idea what they (WordCamp) do. Because these camps are a lot of work. ...I think having some sort of central service or lack of a better term, that helps local camp organizers, I think is a fantastic idea, because we could do a lot of things, like have a camp website out of the box, ... we could have all sorts of best practices out of the box .” — Dries Buytaert

DrupalCamp Slack Community was the first time that I was provided a link to a spreadsheet that had the camp history dating back to 2006 and people were adding their target camp dates even if they were just in the planning stages. As a camp organizer I felt connected, I felt empowered to make better decisions and most of all I could just ask everyone, hey, how are you doing this?

Are you interested in attending the first online DrupalCamp Organizers meeting, on Friday, November 9th at 4:00pm (EST)? RSVP Here.

Earlier this year I volunteered for the Drupal Diversity and Inclusion Initiative (DDI) and was inspired when I heard Tara King on the DrupalEasy podcast, talk about how she just created the ddi-contrib channel on the Drupal slack and started hosting meetings. All jazzed up and motivated by that podcast, I reached out to over 20 different camp organizers from various countries and asked them if they would be interested in being on something like this? And if not, would they feel represented if this council existed?

Here are some quotes from Camp Organizers:

“I think a DrupalCamp Organizers Council is a great idea. I would be interested in being a part of such a working group. Just now I’m restraining myself from pouring ideas forth, so I definitely think I’m interested in being a part.”

“I am interested in seeing something that gathers resources from the vast experiences of current/past organizers and provides support to camps.”

“I definitely would appreciate having such a council and taking part. I’ve now helped organize DrupalCamp four times, and this was the first year we were looped into the slack channels for the organizers.”

“I really like the idea — what do we need to do to get this started?”

What are the Next Steps?

Based on the positive feedback and the spike in interest from other camp organizers I have decided to take the plunge and establish our first meeting of DrupalCamp Organizers on Friday, November 9th at 4:00pm (EST). This will be an online Zoom video call to encourage people to use their cameras so we can actually get to know one another.

The agenda is simple:

  • Introductions from all callers, and one thing they would like to see from the council.
  • Brainstorm the list of items the council should be advocating for.
  • Identify procedures for electing people to the Council: ways to nominate, eligibility criteria, Drupal event organizer experience required etc.
  • Outline of a quick strategic plan.
Jan 17 2019
Jan 17

When we say DrupalCon, the upcoming DrupalCon Seattle 2019 event is probably what first comes to mind. But while we have been selecting sessions, setting up BoFs, and letting you know about the additions to our Con, we at the Drupal Association have also been looking ahead to DrupalCons of the future. We are excited to share those with you now.

In the past, we used to announce the next DrupalCon location during the closing session of the previous Con. This was a lot of fun, but created some logistical problems for the events team, and made it difficult to do all the work we need to do to secure our next con locations. It is a multi-year process to secure a venue for DrupalCon, so we've made some changes that help us coordinate with venues, hotels, and partners without relying on a veil of secrecy.

You first saw this change during the DrupalCon Nashville Closing Session, where we announced both 2019 (Seattle) and 2020 (Minneapolis).

We're taking these changes a step further by looking far into the future to announce the North American DrupalCons for 2021, 2022, 2023 and 2024. We're thrilled to announce the selected cities, as well as share the process that went into making these selections.

Where DrupalCon is going

Together with each of our partner cities, we're excited to announce the upcoming locations for DrupalCon North America:

  • DrupalCon Boston North America 2021 Online (April 12-16)
  • DrupalCon Portland 2022 (Oregon, April 25-29)
  • DrupalCon Pittsburgh 2023 (June 5-9)
  • DrupalCon Portland 2024 (Oregon, May 6-10)

Want to understand the process that goes into city selection? The search for each location starts four or more years before the event, and you can read on for the inside scoop into how this plan came together. Wondering why all the selected cities are in the USA? We encourage you to read our prior blog about why the sustainable choice for North American locations is in the United States for the foreseeable future.

How we got here 

Planning for the future

Historically, DrupalCon locations have been contracted a couple of years before they happened, in a city where we were excited to host the community, that we revealed in a fun fashion at our Closing Session the prior year.

However, announcing the new event only a year in advance—and selecting new cities for every event—created some logistical problems; conference center venues large enough to host DrupalCon are often booked four or more years in advance. This has meant that cities we would love to visit have often simply been booked during the dates that would work with our community needs, or are too expensive because we couldn't make multi-year commitments - which took a lot of options off the table.

In benchmarking ourselves with comparable conferences (in size, audience, and program), it became clear that many established organizations were booking multiple years in advance. This is in part due to the availability of desirable cities, but also that securing locations in the future equates to more competitive pricing.

As the Drupal Association matures and starts leading change in the community and in the open source world, we determined it was best to look farther into the future for our largest annual conference.

Creating a location pattern that the community can count on

We took a serious look at data from past attendance, the locations we're trying to reach, and where we see the most traction from the community.

In analyzing data from DrupalCons dating back to DrupalCon Austin 2014, we were able to deduce some high-level insights about our attendees:

  • 88% of attendees at DrupalCon North America come from the United States
  • In hosting a DrupalCon in a coastal city in the USA, attendance from the regional community local to those cities can be 13-17% higher than the regional attendance we see in other cities (not counting those who travel greater distances).
  • Conversely, when hosting a Con in the center of the country, attendance decreases significantly from the coastal audiences and does not significantly increase from the hosted-area region.

With the majority of our conference attendees in mind, we set out to host our conference in coastal cities, where, by ‘showing up’ our community has proven they want to go. This led us to primarily work on sourcing East Coast and West Coast cities for the upcoming years.

With our upcoming DrupalCon Seattle 2019 on the West Coast, and DrupalCon Minneapolis 2020 in the middle of the USA, we aimed to host DrupalCon 2021 on the East Coast, and from there, jump between the coasts for the foreseeable future.

The benefits of repeating cities

As we did with timing and location, we also stepped back to ask ourselves, why do we move this conference every year? The logical answer is that it makes the conference more accessible to new audiences in different areas. But our past attendee data doesn't support this conclusion. So we asked ourselves again: If it isn't bringing in large numbers of new first-time attendees, why do we search for a new city every year?

We had heard anecdotally that it was because ‘Drupalers like to go on vacation in new cities’ and that ‘it helps grow the community in a new city,’ but these answers aren't well supported by the data, so we decided to re-evaluate our strategy.

When we release our RFP to the world, we work internally with the Drupal Association Board to determine our Selection Criteria. A lot of this hasn’t changed because the Con hasn’t changed drastically in a few years. The top 5 things that we evaluated in each city’s bid were:

  • Large/versatile venue - Could the venue fit our 150+ sessions, 3,000 people for lunch, and the breadth of programming offered at our Cons?
  • Popular tourist area - Do people want to go there? Is there a wealth of activities for them post-sessions each day?
  • Strong business community - Do we already have partners in the city? Is it a place our sponsors have expressed as a city where they’d like to do business?
  • Tech-focused city - Is the city supportive of tech and open source? Are there businesses and organizations that may participate in our event because we are in their city?
  • Large and strong Drupal community - Does this city have a community that has hosted a successful camp in the past? Is there a solid community that regularly meets and would help support the planning of a Con?

It had been a few years since we selected new DrupalCon cities, so reviewing and updating the criteria seemed prudent. We added and changed the following criteria:

  • CHANGE: In the venue criteria, we included the ability to change the program around, since as the community grows and changes, we want to be able to flex our program.
  • ADD: Welcoming to all attendees. We wanted to make sure that topics such as legislative actions, political climates, and inclusiveness of the cities were taken into account to ensure that we were placing our Con in a city where all members of our community would feel welcome.
  • CHANGE: When DrupalCons were mostly managed by the community, the need for a large and strong community was imperative to the success of a Con. Since the Drupal Association has taken on the bulk of planning, pricing, and executing of the Con, the need for the community to be of a certain size is no longer a qualifying factor. In fact, by changing the focus, we could look at cities that didn’t have large community groups at the time, but maybe a Con could inspire one.

When we examined our search criteria and started matching it up with real cities that we could reach out to, the list became short. With that reality, it became apparent that we would need to begin repeating cities. We seized the opportunity to proactively address that reality.

In speaking with tech event leaders from other communities and organizations, it was helpful to get a fuller understanding regarding the benefits of repeating a city location:

  • Time: Securing multiple years can save an organization time, money and peace of mind. By doing this, you eliminate the need to do site visits and RFP gathering again the following year.
  • Staff Capacity: By hosting an event somewhere you’ve already been, the staff does not need to learn a new floor plan, crew, process, regulations, etc. It is estimated that in eliminating these normal challenges of a new venue, that the staff capacity can be reduced by 25%, freeing them up to focus on the event itself.
  • Negotiation: Planners can gather information on the facility once and focus on strategic negotiating, which translates to consistent concessions and commissions with minimal increases in rates/pricing annually.
  • Cost Savings: Event budgets can be determined early, giving the planner more time to focus on the important things like planning for the success of the event. And, if you have done all of this well in the beginning, you will have the peace of mind to know that you are prepared for surprises that inevitably come along.
  • Relationships: Multiyear contracts require a partnership. Planners, venues, and hotel partners can create a strategic plan to build the event and their services. In working with a crew for more than one year, improvements can be made and the crew is better prepared to serve the attendees the next time around.

Getting from ideas to contracts

We released our RFP on August 13, 2018, on the Drupal Association blog. It was also sent to multiple cities that met our criteria. Within our RFP, we shared our tight timeline, with the goal of signing contracts for 2021, 2022, 2023, and 2024 by the end of 2018. Below is a glimpse into the work that transpired between launch date and sign date.

  • September 4, 2018. Is the date that we requested cities submit their detailed bids. Per our RFP, we had multiple questions about space needs, catering, AV, diversity and inclusion, internet, hotels, and more.
  • September 5-11. Partnering with our fantastic production partner, Groundswell Marketing, we reviewed the proposals to see if any questions arose initially about the information provided. Most proposals were 30+ pages of information with pricing grids, proposed hotel blocks, and ‘why our city’ info. We ask each city for some hard numbers on regular items like a gallon of coffee or the hourly rate of an AV technician. This helps us immediately get a picture of a Con cost.
  • September 11 - September 17. For cities we hadn’t been to before, the next step was to interview the city via a Zoom call to better understand how they were a good fit for our conference. Questions like ‘how would attendees be made to feel welcome in your city?’ and ‘How easy and affordable is it to get from the airport to the Convention Center?’ are asked in our initial determination.
  • September 18 - 21. Once we determined cities that met our criteria, we dug a bit deeper into each city’s numbers. We laid out the entire Con on their floor plans to determine if we could fit and how. We inquired about real quotes for line items like our AV and our internet. We costed out catering estimates and space rental.
  • September 24 - October 26. With our list in hand, we did our due diligence visiting possible future Con locations. In these meetings we reviewed the space and discussed how the attendee experience would feel. We met representatives from various departments of the Convention Center’s team to negotiate pricing and discuss pain points. We also did a whirlwind tour of the city to get a feel of what attendees would see/do after the Con each day.
  • October 29 - November 14. We reviewed all of this information with the Drupal Association leadership team and collaboratively determined the priority of cities based on our search criteria. Going further, we then included data points on pricing, incentives, conference dates, etc, to come to a final recommendation for each year.
  • November 15 - December 3. Built a working budget with concrete numbers for each preferred city to get an accurate future picture of finances. This involved getting future pricing on catering, network, hotel rates, etc. Worked back and forth with the city to negotiate down pricing.
  • December 5. Presented recommendation to the Drupal Association Board for buy-in and support.
  • December 6 - 27. Requested contracts from our preferred venues and hotels. Each city has one Convention Center, and at least 5 hotels, so in asking for these hotels, we had about 20 contracts to review. By looping in our legal team and our insurance group, we were able to further negotiate terms that make committing to future years smart, sustainable, and safe.
  • December 28. Signed the last contract and sent it off to the cities. Signing before the end of the year met a contracting deadline that gave us a lot of financial benefits.
  • End of December. CELEBRATED the end of this intense and action-packed process, and the future of sustainable and secured DrupalCon programming.

Serving our community

We aim toward growing adoption, one of the Drupal Association’s main goals. In planning ahead and setting ourselves up for a sustainable and fiscally responsible future conference plan, we can allocate our resources better to focus on creating a successful event that drives to this goal. By making these decisions now, we work to strengthen the foundation of the Association in order to continually work to serve our incredible and growing open source community.

We appreciate the questions and interest that community members have had in this process and were happy to do a deep dive to show you the planning, strategy, and work involved in selecting a city for a future DrupalCon. We invite you to share your thoughts and comments below, and we look forward to seeing you at a Con in the future.

Jan 03 2019
Jan 03

Context

EK application has a module that store personal documents for user. When user account is deleted, those documents may be transferred to another account.

To achieve that, we need to alter the user account cancel form when building the form, validating and submitting it.

Let's review the 3 steps.

BUILD

The form before altering it looks like this

cancel user account before hook

We need to add a field to select another user account to which the document of the canceled account will be moved to.

To achieve that we Implements hook_form_alter() in MyModule.module:


function MyModule_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {    
  if ($form_id == 'user_multiple_cancel_confirm') {
        $form['move_uid_documents'] = [
      '#type' => 'textfield',
      '#title' => t('Move uer documents'),
      '#autocomplete_route_name' => 'MyModule.user_autocomplete',
      '#description' => t('Select to whom to transfer personal documents'),
    ];
    $form['#validate'][] = 'MyModule_form_user_delete_validate';
    $form['#submit'][] = 'MyModule_form_user_delete_submit';
    
    return $form;
      
  }
}

What we can notice here is:

  • We alter selected form defined by form ID. In this case : "user_multiple_cancel_confirm";
  • We create the required field by returning $form['move_uid_documents'] ;
  • We add 2 new actions for validation, $form['#validate'][], and submit, $form['#submit'][],  for the next steps.

After altering the form will look like this:

cancel user account after hook

We have a new field to select user. In our case, we also have an autocomplete function that helps selecting existing user. However, we need to ensure that the value entered in the field is really an existing user. This is the part handled by the validation.

 

VALIDATE

The validation is defined in MyModule_form_alter by adding validate callback named MyModule_form_user_delete_validate. Therefore, we need to create the function with thah particular name in MyModule.module.


function MyModule_form_user_delete_validate(&$form, \Drupal\Core\Form\FormStateInterface $form_state) {   
  if ($form['#form_id'] == 'user_multiple_cancel_confirm') {
        if ($form_state->getValue('move_uid_documents') <> '') {
            
            $query = "SELECT uid FROM {users_field_data} WHERE name = :n";
            $data = db_query($query, [':n' => $form_state->getValue('move_uid_documents')])
                    ->fetchField();
            if ($data) {
                $form_state->setValue('move_uid_documents', $data);
            } else {
                $form_state->setErrorByName('move_uid_documents', t('Unknown user to move documents'));
            }
            
 
        }
    
     return $form;
      
  }

Here the function will check against user_field_data table that the id is valid.

If not an error message will be displayed:

cancel user account validation error

However, if valid, we store the value to be used in the next step which is the submission.

SUBMISSION

As for validation, the submission is defined in MyModule_form_alter by adding validate callback named MyModule_form_user_delete_submit.


function MyModule_form_user_delete_submit(&$form, \Drupal\Core\Form\FormStateInterface $form_state) {
    
  if ($form['#form_id'] == 'user_multiple_cancel_confirm') {
    if($form_state->getValue('move_uid_documents')){
        foreach($form_state->getValue('accounts') as $key => $id) {               
        \Drupal::database()->update('MyModule_table')
           ->fields(['uid' => $form_state->getValue('move_uid_documents'), 'folder' => t('Moved from user @u', ['@u' => $id])])
           ->condition('uid', $id)->execute();
       }
    }
     \Drupal::messenger()->addStatus(t('Documents moved to user @u', ['@u' => $form_state->getValue('move_uid_documents')]));
     return $form;
      
  }
}

In the function above, we pick the id of each user account that is canceled and change to new user id in the document table.

The function also display a message to confirm actions: both cancellation and the submit hook have been executed.

cancel user submit alert

Please feel free to comment or suggest improvements.

Thank you.

Dec 28 2018
Dec 28

Themes improperly check renderable arrays when determining visibility

Kaleem ClarksonPhoto by Hello I'm Nik on Unsplash

One of the many great advantages of being a part of an open source project is that there are so many smart people out there are willing to contribute their time for the betterment of the project. This ability to crowdsource bugs and feature requests that rarely stumps the community is what makes Drupal such a powerful application.

While rare, sometimes the community finds a bug that is very difficult to solve. Let me introduce you to [#953034] Themes improperly check renderable arrays when determining visibility.

I was first introduced to this bug while trying to add a view block in the left sidebar. When the view was empty I expected the block and the sidebar to not be displayed. As you can see below, while the block was empty the sidebar was still being rendered.

The sidebar is Still being displayed.

I then googled and stumbled upon another issued, Empty view causes region to be displayed and it was exactly what I was looking for, but I noticed it was marked as a duplicate issue and linked to [#953034] Themes improperly check renderable arrays when determining visibility. This bug was reported to Drupal 7 core on October 26, 2010. The issue has over 310 comments and 230 followers.

You can really tell the severity and complexity of an issue when you see some of the brightest Drupal contributors have been making suggestions and striking out. They include but are not limited to:
bleen, chx, Cottser, Crell, DamienMcKenna, EclipseGc, Fabianx, Jeff Burnz, jenlampton, joachim, joelpittet, JohnAlbin, lauriii, markcarver, mdrummond, moshe weitzman, mpotter, samuel.mortenson, tim.plunkett, webchick, Wim Leers, xjm.

While I am not a backend developer, I felt like I could still help by highlighting a major issue that maybe someone either inside or outside the community could help find a solution.

Please remember to read the complete issue before commenting as so many people have suggested solutions to fix but have ran into a roadblock.

Dec 20 2018
Dec 20

To Zach Sines and Taylor Wright, It’s not goodbye, it’s see you later.

Kaleem Clarkson2018 DrupalCamp Atlanta Group Picture

Thanks to all of the presenters and participants who attended 2018 DrupalCamp Atlanta (DCATL). We are excited to provide you with a little holiday gift. The Session Videos are now live. View here

I would also like to thank the awesome DCATL team that I had the pleasure to work with:

  • Sarah Golden — Acquia
  • Nikki Smith — Sevaa
  • Zach Sines — Manhattan Associates
  • Taylor Wright

As with any event, this year’s DCATL had some interesting twists and turns that we were able to overcome. The biggest and most noticeable one, of course, was the construction that was happening at the hotel. Two weeks before the event, I met with the hotel event staff to discuss our setup. On my way into the hotel, everything looked as I expected and it was business as usual. When I entered the lobby I noticed they were putting up a temporary wall that blocks off the hotel bar. During our discussion, I was informed there was going to be some construction going on during our camp but was ensured that the event space wouldn’t be impacted.

The DCATL team arrived at the hotel to load in and everyone was mortified when we saw the front of the building. No more than 10 minutes after we arrived, I received a message from one of the trainers asking, “are we still having the conference?” We immediately started thinking about how we can alleviate the situation, so we took a picture of the building and sent an email out to everyone stating that the interior of the building was okay and that we were still going to have an awesome conference.

It wasn’t all doom and gloom. 10 days before the camp, we were still short on the financials and were kind of sweating it out (although we had reserve funds to cover the costs) thinking of ways that we could reduce costs without getting rid of too much programming. I received a phone call from an employee at Turner, asking if they could be a Diamond Sponsor and would also like to sponsor the after party. WOW! I couldn’t believe we were getting bailed out in the last minute, phew!

After the camp, I got a chance to have lunch with a mentor of mine and we talked about where are the next generation of Drupalers going to come from and what purpose camps serve today vs ten years ago. So based on our discussion here are my top two goals I would like to propose to the DCATL organizing team.

Increase the Number of Case Studies with co-presentations from Drupal shops and their Clients.

Another topic we discussed was how Acquia Engage has taken a different approach by showcasing their clients and providing opportunities for Drupal shops to schedule meet and greets talk with their clients. During the opening session at DCATL I asked the audience, “raise your hand if you have invited a client to attend or co-present at DrupalCamp Atlanta.” Out of all the attendees maybe 2 raised their hands.

Increase the Number of Student Attendees

When looking at some of my Drupal colleague's user profiles so many of us over 10 years. This means we are getting old folks :) But more importantly, where are the next generation of Drupalers going to come from. The state of Georgia has 114 colleges and 326,609 students. I know it takes a lot of energy but we have to figure out a way to use our camp as a pipeline for nurturing the next generation of Drupalist.

For the past 5.5 years, I have had the pleasure to work with Zach Sines and Taylor Wright as board members of the Atlanta Drupal Users Group (ADUG). Both Zach and Taylor were key stakeholders in the restructuring of the organization. Zach took on the writing of the bylaws that states how people are elected, what are the rules for participating, what are the roles and responsibilities of each officer and so on. Taylor has a ton of finance experience so he took on the responsibility of cleaning up our financials and paying all of our bills. These two have been by my side, even after heated discussions and have been what I like to call my nice translators. Sometimes I have the tendency to be too blunt and they were always there to translate my bluntness into that beautiful southern hospitality.

Zach in the Green on the Left. Taylor in the Green on the Right

Earlier this year, both Zach and Taylor informed all of us that 2018 will be their last year serving on the board. Not to get too mushy but I am going to miss them both a lot, I mean a ton. Not just for their expertise but hearing their voices on our monthly calls and some of their hilarious stories. But what is great about Drupal is that you build some lasting relationships and now I consider these two my friends. Thank you for all the work you have put into running these events, and I know this is not goodbye its soo you soon.

With our current vacancies, the Atlanta Drupal User Group (ADUG) is currently looking for new board members to join our team. While the serving on a board can sound intimidating we are really just a bunch of Drupalers who want to give back to the community. All of our meetings are held on a video call. If you are interested or know some who would be a great fit, please feel free to contact us.

Dec 08 2018
Dec 08

Sometimes we need to build a rather complex search form with many options. We want to have total control under output, so we will override the default template by own because standard Drupal templates do not allow to the use the complex formatting. However, we can easily override the template with our custom theme or module.
All we need to know the ID of the form and the appropriate name of the template. For this, you can check using the following code: dump($form['#id']); and dump($form['#theme']); inside hook_form_alter() or hook_form_FORM_ID_alter().

In my example, we have: views-exposed-form-class-schedule-block-1 and views_exposed_form__class_schedule__block_1 , you should replace both with your values.

Nov 27 2018
Nov 27

Our team loves exploring and using hot trends in development, one of which is decoupled Drupal architecture. Our previous post was devoted to using decoupled Drupal with JSON.API, and our today’s story hero will be “the Great Gatsby”. Does it sound like the famous book hero? No, Gatsby.JS is a new and hot JavaScript tool, but it promises to be equally famous and deserve a hundred books! In this post, we will discuss its principle of work and the benefits of using decoupled Drupal 8 and Gatsby.JS. And, of course, you always can rely on our Drupal experts in implementing it all.

Gatsby.JS: what it is and how it works

Gatsby.JS is defined a static site generator, but it is approaching a front-end framework in its capacities. Gatsby is built on very hot front-end tools, some of which are:

  • React.JS — the amazingly popular JavaScript library for building complex interfaces
  • GraphQL — the super efficient query language
  • Webpack — the great JavaScript module bundler 

Gatsby.JS is meant for building blazing fast static sites. It fetches the data to them from absolutely any sources and generates static content using GraphQL. Right now, there are 500+ source plugins to establish the connection between particular data sources and Gatsby. The sources include YouTube, Twitter, Hubspot, Shopify, Trello, Vimeo, Google Sheets, content management systems like Drupal, WordPress, and so on. 

Gatsby uses source plugins and GraphQL

 

Decoupled Drupal 8 and Gatsby.JS: the great duet and its benefits

One of the hottest and most beneficial combinations for today is Gatsby and Drupal 8. According to the the decoupled, or headless Drupal architecture, Drupal serves as the backend only, while Gatsby.JS handles the presentation layer. 

Drupal 8 and Gatsby.JS are both open-source, have a large and active community and a huge ecosystem of add-on modules or plugins. And Drupal 8 has built-in web services to make integration a breeze. 

What makes this combination so beneficial? The simplicity and speed of a static site combines perfectly with the power and flexibility of the backend provided by the Drupal 8 CMS. Here are at least some of the features that we get in the end:

  • Unmatched speed. Gatsby.JS pre-fetches all pages of the website instead of querying the database every time on demand, which makes navigation enjoyable and amazingly fast. Gatsby is a static PWA (progressive web app) generator. It efficiently fetches only the critical HTML, CSS, and JS files. 
  • Easy setup. No cumbersome deploy and setup processes will be needed with Gatsby. It builds your site as static files that can be quickly deployed anywhere.
  • Great personalization features. Drupal-and-Gatsby combinations can feature awesome user personalization and authentication capabilities.
  • Awesome content editing. Usually, static site generators need writing content in Markdown, which could be cumbersome for content editors. But the problem is solved with Drupal 8 as a backend! Drupal 8 content creation features are a joy for any content editor. 

One of examples of using decoupled Drupal 8 and Gatsby.JS is the demo site Umami Food Magazine. The site is built on headless Drupal distribution Contenta CMS with Gatsby.JS. 

Umami Food Magazine uses Gatsby 2Umami Food Magazine uses Gatsby

If this looks appetizing enough, contact our Drupal team right now to combine decoupled Drupal 8 with Gatsby.JS for you! Or continue reading about some implementation details. 

Some specifics of using Drupal 8 and Gatsby.JS

In the decoupled setup, both Drupal 8 and Gatsby sites need to be prepared to work together. They will be connected by means of the special Gatsby’s source plugin for Drupal that fetches data, including images, from Drupal 8 websites with JSON API installed. 

So it is necessary to install and enable the JSON API and JSON API extras contributed Drupal modules, as well as enable the core Serialization module on our Drupal website.

Enable JSON API module

Our next destination is Configuration — Web Services — JSON API Overwrites.

Configure JSON API

In Settings, we need to make sure the path prefix for JSON API is /jsonapi. This is what the Gatsby site will need to know.

Configure JSON API

In People — Roles — Permissions we give access to the JSON API list of resources to users with all roles, including anonymous.

Permissions for JSON API

Our Drupal site is ready for Gatsby integration, and we now need to prepare our Gatsby site. It begins with installing Gatsby’s CLI:

npm install --global gatsby-cli

Then we follow all the site creation steps in the “Get started” documentation. Gatsby also offers pre-configured starters for site creation.

Gatsby starters

Then we run Gatsby with the command, after which the Gatsby site should become available at localhost:8000:

gatsby develop

The above mentioned source plugin for Drupal then needs to be installed on the Gatsby site. Next, we add the piece of code from the plugin’s documentation to the gatsby-config.js file. The URL should changed to the one of our Drupal site.

plugins: [
 {
 resolve: `gatsby-source-drupal`,
 options: {
 baseUrl: `https://our-site-name.com/`,
 apiBase: `api`, // optional, defaults to `jsonapi`
 },
 },
]

We then configure our Gatsby site to fetch exactly the content we need from Drupal. We need to create the appropriate pages in /src/pages on the Gatsby site and add the code for React import to the JS file. 

And we configure GraphQL at localhost:8000/___graphql to query the Drupal site exactly how we want. 

It all crowns up with the last command to publish our Gatsby site with the Drupal data:

gatsby build

This is just a very brief description of getting Drupal 8 work with Gatsby. Our experts are ready to do the setup exactly in accordance with your wishes.

Enjoy the combination of decoupled Drupal 8 and Gatsby.JS!

If you are interested in using decoupled Drupal 8 and Gatsby.JS, either on an existing project or on a new one, contact our Drupal developers. Our Drupal 8 team has great experience in third-party integration. We will advise you the best decoupled setup and, of course, smoothly implement it. Let’s enjoy the latest and greatest technologies!

Nov 23 2018
Nov 23

It’s been almost one month since I wrote the blog post, “DrupalCamp Organizers Unite: Is it Time for Camp Organizers to Become an Official Working Group” and a ton of things have transpired that will catapult us into 2019 with some great momentum. With the support of the many Drupal evangelists, over 50 Drupal event organizers from around the world signed up to attend our first official / unofficial video call.

Then on Friday, November 8, a few hours leading up to the video call, The Drupal Governance Taskforce 2018 Proposal was released. This proposal was put together by the Governance Taskforce in an effort establish a community directive that helps create the next generation of Drupalers. One of the recommendations in this proposal was to provide in-person events, more support, and to establish a Drupal community events working group. The timing of the proposal was perfect for our call. It was really great to see that us organizers were not the only ones who acknowledged that our community events are crucial to Drupal adoption.

Are you a Drupal Event Organizer? Well, join us at our next meeting on Tuesday, January 8, 2019, at 12 pm (EST). Register Here

When the time came to start the call I was a little nervous that not very many people would attend and then all of a sudden the chimes started going off and faces appeared on the screen. After 5 minutes we had 25 people on the call. It was inspirational to be a part of something big. It felt like we were the United Nations :).

Flags of all the Countries that were represented

Countries Represented
Canada, Mumbai, Netherlands, Switzerland, United Kingdom, United States.

Drupal Events Represented
BADCamp(2), Drupal Association(2), Drupal North, Drupal Camp Asheville, DrupalCamp Atlanta, Drupal Camp Chattanooga, DrupalCamp Colorado, DrupalCorn(2), Drupaldelphia, Drupal Mountain Camp, Drupal Camp Mumbai, DrupalCamp New Jersey, Florida Drupal Camp (2),Frontend United, GovCon, MidCamp(2), NED Camp(4),Victoria BC Meetup.

  1. The next meeting will be held on Tuesday, January 8, 2019, at 12 pm (EST). Register Here
  2. Comment on Governance Taskforce Proposal Issue
    To help Dries Buytaert, prioritize the recommendation of creating a Community Events Working Group, we need as many people as possible to comment on this issue. Please view the issue and indicate why you believe this working group is critical to the success of Drupal. Comment now!
  3. DrupalCamp Website Starter Kit
    Out of all of the discussions, the common pain point is that the website takes up too much of our limited resources. The idea of an event starter kit, instead of a distribution, was really intriguing to us all. We also discussed all of the events donating funding to hire a professional project manager to scope out what a starter kit would look like.
  4. Drupal.org Events Website
    Many of us use the great Drupical to let us know what events are happening. But if you don’t know about that website there is nowhere on Drupal.org that is easily accessible that promotes Drupal events. The idea that was brought to the table was to design a new section of the community page that is a space specifically for promoting and producing Drupal events.
  5. A Centralized Drupal Event Statistics Hub
    Another website related item that was brought up was the idea of centralized data hub that event organizers could submit crucial data of events (attendance, budget, programing etc.) so that Drupal.org could display the data and allow for data manipulation. For example, it would be great to know how many people attended Drupal events in one year. This data would be extremely powerful as it could help organizers to compare events, drive corporate sponsorships and adoption, and get more people involved with Drupal.
  6. DrupalTV — A website with all Drupal Videos
    The topic around Drupal video content came up and one of the biggest issues was that videos are all over the place and are not organized. To solve this problem, the idea of a centralized website (DrupalTV) where videos were tagged by topic, presenter, module, etc.. would allow for content to be easily found. This idea was started before our meeting and you can see a proof of concept here.

I was very happy to be a part of this first meeting and I hope that Drupal leadership also sees the work we do as critical and will make us an official working group. There were a lot of great conversations that took place so I am sure that I have missed something. Feel free to comment and let me know and I will update the post.

Nov 14 2018
Nov 14
Make your dev life easy by using "apachectl" command to restart, stop, or start the apache server on mac from the terminal.
Nov 09 2018
Nov 09

Last week, the Children’s Hospital of Philadelphia (CHOP) Vaccine Makers Project (VMP) won a PR News Digital Award in the category “Redesign/Relaunch of Site.” The awards gala honors the year’s best and brightest campaigns across a variety of media. 

PR News Award on a table.

Our CEO, Alex, and our Director of Client Engagement, Aaron, along with members of the Vaccine Makers team attended the event at the Yale Club in New York City.

Screenshot of a Tweet posted by the PR News. Source

The Vaccine Makers Project (VMP) is a subset of CHOP’s Vaccine Education Center (VEC). It’s a public education portal for students and teachers that features resources such as lesson plans, downloadable worksheets, and videos. 

The Vaccine Makers team first approached us in need of a site that aligned with the branding of CHOP’s existing site. They also wanted a better strategy for site organization and resource classification. Our team collaborated with theirs to build a new site that’s easy to navigate for all users. You can learn more about the project here.

Screenshot of a Tweet from Vaccine Makers team. Source

We’d like to thank CHOP and the Vaccine Makers team for giving us the opportunity to work on this project. We’d also like to thank PR News for recognizing our work and hosting such a wonderful event. 

Finally, we’d like to congratulate our incredible team for their endless effort and dedication to this project. 
 

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