Drupal Planet

Let's jump right in! For business owners, ecommerce eliminates many restrictions of traditional business practices. One opportunity is the ability to sell your product to overseas consumers, expanding your possible market to contain, well virtually, the whole world. Of course, one of the barriers to entry into certain markets may be the language.

Imagine this: You are a Brazilian business owner who just invented chewing gum that never loses its flavour. Obviously, the demand for this product is worldwide. The only problem is that you do not feel comfortable writing the script for your new online product page in English or any language other than Portuguese for that matter. In a perfect world, the ideal solution might be to hire translators for every language of each country that you want to sell this amazing gum in. However, the costs of such an endeavour are enough to make even those with even the deepest of pockets think twice.

In my opinion, the next best and completely viable option is to choose to develop your chewing gum site using Drupal then make use of the many multilingual modules to automatically translate your content (just Google “Drupal automatic translate” for a list of options). The advantage of these Drupal translation modules is that, first, it can appear as an option at the top of the page and is therefore easily accessible to the customer. Second, additional modules can allow you to automatically show the users local language based on their browser’s set language. Third, you can choose which blocks of text you want to translate and which you do not; so let us say for aesthetic reasons or brand awareness you do not want a certain block of the site to be translated, you simply do not enable the translation for that block in the admin portal. Additionally, while your site frontend is being translated for your visitors, as an admin you can maintain Portuguese as the primary language to run your backend admin portal.

Speaking from my own experience, I shop online for bicycle components quite often. The problem is many of the unique manufacturers I am looking to buy from are based out of Italy and Germany. Google translate can do an adequate job of helping you navigate the site, but when it comes to the finer details like product specifications or return policies I quickly find myself out of my depth. The great thing about using Drupal Translate is that you can manually enter the translation for each language of every block on your website. So for example, instead of paying for a full site translation in each language, you could hire professionals to translate the important areas like the fine print and leave the less critical areas up to Drupal.

Okay, Drupal is not exactly an episode of Pimp My Ride, but it can pretty much do anything you can dream of. If, for some reason, you want to design a site that sources all of the types of chicken wings sold in restaurants across your city. Then create a catalogue that breaks down the various chicken wings by texture, flavour, price, size, messiness, etc. Now you want to integrate a system that uses logic and intelligence to recommend the best beer your company sells to accompany any wing selection made. This is all possible with Drupal.

The cost to develop such a unique site with these custom modules on Drupal would not be cheap. However, the point remains that a feature such as the one mentioned above is quite crazy, but completely possible. If there is functionality that you need, it can be built on Drupal. The other big takeaway is that once you have paid for the development of the module you are now the owner and do not have to worry about any ongoing licensing costs. For reasons like these, it is my opinion that Drupal is the best CMS for such robust and custom site requirements.

Of course, nothing can ever be fully secure especially without regular upkeep, but Drupal does a few things differently that should help you sleep better at night. Unlike the many popular SaaS platforms, Drupal is open source and non-proprietary. This means that you are the owner of your data and you are the one who decides how it is managed, meaning you can fine tune every aspect of your Drupal site from the site itself to your hosting environment. If you have a security team or security-focused partner that you work with, Drupal provides the flexibility they need to keep your data safe.

The official Drupal Security Team is also thoroughly on top of the security of the core Drupal software’s code and helps module developers keep their modules secure. This team frequently releases security patches that address any vulnerabilities that come up. In addition to the official Drupal team, the large Drupal community of developers donate their time to develop and monitor Drupal’s code. Drupal and all of it’s modules are built using a core set of coding standards, so the many thousands of developers working with Drupal’s code ensures security issues are found and addressed quickly.

Lastly, one of the features of Drupal that is best known is its ability to integrate into third-party applications. As such, Drupal is also capable of easily integrating into other security systems and platforms on the market. You’re not restricted to Drupal alone.

In my mind, there are two main reasons that the open-source nature of Drupal and the community that surrounds it are such an advantage.

First, because of the large community of developers and its open-sourced nature, there are countless plug-and-play ready modules available free of licensing fees just waiting to be added to your website. This means, in addition, you are the owner of your own code and data. Furthermore, you never have to worry about losing development support for your website. There will always be another Drupal agency out there waiting to pick up the pieces if something were to go wrong.

Second, because there is such a large community of developers behind the expansion of Drupal, you have a veritable fusion of diverse ideas and designs. Instead of a single organization pushing code in a certain direction, you can find incredibly creative and unique libraries of code. This means a deeper pool of free talent to pull from. Even with the creative minds driving the development of Drupal, there is still consistency in the underlying code. This enables easier upkeep of the code itself and allows a lower barrier of entry when onboarding new developers. The advantage to the end-user is that, when compared to a fully custom build, using Drupal means that should your partner agency ever go out of business or the relationship deteriorates, you will have other experts in Drupal to turn to.

I keep bringing this up, but it really enables so many possibilities; because Drupal is so open to API integrations, you can design Drupal to work as a modular middleware behind the scenes. This means as you acquire new technology and software, it really is as simple as plugging it in and configuring an API hook.

Furthermore, as long as Drupal is paired with the right server, it can handle endless amounts of traffic and scale from small business to enterprise. This is a reason why Drupal is such a popular CMS of choice for medium-sized to enterprise-level organizations.

Finally, Drupal as a CMS is kind of like Play-Doh. You can build out your frontend experience for the market you are presently targeting using Drupal’s built-in theming layer or by using one of the many other frontend frameworks. Drupal’s APIs allow it to run headless, so it can hold your backend data but you’re not tied down to any specific way of building your frontend. Ten years down the road, though, you may have a completely different set of needs for your frontend framework. No problem, you can rest assured that Drupal won't get in your way.

Choosing the right DXP now is important to your business now and in the future. Protect your tech investment by assessing the trade-offs of buy or build deployment options and how they relate to your digital experience goals and business outcomes. This Gartner report has been made available to our readers for a limited time and will help you get started. Check it out.

"A picture is worth more than a thousand words". True, but a large picture will make your webpage slower, which will affect your SEO in a negative way. And eat away at your servers space, megabyte after megabyte.

There are several ways to remedy such a behaviour, but one way is to use image compression services to save space. With online services or programs on your computer you can remove unnecessary information and compress images with sometimes up to 80% gain.

Here I'm going to show you how to integrate the TinyPNG service in your Drupal installation which automatically compresses your images.

There are many different services on the internet, but one of the best I have found is TinyPNG - and it's supereasy to implement on your Drupal site.

It's also super easy to see if you can benefit from using their service. If you visit their Page Analyzer and enter your site url, you will be presented with statistics. If you are over 25% savings, I would suggest you start using a compression service.

By using composer to install the module and the TinyPNG library, it's super easy to get started.

Type

in your terminal. Composer downloads the module, places it in the correct folder and downloads its dependency - TinyPNG PHP Library - and places it in the vendor folder.

Head into your Drupal website and click Extend in the menu. Scroll down (or filter) to TinyPNG and activate the module. 

API Key? What's that? Well, to make TinyPNG accept the requests from your website to the service you need an API key. It's a way of saying "howdy, can I get some service". It's also a way for TinyPNG to track how many images you get compressed per month. Don't worry, you get 500 for free every month, so unless you upload more that that, you're in the clear

If you should send more than 500 requests then you won't get access to the service until next month - or if you pay for the service. 

For normal use, 500 requests should be enough.

Getting an API key couldn't be simpler. Just visit the developer section of Tinypng.com and enter your name and email. 

You get an email with a link. Click it, and - boom! - you're in. On the page you can see your API key and also a counter that lets you know how many requests TinyPNG has processed using your unique API key.

Click the Configuration link in Drupal's menu and look under Media. There you find TinyPNG Settings. Click it.

Now it's time to copy the API code you got from the TinyPNG service. Paste it into the field on the settings page and hit Save configuration.

The module facilitates two different kinds of image compression: on upload or via Drupal's own Image Styles - or both. I myself use the uploading kind since I then know that I won't reach the monthly limit through the API. If I would use the image style version, then I could reach - and pass - the limit in a fast way since I manage a site with a lot of images. Sure, I don't need to use the image action on every single Image style I have in Drupal, but I sure would be tempted to do so. 

If you choose to use the TinyPNG API whn uploading you get two options under Integration method: Download and Upload. They are the same, the only thing to remember is to use Upload on your local installation and Download on your live server. The help text says it all: "The download method requires that your site is hosted in a server accessible through the internet. The upload method is required on localhost." Though, personally, the names could be better. But anyway, it does the job.

Well, actually there isn't a step 5. After installing the module with its dependencies, entering your API key there isn't much more. Just sit back, relax and watch the images shrink when uploading and/or showing them to the users making their experience on your website faster and better.

Here is also a comparison before and after using TinyPNG.

Displaying videos from YouTube and Vimeo on websites is a common practice used by many companies to create more engaging experiences for their visitors. While it is important to offer customers a great experience, it is also imperative to make sure your site visitors understand what's happening as they interact with your site.

We have developed a visually engaging solution for this. In this blog post we show the solution we have created with screenshots, code snippets, and live examples.

A lot of media functionality has been added into Drupal core over the last few releases. First, we got the Media module in 8.5 which offers fieldable media types. Then we got the Media Library module which offers a popup where users can select media assets. Now for Drupal 8.8 and above you have the ability to embed media assets directly into the editor.

There are three important parts when it comes to media functionality. You need the following:

• Store media assets (media types)
• Reuse media assets (media library)
• Embed media assets

As of Drupal 8.8+,  the above-mentioned functionality is all supported in Drupal core without installing any extra modules.

This functionality could be achieved before Drupal 8.8 by using Media entity, Entity embed and Entity browser. But required a fair bit of site-building and configuring. However, now all you need to do is install Media and “Media Library” and you’re good to go.

In this tutorial, you’ll learn how to create and manage assets, using the Media field and Media library. Then we look at how to embed assets directly in the editor. We finish things off by creating a custom media type to manage Instagram posts.

A Drupal 7 to 8 migration is anything but boring because there are so many ways to perform a migration! Depending on the complexity of the project, we can choose a technique that suits it best. The one we are going to discuss in this blog is to migrate content and configuration from Drupal 7 to Drupal 8 using a CSV import method.

Drupal provides various modules for importing data from different sources like JSON, XML and CSV. Drupal 8 core migration API system offers a whole suite of APIs that can essentially handle any kind of a migration from a previous version of Drupal to Drupal 8. 

In order to migrate from Drupal 7 to Drupal 8 using CSV import, we will need these modules.

Drupal 7 Modules -

• Views Data export: This module needs to be installed in our Drupal 7 site. The Views Data export module helps in exporting the data in CSV format.

• Views Password Field: This module helps to migrate passwords which will send passwords in hashed format. 

Drupal 8 Modules -

• Migrate – The Drupal 8 Migrate module helps in extracting data from various sources to Drupa 8.

• Migrate Plus – This Drupal 8 module will help in manipulating the imported source data

• Migrate Drupal – This module offers support in migrating content and configurations to Drupal 8.

• Migrate source CSV – This module offers a source plugin that can migrate entities and content to Drupal 8 from .csv files.

• Migrate Tools – This Drupal 8 module helps by offering UI tools/Drush commands to manage migrations.

• Configuration Development Module – This module helps in importing configuration files to Drupal 8.

First, we need to create a custom module for our Drupal 8 migration. Let’s name this module as test_migrate. And we know that after creating a custom module we need to create the info.yml file.

Above screenshot shows keys that are required for info.yml.

Once the info.yml file is created, we need to create a migration group for the migration. This migration group needs to be created in the path: test_migration > config > install. Name of the group should be migrate_plus.migration_group.test_migration.yml.

Above screenshot shows the folder structure to create a migration group.

Inside the migrate_plus.migration_group.test_migration.yml file, we need to write id, label and description for the migration group which is shown in the screenshot below.

After creating the migration group, we need to install this group in our info.yml file. 

Now, we are going to write a migration script for the Users, Taxonomy term, Paragraphs, Content types. Note that you are migrating in the same order since there will be a link between these entities. For example, content will be created by a particular user - so we first need to migrate users and after that taxonomy, content type.

Now let’s write a script in yaml file for user migration. So, in order to write user migration, we need user yaml file with the name migrate_plus.migration.test_migration_users.yml and script for migration is shown below.

These are the keys required for migration here source csv file which we need to be migrated. Csv files should be placed in the path assets > csv > user.csv. Users.csv is also shown below.

Path - It indicates the path for the csv file.

header_row_count - This will give row count which is the header of a particular column.

Keys - which should be unique for every row.

Process - In this we are mapping csv files to fields.

Above image shows the mapping between fields and csv. Here, the name is the machine name of the user name field and title is the csv column title. If we have multiple data for a single field, then we use delimiters. Users may have multiple roles in that case we write like shown in the above image.

Images are migrated by writing custom plugin. Custom plugin can be written in the path src > plugin > migrate > process. In the above picture you can see that the user_image_import_process is a custom plugin written to migrate user images.

Inside UserImportProcess.php we are writing the function which will copy the image and save it to the destination. Script is shown in the image below.

In order to identify where images should be saved we will write one more function ImageImportprocess. In that function we will mention the machine name of the image.

In the users info.yml file there is a destination section which will indicate where the migrated data is to be stored and which is an entity. This is marked in the image below.

After creating code for users, we need to write yaml for taxonomy terms. Note that if you have only title field in your taxonomy then you do not need to write a separate yaml file. If you have multiple fields in taxonomy term, then you need to write a separate yaml file. In taxonomy terms we will have tid as key since tid will be unique for each term.

After this we will migrate paragraphs. For that we need to create a separate yaml file. The code to migrate is shown in the below image.

Lastly, lets migrate the content type. The yaml file for the content type is shown in the code below.

label: 'Migrate Content type data from the csv file'

migration_group: test_migration

source:id: test_migration_content

 plugin: csv

 # Full path to the file.

 path: 'modules/custom/test_migrate/assets/csv/content.csv'

 header_row_count: 1

 keys:

   - nid

process:

 # Adding the mapping between the fields and the csv columns.

 title: title

 promote: promoted_to_front_page

 sticky: sticky

 field_display_name: display_name

 field_marketing_tagline: marketing_tagline

 field_taxonomy:

   plugin: entity_lookup

   source: Taxonomy

   entity_type: taxonomy_term

   bundle_key: vid

   bundle: taxonomy

   value_key: name

 body/value: body

 body/format:

   plugin: default_value

   default_value: "full_html"

 field_paragraph:

   - plugin: explode

     delimiter: "|"

     source: fcid

   - plugin: skip_on_empty

     method: process

   - plugin: migration_lookup

     migration: test_migration_paragraphs

     no_stub: true

   - plugin: iterator

     process:

       target_id: '0'

       target_revision_id: '1'

destination:

 plugin: 'entity:node'

 default_bundle: content

migration_dependencies:

 required:

   - test_migration_paragraph

   - test_migration_taxonomy

dependencies: { }

After writing all the yaml files the migration test_migrate.info.yml will contain the below installs.

Once you finish all these steps, go to your site and install your custom module.

Next, go to your project in terminal and run this “drush ms” command to check migration status as shown in the below image.

To migrate use command drush mim migration-id . We can see the migration ID in the above image.

Once done, if you check the migration status you can see the number of migrated items.

Now you can observe that all the content is migrated. If there is any error in the data migration, the process will terminate at that particular instance. Check the issue with that content and then once again you can restart the migration.

Things to Remember

• If the migration is terminated in between the process, the status of migration will display as “importing”. In order to change the status to idle you need to run the command drush mrs migration-id. Next, run command drush mim migration-id

• If you want rollback the migrated content, then run the command drush mr migration-id

• If you have changed anything in the code after starting the migration process, then make sure you run the command drush cdi test_migration. This command will help you to reflect the changes while migrating. Once done, do a thorough check on your site to see if all the content is migrated.

Migrating content from Drupal 7 to 8 using this CSV import method is one of the many ways of a Drupal 8 migration. If you need assistance in migrating any of your Drupal projects to Drupal 8, contact our expert Drupal developers now.

Leave us a Comment

Know more about our technology driven approach to recreate the content management workflow for [24]7.ai

Find out how we transformed the digital image of world’s largest healthcare provider, an attribute that defined their global presence in the medical world.

Discover how a Drupal powered internal portal encouraged the sellers at Flipkart to obtain the latest insights with respect to a particular domain.

VIEW ALL CASE STUDIES

Florida Drupalcamp 2020 is the event that celebrates open-source software and brings together a worldwide community of Drupal users, developers, marketers and content specialists to a spot. The brightest of minds share their expertise, level up their skills, and make new friends in the community every year. 

This year, OpenSense Labs is a Silver Sponsor for Florida Drupalcamp 2020! To be held from 21-23 February 2020, the event will provide for a platform where developers, designers, and marketers gather to explore the most ambitious and cutting edge case studies.

If you're going to be around during the camp, do not miss out on these sessions: 

A central content repository allows the content editors to edit content directly from the backend of one site. Using the publisher site, organizations can publish, reuse, and syndicate content across a variety of subscriber sites and publishing channels.

The session will stress the importance of having a centralized reporting to boost the editorial teams’ productivity & article publication pace.

At the end of the session the attendees would be able to take away the following:

• Centralized Content Distribution Architecture.
• Real-time content syndication by setting up publisher and subscriber sites.
• Configuring content schema between publisher and subscriber sites.
• Minimizing Failures during data transmission.
• Choosing the right infrastructure for content distribution.

Vidhatanand will be sharing how we have built an enterprise search over the traditional by tinkering with robust Apache Solr and Drupal 8, leveraging portability using Java Script and with a diverse range of CMSs, thereby increasing efficiency by 40%.  

He will walk you through the complex architecture of federated search and challenges amidst architecting a microservice. You will be equipped with the know-how of:

• Enhancing website search experience retaining a blend of useful and accurate results.
• Expanding inter-site searchability decreasing the bounce rate and latency.
• Increasing data discovery and interoperability of information by cross-functional support to a plethora of platforms. 

Taking this great opportunity to be a part of Florida DrupalCamp 2020 we can’t wait to connect with you about the amazing things our team has to offer. Come stop by and say hello to get your hands on some cool Drupal swag!

When: 21-23rd February 2020 

Where: Florida Technical College, 12900 Challenger Parkway, Orlando, Florida 32826

The Drupal Community Working Group (CWG) is pleased to announce that registration is now open for a full-day Mental Health First Aid workshop on Sunday, May 17, 2020 (the day before DrupalCon Minneapolis begins) in Bloomington, Minnesota. 

The workshop will be held "field trip" style; it will be held off-site, at the Health Counseling Services facility in Bloomington, Minnesota, from 8:30am-5pm. Transportation will be provided to and from a location near the Minneapolis Convention Center (the site of DrupalCon) to the workshop. Following the workshop, attendees are invited to (optionally) attend a pay-on-your-own group dinner to decompress and discuss the day's workshop.

The CWG believes that these types of proactive workshops will help improve our community's mental health literacy and awareness, as well as making it easier for us to have open, honest, and respectful conversations and potentially spotting signs of when community members are in need of assistance.

The Drupal Association is generously sponsoring the workshop by providing funding to help defer the cost of the workshop as well as providing transportation. 

From the Mental Health First Aid website:

Mental Health First Aid is a course that gives people the skills to help someone who is developing a mental health problem or experiencing a mental health crisis. The evidence behind the program demonstrates that it does build mental health literacy, helping the public identify, understand, and respond to signs of mental illness.

Mental Health First Aiders learn a single 5-step action plan known as ALGEE, which includes assessing risk, respectfully listening to and supporting the individual in crisis, and identifying appropriate professional help and other support. Participants are also introduced to risk factors and warning signs for mental health or substance use problems, engage in experiential activities that build understanding of the impact of illness on individuals and families, and learn about evidence-supported treatment and self-help strategies.

Over the past few years, the CWG has organized proactive community health events, including on-going Code of Conduct contact training, as well as previous DrupalCon North America trainings on leadership, teamwork, and communications. 

In order for the workshop to proceed, we need at least ten community members to register by April 1, 2020 at https://healthcounselingservices.com/events/adult-mental-health-first-aid-11/. 

When registering:

• Choose the "Pay now" option (do not select the "Bill my organization" option.
• Use the coupon code: MHFA30 to receive $30 off the regular price.
• For the "Name of organization", "Name of site", "Supervisor's name", and "Supervisor's phone" fields, feel free to use "not applicable".
   

Problem/Motivation

To perform A/B testing, segmentation, and the personalization of a webform, a site builder needs to create a variant of the form that can be triggered based on certain contexts, which can be as simple as a custom URL.

A webform variant might alter a form's labels, descriptions, and even its confirmation page. A webform variant could be used to create an A/B test to confirm if a tweak or improvement to a form's user experience increases the rate at which the user completes a form. A basic A/B test would randomly load two variants, allow a defined number of users to complete the form, and then review the results to determine which variant had the highest completion rate. The most successful variant can then be permanently applied to the webform.

A webform variant can also be used to create a personalized webform based on a user's demographics. For example, webform's available inputs, labels, and even options could be altered based on a user's gender, age, locale, employer, etc. Even subtle tweaks can improve a form's user experience - for example, removing inappropriate disease options or inputs based on a user's gender can simplify an appointment request form.

Solution/Resolution

Right now, the one out-of-box solution is to create multiple instances of a webform and route users to the appropriate webform. The biggest issue with having multiple webforms is that, in doing so, it collects two different datasets. Ideally, all submission data should go into the same results table to be analyzed with just the user experience changing. You can also use conditional logic to tweak hide/show elements and disable/enable certain behaviors.

Both approaches have limitations and lack some organization. For A/B testing, it is possible to alter a form via JavaScript. Still, this approach is limited to front-end tweaks - for example, you can't change an element's server-side conditional logic using...Read More

Drupal provides a rich ecosystem of tools and features to turn your content system into an effective and performant platform. But it's not the only technology you want to rely on to reach your audience. Integrating with third-party systems can provide high-value experiences, such as:

• External search technologies like Solr and ElasticSearch are fast, flexible and scalable to satisfy even the largest workloads
• Messaging services like SendGrid or Twilio can manage delivery and tracking for important notifications

Another technology that websites depend on to be fast and reliable is a content-delivery network, or CDN. These systems help manage user traffic and deliver content as fast as possible while limiting how much work is required of the servers that actually host your website. 

Cloudflare is one of the big names in the CDN world and they're showing that their global network can do much more with the introduction of Cloudflare Workers. This is a new feature using the V8 engine that is also used by Chromium and Node.js. 

Workers operate on Cloudflare's network to process every inbound request. While many integrations, like Solr search, affect the user experience after reaching the site, Workers kick in before the user reaches the site. Similar to cloud services that are marketed as "serverless," Cloudflare takes care of managing the deployment and workload concerns.

Rather than running on an individual’s machine (e.g a browser application or on a centralized server), Workers functions run on Cloudflare’s Edge Network - a growing global network of thousands of machines distributed across hundreds of locations. Each of these machines hosts an instance of the Workers runtime, and each of those runtimes is capable of running thousands of user-defined apps.

- Source: Cloudflare Workers - How it Works

Written in Javascript, Workers can be created and edited in the Cloudflare web console or through CLI tools. There is also a very handy selection of templates to get started: https://developers.cloudflare.com/workers/templates/

What does this mean if you're operating a Drupal site? Workers provide a new outlet to expand the functionality of your application, help replace or simplify existing features, or get access to tools that are otherwise limited to large-scale hosting plans. In some cases, a Worker can replace a module that you need to install and maintain -- or even build yourself. In other cases, using Workers can help reduce the load on your application database, by handling redirects for example. Workers also expand on Cloudflare's security benefits, by blocking malicious traffic before it reaches your application server.

A/B testing, or split testing, is one common way to compare two different pages, to measure the effectiveness of the content or design. Users to a specific URL are shown version A or version B, based on random assignment or a cookie assigned to certain users. Cloudflare Workers provide an easy-to-use template to get this working on your site.

Use this instead of a Drupal module: A/B Test JS

The Redirect module provides a great way for editors to manage redirects from one URL to another. Workers can accomplish the same thing with even more flexibility. Managing these redirects at the edge also can save the load on your application server. For a site migration, this can be especially useful to route traffic between the new application and the old one.

Use this instead of a Drupal module: Redirect

For marketing or commerce needs, it's more effective to know something about a user when they first reach the site. Where is the user located in the world? Is the visitor using the organization's internal IP address? By knowing this kind of information, you can make smart decisions about how to route the request or what language to show the user. Workers have access to the incoming request in order to manage these choices, by setting a cookie or routing to different versions of the application. For sites with a global audience and varying needs, this type of flexibility is critical.

Use this with Drupal's Multilingual features. 

The Views module is the lifeblood of any dynamic Drupal site, and integrating with contextual filters helps manage the complex mix of content and taxonomies. What's better than showing these filters in a dropdown? Anticipating the user's needs and prepopulating the contextual filter. Similar to above, we can make certain assumptions about our user based on their geolocation, for example, and set a cookie that is read by Views. This kind of efficiency can improve the user experience and make it easier for visitors to accomplish their task on the site.

Use this with Drupal module: Views Extras

Email marketing campaigns rely on specialized URL parameters to track which visitors reach your landing pages. Some of these parameters are useful to Drupal, to provide a custom experience to the user. But when these URLs become unwieldy and very long, the user may be confused or suspicious. Using a Worker, we can read the query parameters and respond accordingly -- maybe to send a confirmation message to a logging service. Then the user is directed to a simplified URL without all the extra parameters. Similarly, these types of rules can help detect malicious requests and block them from reaching the site.

Use this with email campaigns.

Building web applications can be complicated, more so today than ever before. Users have high expectations when they visit our sites. Adding a tool like Cloudflare Workers should make that process easier to manage and maintain. Whether a site is running Drupal or some other technology (or both!), Workers may help deliver the kind of rich experiences that users are looking for.

​

Growing the community is the implicit goal of every Drupal meetup and event I attend. It's a constant topic of conversation at Drupal event organizing meetings, agency roundtables, and panels about recruitment and selling Drupal. Last year, I created a presentation for DrupalCamp Atlanta called "Growing the Drupal Community". Since then, it's been my hallway track conversation of choice, and everyone I talk to seems onboard with the goal of growing Drupal. As part of my role on the Drupal Association board, I'm chairing the Community & Governance Committee. We've been having lots of conversations about facilitating community growth, and I wanted to share some of what I've been thinking.

By definition, if we want to grow Drupal, that means talking to people outside the Drupal-sphere. So who would we be targeting?  

• Decision makers selecting a technology (Marketing/Communications and IT)
• Developers and technologists curious about Drupal
• Drupal users who aren't active in the community
• Users who inherit a Drupal project
• Agencies who are using Drupal for the first time
• People looking to switch careers  

These are who I think of when I think of growing the community. It's important to remember that we're not just talking to developers or decision makers, but people from a wide range of backgrounds. The Drupal community is made up of designers, project managers, developers, translators, content and accessibility experts, and folks with other roles or who do Drupal as one of their many responsibilities.

Growing the Drupal community means bringing our audiences one step closer to participating in the community. That could mean different things for different people depending on what type of user they are and where they're at in their "Drupal Journey." Here are some tasks early on in this journey that we should make easier:

• Install Drupal
• Try out a demo
• Watch a video about how Drupal works

• Attend a first Drupal event
• Attend Global Training Days 
• Make an account on Drupal.org and/or Drupal Slack
• Talk to another Drupal user in the community
• Join a Drupal user group on meetup.com 

• Join a mailing list to learn more about Drupal
• Read a case study or download promo material
• Watch a video from a Drupal event
• Search for help on Drupal.org or Drupal StackExchange  

Later in the journey, we hope to take users beyond feeling like "Newbies." We want them to use Drupal successfully, become members of the Drupal Association, make contributions, and become Drupal ambassadors. But arguably, the steps above are more important for growing the community.

Drupal.org is the home of the Drupal project and it should help move users further along their journey to being part of the community. It's a big ask. Drupal.org is also a place for the existing community to communicate and collaborate, and it's a complex website with a lot of moving pieces.   

That being said, here are some key places we could focus on to build community engagement:  

• Community page: At DrupalCon Amsterdam, I conducted a UX feedback session and collected some feedback about the Community page. One audience member said "I feel like this is structured in a way that people who are very familiar with the community would think about it, rather than from the point of view of someone who is new to the community." I think repositioning this page for newcomers and focusing on local events (camps, meetups, and local training days), joining the Drupal Slack, local associations, and getting started using Drupal would be a big improvement.
• Groups.drupal.org is still a useful community organizing tool for some topics and groups, but many of its features have effectively been replaced by meetup.com, confusing many new users who stumble across abandoned groups on the website. When a user stumbles across a group, clearly pointing them to the place where they can find upcoming events and the most relevant content would be really helpful.
• The Evaluator Guide is a valuable tool for developers trying out Drupal for the first time. I think adding in an evaluator guide for different audiences (especially decision makers) is essential to creating a smooth and welcoming onboarding experience.

• Spread the success stories of Drupal in your local communities and networks, especially to those outside the Drupal community. Post those stories on LinkedIn, attend events outside the Drupal-sphere. And look for ways to promote Drupal in outlets where non-Drupal folks hang out.
• Volunteer with the Promote Drupal initiative 
• Be active in your local Drupal community
• Welcome newcomers on Slack, Drupal.org, and at the Drupal events you attend 
• Look for opportunities to hire and train those outside the Drupal community  

Let me know your thoughts and what you think of the ideas above. I'd love to start a conversation.

Drupal, one of the prominent WCMS in the world, delivers its services to giants like AL-Jazeera, URRWA, and Georgetown University. Having an impressive network of committed developers, it makes up as a robust, flexible, scalable, and highly secure WCMS for small and big businesses alike. Migrating to Drupal 8 can prove a nice pull for enterprises if they are looking to enhance their workflow efficiency, however, the move must be undertaken with utmost care.

Direct .mp3 file download.

We debut a new podcast format, and talk with Leslie Glynn about the Aaron Winborn Award and Mauricio Dinarte about Drupal 8 migrations.

• https://www.drupal.org/aaron-winborn-award
• https://understanddrupal.com/migrations
• https://events.drupal.org/minneapolis2020/training/drupal-8-content-mig…
• https://www.drupal.org/project/migrate_upgrade

• Drupal Career Online - the 12-week (3 half-days/week) best-practice focused training program begins February 24, 2020. Learn more at our free Taste of Drupal webinars February 19.
• Professional local development with DDEV - 2-hour, hands-on, online workshop held monthly (Tuesday, March 3).
• Local Web Development with DDEV Explained
• Florida DrupalCamp 2020 - February 21-23, 2020.
• MidCamp Composer Basics workshop - Wednesday, March 18, 2020.

• MyDropWizard.com - Long-term-support services for Drupal 6, 7, and 8 sites.

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

With performance being a continuous bottleneck for enterprises trying to deliver an exceptional digital experience to customers and please search engines, this blog will serve as a sight to the sore eyes. 

• Provided by Acquia, a Drupal funder's company
• Bundled Apache-MySql-PHP-phpMyAdmin-Drush stack
• No better option for macOS users, Especially, docker has performance issue, see Performance tuning for volume mounts (shared filesystems)

So if we could get Acquica Dev Desktop working as what we expected, it would be a good alternative for Drupal devs who use macOS.

Since joining Planet Drupal in 2016, no seriously new blog posts for a long time. Last year, my personal site was rebuilt with Drupal 8 again. And a few months ago, I found my feed was removed from Planet Drupal. Recently, I wanted to join in it again. The first task is to make a valid RSS. This is the background.

Suggestions from How to get your feed to the Planet

New year, new possibilities, as we say in Norway. Which is why I have relaunched my blog using Gatsby.js. I could write a blog post about that, but I am not going to do that today. There is a lot of tutorials on how to set that up (one of my personal favorites is this one from Lullabot), and there is even an official page in the Gatsby.js documentation.

I could probably write many blog posts about different aspects I tweaked and looked at in the migration, but one field I feel is not often talked about is geography and performance.

With regards to servers, many (at least basic) Drupal sites are probably geographically limited by the actual server that is supposed to serve the web requests, and the location of this particular server. With a static site, made for example with Gatsby.js, you can deploy it to a Content Delivery Network (CDN) and have the same static html files on servers all around the world. This could mean that a website visitor from Tokyo to your static site could get a response from a server in Tokyo. The traditional Drupal site however might be on a server in Ireland, and then a visitor from Tokyo would quite often have to send their request all around the world to get responses.

This idea is not very new. In fact, there are several providers that let's you deploy your static site on their CDN (more or less) for free. They will then serve your static HTML from different parts of the world, depending on the visitor. What a world to live in. But instead of comparing their service and the user experience of deploying, I decided to compare them by which ones were being performant from all parts of the world. A geographic performance cup if you like.

The competitors in the cup are:

• Surge.sh
• Zeit Now
• Netlify
• S3 with Cloudfront (a service from Amazon Web Services - AWS)

Instead of doing a very long analysis, so let's just start with the results.

The fastest service is S3 with Cloudfront. S3 is a static file storage, and Cloudfront is the CDN service from Amazon.

In the same way I could write many things about my migration to Gatsby, I could also speculate and write many things about this result. Instead I want to just show some animated gifs about interesting aspects of the different geography results for the providers. I am going to do them in reverse order, best result last.

Fourth place: Surge.sh:

Third place: Netlify:

Then, slightly behind on second place, Zeit Now:

Lastly, the winner, here is AWS S3 with Cloudfront:

The numbers are one thing, but let's talk a bit about their significance. The tests were performed from AWS datacenters, and the 2 services scoring highest is either an AWS service (S3/Cloudfront), or uses AWS for their service (Zeit Now). Meaning the actual numbers does not necessarily mean that Netlify is 144% slower than S3/Cloudfront. It also does not mean I think any of these services have been proven to be better or worse than others.

I think it means that now that we are able to serve static HTML pages for our blogs or websites in a somewhat dynamic way, we can make the performance more democratic and less unfair. I don't want to discriminate readers of my blog based on their location (or anything else for that matter). Performance matters, but performance also differs from different parts of the world.

I guess what I am trying to say is: Let's make the world a better place by thinking about everyone that lives there, no matter where they live. So I will finish this post with an animated gif about just that. The world.