Drupal

CiviMail

New Drupal Modules - 19 April 2018 - 12:49am

Integration with CiviCRM CiviMail.

Features
  • Send a node from a CiviCRM Contact to CiviCRM Groups.
  • Per content type configuration: enable CiviMail and set the view mode for the mail.
Dependencies

CiviCRM Core, CiviCRM Drupal, CiviCRM Entity.

Categories: Drupal

Security Check Kit

New Drupal Modules - 18 April 2018 - 11:51pm
Categories: Drupal

VK comments Social Plugin

New Drupal Modules - 18 April 2018 - 11:33pm

Implement (VK)Vkonakte commenting as a block. Each block with its own settings.

Categories: Drupal

Commerce Stripe Payment Request

New Drupal Modules - 18 April 2018 - 11:02pm

Provides a single Stripe payment request button for processing Apple Pay/Google Pay payments on the web for Drupal Commerce.

The paymentRequestButton Element gives you a single integration for Apple Pay, Google Pay, Microsoft Pay, and the Payment Request API —a browser standard that gives your customers the ability to quickly provide you payment and address information they’ve stored with their browser.

Categories: Drupal

Flocon de toile | Freelance Drupal: Set up a simple inventory control with Drupal Commerce 2

Planet Drupal - 18 April 2018 - 11:00pm
If we do not have (yet) a contributed module (commerce_stock should be available soon), Drupal Commerce 2 already has an API to set up an simple inventory control, with the Availability Manager service. Let's look at how to set up a very simple stock control, based on a field (for example field_stock) that has been added on a product.
Categories: Drupal

myDropWizard.com: Security Vulnerabilities Affect Your Dev Sites Too

Planet Drupal - 18 April 2018 - 2:25pm

When Drupalgeddon 2 (SA-CORE-2018-002) happened a few weeks back, we saw plenty of buzz from agencies and other organizations throughout the community who were having patching parties.

Yay for patching! But were you left vulnerable by not updating all of your installations?

If you didn’t update development and staging sites, you may be at risk!

Due to the nature of the vulnerability, from the largest of enterprise applications to the smallest of brochure or hobbyist site builds, all Drupal sites were affected. This includes any testing or staging versions of your site. Depending on how you manage your local development sites, even those may have been exposed too!

Still not convinced? Read more to find out why you need to update ALL sites!

Categories: Drupal

Sooper Drupal Themes: Web Forms In Drupal 8 With Contact Module And Webform Module | 8 Days To Drupal 8 | Day 3

Planet Drupal - 18 April 2018 - 10:57am

We're counting down the days to the official SooperThemes Drupal 8 Release! Count with us as we will be writing a Drupal 8 related blog post every day for the next 8 days.

Drupal 8 web forms and drag and drop forms video tutorial

view on sooperthemes.com if you can't see the video

This tutorial is aimed at people who just need a contact form or some other kind of user input form. We'll cover deciding between the core contact module and the popular webform module. We won't cover using the Drupal API to program complex forms that integrate with external applications.

Drupal 8 Core Contact Module

Whereas the Drupal 7 core contact module was not very useful due to a total lack of flexibility, the Drupal 8 version is much nicer. It's nicer because you can add fields to it. You're no longer limited to just the name, email, subject and message fields that were baked into the Drupal 7 version. 

Not only does the new contact form allow for custom text fields, it even supports file uploads, entity references, date fields, and other Field API fields.This simple yet powerful form builder module is not limited to just contact forms; you can use it to create questionnaires, gather user feedback, etc.  

Drupal 8 Contact module customized form

Better Together: Contact Module + Contact Storage Module

One major inconvenience of the Contact module is that is doesn't store any messages that are sent. Your only option is to send the message via email and afterwards there is no copy of the message in your Drupal site. The contact storage module will store your messages as entities. It lets you administer the messages and provides integration with the views module. Since the messages are stored as Drupal entities you also gain interoperability with other modules in the Drupal ecosystem. This will allow you to do even more, for example exporting messages as CSV, searching messages, and pushing messages to your CRM.

Webform Module

Drupal's popular webform module is a massive framework that offers a ton of extra options that the contact module doesn't have. You should choose the webform module if these extra features are useful to you and you're prepared to learn the ropes around a more complex user interface. The webform module can be intimidating at first because there are so many elements and settings... but once you're familiar with the interface you can configure and design very powerful forms fairly easily. 

To see what the webform module offers it's really better for me to show than tell. Check out the youtube video above where I show you the interface of the webform module.

Drupal 8 Webform module form using the flexbox layout option

Contact Module vs Webform Module

Personally I choose the webform module for anything that is more complicated than just the standard contact form with a subject and message field. The contact module is powerful and extendable, but the webform module gives you everything you need in one place. It's a purpose-built single-purpose application within Drupal and once you get familiar with it it's really very powerful. 

It also lets met build multi-column form layouts, a feature that I use often.

A feature-base comparison of Contact and Module based on features that I think are important: Feature
  • Multi-column layouts
  • Control labels and placeholders
  • Control Submit Button Text
  • Route email with form options
  • Search in submissions
  • Export submissions
Contact
  • ✔ (can't remove Preview)
  • ✔ (needs additional modules)
  • ✔ (needs additional modules)
Webform
Placing Drupal 8 Forms With Our Visual Page Builder

We believe interoperability with the Drupal ecosystem is important for Glazed Builder. This is why we don't include a proprietary form builder in Glazed Builder and instead encourage you to create forms with Drupal's webform module. Currently Glazed Builder let's you place blocks created with the webform module anywhere in your drag and drop page. The contact module doesn't provide blocks that we can drag and drop natively, but you can install the contact_block module to fix that.

Categories: Drupal

Aten Design Group: Consolidating Websites Using Pantheon Upstreams

Planet Drupal - 18 April 2018 - 8:34am

Over the last couple years, organizations have been coming to us with a new problem. Instead of needing a single website, they need dozens, if not hundreds. They might be large universities with many departments, an association with independent franchises nationwide, or a real estate developer with offerings all over the world. Often, these organizations already have several websites supported by different vendors and technologies. They’ve become frustrated with the overhead of maintaining Drupal sites built by one vendor and Wordpress sites by another. Not to mention the cost of building new websites with a consistent look and feel.

While the details may vary, the broad ask is the same. How can we consolidate various websites onto a single platform that can be spun up quickly (preferably without developer involvement) and update and maintain these en masse, while maintaining enough structure for consistency and flexibility for customization. Essentially, they want to have their cake and would also like to eat it.

Over this series of posts, we’ll break down the various parts of this solution. We’ll first look at Pantheon’s hosting solution, and how its infrastructure is set up perfectly to give clients the autonomy they want. Then we’ll look at the command line tools that exist for developers to easily manage updates to dozens (if not hundreds) of websites. Lastly, we’ll look at the websites themselves and how Drupal 8 was leveraged to provide flexible website instances with structured limits.

Pantheon and Upstreams

Pantheon is a hosting solution designed specifically for Drupal and Wordpress websites. For individual sites they offer a lot of features, however the ones we’re most interested in are single click installations of a new website and single click updates to the code base. Using a feature called Upstreams, users can create fresh installs of Drupal 7, Drupal 8, or Wordpress that all reference a canonical codebase. When new code is pushed to any of those Upstreams, any site installed from it gets notified of the new code, which can be pulled into the instance with the click of a button.

Outside of the default options Pantheon maintains internally, developers can also build their own Custom Upstreams for website creation. Anyone with access to the Upstream can log into Pantheon and click a button to install a new website based on that codebase. In short this codebase will handle installing all of the features every website should have, establish any default content necessary, and be used to roll out new features to the entire platform. This setup allows non-technical users to easily create new websites for their various properties, and then handoff specific websites to their appropriate property managers for editing. We’ll go over more specifics of this codebase in a later post.

Since a developer is no longer required for the creation of individual sites, this frees up a lot of time (and budget) for building new features or keeping on top of maintenance. The process for rolling out updates is simple: the developer writes code for a new feature and pushes it to the upstream repository. Once pushed, every site connected to this upstream will get an alert about new features and a shiny button that pulls them in with a single click.

Pantheon and Organizations

At this point it’s worth mentioning that custom upstreams are a feature of a special account type called an Organization. An organization is used to group multiple websites, users, and Custom Upstreams under one umbrella. Organizations also come with additional features like free HTTPS and code monitoring services. It’s recommended that each organization signup with their own organization account, rather than use one tied to their development partner. This gives them full control over who can create new websites using their Custom Upstream, who can manage all their websites, and who can only access specific websites.

Organization accounts and Custom Upstreams go a long way in helping organizations reduce the overhead they may have from managing several properties simultaneously. Having the option to create an infinite number of websites in-house helps reduce the cost of growth. Having every website using the same codebase means new features can easily be rolled out to the entire platform and security vulnerabilities can be handled quickly.

The only downside with this approach is updates are generally applied one site at a time. The developer can push the code to the Custom Upstream, but it’s necessary to log into every website and click the button to update that site. For a handful of sites, this might be manageable. For dozens to hundreds, this problem becomes tedious. In the next post we’ll look at some of the scripted solutions Pantheon has for applying and managing an ever growing number of websites at once.

Categories: Drupal

Security advisories: Drupal core - Moderately critical - Cross Site Scripting - SA-CORE-2018-003

Planet Drupal - 18 April 2018 - 8:34am
Project: Drupal coreDate: 2018-April-18Security risk: Moderately critical 12∕25 AC:Complex/A:User/CI:Some/II:Some/E:Theoretical/TD:DefaultVulnerability: Cross Site ScriptingDescription: 

CKEditor, a third-party JavaScript library included in Drupal core, has fixed a cross-site scripting (XSS) vulnerability. The vulnerability stemmed from the fact that it was possible to execute XSS inside CKEditor when using the image2 plugin (which Drupal 8 core also uses).

We would like to thank the CKEditor team for patching the vulnerability and coordinating the fix and release process, and matching the Drupal core security window.

Solution: 
  • If you are using Drupal 8, update to Drupal 8.5.2 or Drupal 8.4.7.
  • The Drupal 7.x CKEditor contributed module is not affected if you are running CKEditor module 7.x-1.18 and using CKEditor from the CDN, since it currently uses a version of the CKEditor library that is not vulnerable.
  • If you installed CKEditor in Drupal 7 using another method (for example with the WYSIWYG module or the CKEditor module with CKEditor locally) and you’re using a version of CKEditor from 4.5.11 up to 4.9.1, update the third-party JavaScript library by downloading CKEditor 4.9.2 from CKEditor's site.
Reported By: Fixed By: 
Categories: Drupal

Acquia Developer Center Blog: How Acquia Blocked 500,000 Attack Attempts

Planet Drupal - 18 April 2018 - 8:15am

The Acquia blog has a fascinating and important post by Dries Buytaert and Cash Williams on the recent Drupal critical security vulnerability, and it's aftermath: Acquia blocks 500,000 attack attempts for SA-CORE-2018-002.

It's worth checking out in its entirety, but here are a few take-aways if you haven't gotten to it yet:

Tags: acquia drupal planet
Categories: Drupal

AdCoin Payments

New Drupal Modules - 18 April 2018 - 6:54am

Allow your customers to pay or donate through AdCoin.

Categories: Drupal

Acquia Developer Center Blog: Experience Express in Nashville: Decoupled in the Spotlight at DrupalCon

Planet Drupal - 18 April 2018 - 6:23am

As the weather heated up last week in Nashville and the city's eponymous hot chicken incinerated tongues left and right, something else was burning in the spotlight at DrupalCon Nashville: decoupled Drupal.

Tags: acquia drupal planet
Categories: Drupal

AWS Secrets Manager

New Drupal Modules - 18 April 2018 - 6:14am
AWS Secrets Manager

This Drupal module adds a new key provider for the Key module - it allows you to encrypt data using AWS Secrets Manager.

Get Started

This guide assumes you have an AWS account and working knowledge of AWS Secrets Manager and IAM, and the following resources provisioned in AWS.

  • One or more secrets
  • An IAM user with privileges to access the relevant secrets

Ensure this module and its dependencies are available in your codebase.

Categories: Drupal

InternetDevels: The Masquerade module: see your Drupal site through each user’s eyes!

Planet Drupal - 18 April 2018 - 6:10am

Let us invite you to an exciting masquerade! Its mission is to check what each user can see or do on your website. Drupal has an awesomely flexible system of user roles and permissions, as well as opportunities for fine-grained user access. These are the keystones of Drupal security, smooth user experiences, and cool features. You can make the most out of them, and then test the result for different users with the help of the Masquerade module.

Read more
Categories: Drupal

TEN7 Blog's Drupal Posts: Episode 026: Chris Weber, Software Engineer

Planet Drupal - 18 April 2018 - 6:00am
Chris Weber, software engineer at The Nerdery in Minneapolis, discusses his Drupal origins, as well as other related issues.
Categories: Drupal

Lullabot: Decoupled Drupal Summit at DrupalCon Nashville

Planet Drupal - 18 April 2018 - 5:59am

This first-ever Decoupled Summit at DrupalCon Nashville was a huge hit. Not only did it sell out but the room was packed to the gills, literally standing room only. Decoupled Drupal is a hot topic these days. The decoupled summit was an opportunity to look at the state of decoupled Drupal, analyze pros and cons of decoupling, and look at decoupling strategies and examples. There is lots of interest in decoupling, but there are still many hard problems to solve, and it isn’t the right solution for every situation. This summit was an opportunity to assess the state of best practices.

The summit was organized by Lullabot's Sally Young and Mediacurrent's Matt Davis, two of the innovators in this space.

What is “decoupled Drupal”? 

First, a quick explanation of what “decoupled Drupal” means, in case you haven’t caught the fever yet. Historically, Drupal is used to deliver all the components of a website, an approach that can be called “traditional,” “monolithic,” or “full stack” Drupal. In this scenario, Drupal provides the mechanism to create and store structured data, includes an editorial interface that allows editors to add and edit content and set configuration, and takes responsibility for creating the front-end markup that users see in their browsers. Drupal does it all.

“Decoupled”, or “headless” Drupal is where a site separates these website functions across multiple web frameworks and environments. That could mean managing data creation and storage in a traditional Drupal installation, but using React and Node.js to create the page markup. It could also mean using a React app as an editorial interface to a traditional Drupal site. 

Drupal tools and activity

Drupal core is enabling this activity through a couple of core initiatives:

Drupal and the Drupal community have numerous tools available to assist in creating a decoupled site:

  • Contenta, a pre-configured decoupled Drupal distribution.
  • Waterwheel, an emerging ecosystem of software development kits (SDKs) built by the Drupal community.
  • JSON API, an API that allows consumers to request exactly the data they need, rather than being limited to pre-configured REST endpoints.
  • GraphQL, another API that allows consumers to request only the data they want while combining multiple round-trip requests into one.

There’s lots of activity in headless CMSes. But the competitors are proprietary. Drupal and WordPress are the only end-to-end open source contenders. The others only open source the SDKs.

Highlights of the summit

The summit included several speakers, a business panel, and some demonstrations of decoupled applications. Participants brought up lots of interesting questions and observations. I jotted down several quotes, but it wasn't always possible to give attribution with such an open discussion, so my apologies in advance. Some general reflections from my notes:

Why decouple?
  • More and more sites are delivering content to multiple consumers, mobile apps, TV, etc. In this situation, the website can become just another consumer of the data.
  • It’s easier to find generalist JavaScript developers than expert Drupal developers. Decoupling is one way to ensure the front-end team doesn't have to know anything about Drupal.
  • If you have large teams, a decoupled site allows you to have a clean separation of duties, so the front and back end can work rapidly in parallel to build the site.
  • A modern JavaScript front-end can be fast—although several participants pointed out that a decoupled site is not automatically faster. You still need to pay attention to performance issues.
  • Content is expensive to create; decoupling is a way to re-use it, not just across platforms, but also from redesign to redesign.
  • You could launch a brand new design without making any changes to the back end, assuming you have a well-designed API (meaning an API that doesn't include any assumptions about what the front end looks like). As one participant said, “One day, React won't be cool anymore, we'll need to be ready for the next big thing.”
What are some of the complications?
  • It often or always costs more to decouple than to build a traditional site. There’s additional infrastructure, the need to create new solutions for things that traditional Drupal already does, and the fact that we’re still as a community figuring out the best practices.
  • If you only need a website, decoupling is a convoluted way to accomplish it. Decoupling makes sense when you are building an API to serve multiple consumers.
  • You don’t have to decouple to support other applications. Drupal can be a full-featured website, and also the source of APIs.
  • Some tasks are particularly tricky in a decoupled environment, like previewing content before publishing it. Although some participants pointed out that in a truly decoupled environment preview makes no sense anyway. “We have a bias that a node is a page, but that’s not true in a decoupled context. There is no concept of a page on a smartphone. Preview is complicated because of that.”
  • Many businesses have page-centric assumptions embedded deep into their content and processes. It might be difficult to shift to a model where editors create content that might be deployed in many different combinations and environments. One participant discussed a client that "used all the decoupled technology at their disposal to build a highly coupled CMS." On the other hand, some clients are pure Drupal top to bottom, but they have a good content model and are effectively already "decoupling" their content from its eventual display.
  • Another quote, “Clients trying to unify multiple properties have a special problem; they have to swallow that there will have to be a unified content model in order to decouple. Otherwise, you're building numerous decoupled systems.”
  • Once you are decoupled, you may not even know who is consuming the APIs or how they're being used. If you make changes, you may break things outside of your website. You need to be aware of the dependency you created by serving an API.
Speakers and Panelists

The following is a list of speakers and panelists. These are people and companies you could talk to if you have more questions about decoupling:

  • Sally Young (Lullabot)
  • Matt Davis (Mediacurrent)
  • Jeff Eaton (Lullabot)
  • Preston So (Acquia)
  • Matt Grill (Acquia)
  • Daniel Wehner (TES)
  • Wes Ruvalcaba (Lullabot)
  • Mateu Aguiló Bosch (Lullabot)
  • Suzi Arnold (Comcast)
  • Jason Oscar (Comcast)
  • Jeremy Dickens (Weather.com)
  • Nichole Davison (Edutopia)
  • Baddy Breidert (1xinternet)
  • Christoph Breidert (1xinternet)
  • Patrick Coffey (Four Kitchens)
  • Greg Amaroso (Softvision)
  • Eric Hestenes(Edutopia)
  • David Hwang (DocuSign)
  • Shellie Hutchens (Mediacurrent)
  • Karen Stevenson (Lullabot)
Summary

It was a worthwhile summit, I learned a lot, and I imagine others did as well. Several people mentioned that Decoupled Drupal Days will be taking place August 17-19, 2018 in New York City (there is a link to last year's event). The organizers say it will be “brutally honest, not a cheerleading session.” And they’re also looking for sponsors. I’d highly recommend marking those days on your calendar if you’re interested in this topic!

Categories: Drupal

Webform Validation for Argentinian CBU

New Drupal Modules - 18 April 2018 - 4:33am

Validate in the webform the Argentina CBU

Categories: Drupal

VisualNX

New Drupal Modules - 18 April 2018 - 3:44am

This is a place-holder, module is under development

Categories: Drupal

Dropsolid: Varnish for Drupal 8

Planet Drupal - 18 April 2018 - 3:00am
18 Apr Varnish for Drupal 8: the need for speed Niels A Drupal Drupal 8

Our team had been using Varnish a long time for our Dropsolid Drupal 7 project, and we thought the time had come to get it working for Drupal 8 as well. That is why our CTO, Nick Veenhof, organized a meetup about Caching & Purging in Drupal 8. Niels van Mourik gave an elaborate presentation about the Purge module and how it works.
I definitely recommend watching the video and the slides on his blog. In this blog post, we’ll elaborate and build on what Niels explained to us that day. 
First, let’s start off with a quick crash course on what Varnish actually is and how it can benefit your website.

 

Varnish 101

“Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 - 1000x, depending on your architecture.” (Source: Varnish-cache.org)

In layman’s terms, Varnish will serve a webpage from its own internal cache if it has it available. This drastically reduces the number of requests to the webserver where your application is hosted. This will, in turn, free up resources on your webserver, so your web application can handle more complicated tasks and more users.

In short, Varnish will make your web application faster and will allow you to scale it more efficiently.


How we use Varnish and Drupal 7

How did things typically work in D7? Well, you’d put a Varnish server with a Drupal compatible Varnish configuration file (vcl) in front of your Drupal 7 site and it would start caching it right away - depending, of course, on what is in the vcl and the headers your Drupal site sent.
Next step would be to install the Varnish module from Drupal.org. This module’s sole purpose is to invalidate your Varnish cache and it does so using telnet. This also requires the Varnish server to be accessible from the Drupal backend. This isn’t always an ideal scenario, certainly not when multiple sites are being served from the same Varnish.

The biggest issue when using Drupal 7 with the Varnish module is that invalidation of content just isn’t smart enough. For instance, if you would update one news item you’d only want that page and the ones where the news item is visible to be removed from Varnish’s cache. But that isn’t possible. This isn’t the module’s fault at all - it’s simply the way Drupal 7 was built. There are a few alternatives that do make it a little smarter, but these solutions aren’t foolproof either.

Luckily, Drupal 8 is a whole new ballgame!


How we use Varnish with Drupal 8

Drupal 8 in itself is very smart at caching and it revolves around the three following main pillars (explained from a page cache perspective, it will also cache parts of pages):

  • Cache tags: A page will get a list of tags based on the content that is on it. For instance if you have a news overview, all rendered news items will be added as tags to that page. Allowing you to invalidate that cache if one of those news items change. 
  • Cache context: A page can be different based based on variables from the current request. For instance if you have a news overview that filters out the news items based on a query parameter. 
  • Cache max-age: A page can be served from cache for X amount of time. After the time has passed it needs to be built up again. 

You can read more about Drupal 8’s new caching system here.


All about invalidation

Niels van Mourik created a module called Purge. This is a modular external cache invalidation framework. It leverages Drupal’s cache system to provide easy access to the cache data so you only need to focus on the communication with an external service. It already has a lot of third-party integrations available like Acquia Purge, Akamai and Varnish Purge.

We are now adding another one to the list: the Dropsolid Purge module.


Why does Dropsolid Purge do and why do I need it?

The Dropsolid Purge module enables you to invalidate caches in multiple Varnish load balancers. It also lets you cache multiple web applications by the same Varnish server. The module was very heavily inspired by the Acquia purge module and we reused a lot of the initial code, because it has a smart way of handling the invalidation through tags, but we’ll get in to that a little later. The problem with the Acquia purge module is that it is designed to work on Acquia Cloud, because it depends on certain environment variables and the Varnish configuration is proprietary knowledge of Acquia. This means that it isn’t usable on another environments. 

We also experimented with the Varnish purge module, but it lacked support for cache invalidation in case you have multiple sites/multisites cached by a single Varnish server. This is because the module actually doesn’t tell Varnish which site it should invalidate pages for, so it just invalidates pages for all the sites. It also doesn’t have the most efficient way of passing along the invalidation requests. It contains two ways of sending invalidation request to Varnish: one by one or bundled together. The one by one option results in a lot of requests if you know that updating a single node could easily invalidate 30 tags. Using the Bundle purger could get you to reach the limit of your header size, but more on that later.


What's in the bag?

Currently we provide the following features:

  • Support for tag invalidation and everything invalidation,
  • The module will only purge tags for the current site by using the X-Dropsolid-Site header,
  • The current site is defined by the name you set in config and the subsite directory,
  • Support for multiple load balancers,
  • There is also a default vcl in the examples folder that contains the logic for the bans.

It can be used for any environment if you just follow the installation instructions in the readme.


Under the hood Preparing and handling the responses for/by Varnish

By default, the module will add two headers to every response it gives:

  • X-Dropsolid-Site: A unique site identifier as a hash based on config (you provide through settings.php) and site parameters:
    • A site name
    • A site environment
    • A site group
    • The path of your site (e.g. sites/default or sites/somesubsite)
  • X-Dropsolid-Purge-Tags: A hashed version of each cache tag on the current page. (hashed to keep the length low and avoid hitting the maximum size of the header)

When the response reaches Varnish, it will save those headers along with the cache object. This will allow us to target these specific cache objects for invalidation.

In our vcl file we also strip those headers, so they aren’t visible by the end user:

sub vcl_deliver { unset resp.http.X-Dropsolid-Purge-Tags; unset resp.http.X-Dropsolid-Site; }
Invalidation of pages

For Drupal 8 we no longer use telnet to communicate with Varnish, but we use a BAN request instead. This request will get sent from our site, and it will only be accepted when it comes from our site.  We currently do this by validating the IP of the request against a list of IPs that are allowed to do BAN requests. 

As we mentioned earlier, we provide two ways of invalidating cached pages in Varnish:

  • Tag invalidation: We invalidate pages which have the same cache tags as we send in our BAN request to Varnish.
  • Everything invalidation: We invalidate all pages which are from a certain site.

Tag invalidation

Just like the Acquia purge module, we send a BAN request which contains a group of 12 hashed cache tags which then will be compared to what Varnish has saved. We also pass along the unique site identifier so we indicate we only want to invalidate for a specific site.

Our BAN request has the following headers:

  • X-Dropsolid-Purge: Unique site identifier
  • X-Dropsolid-Purge-Tags: 12 hashed tags

When Varnish picks up this request, it will go through the following logic:

sub vcl_recv { # Only allow BAN requests from IP addresses in the 'purge' ACL. if (req.method == "BAN") { # Same ACL check as above: if (!client.ip ~ purge) { return (synth(403, "Not allowed.")); } # Logic for banning based on tags # https://Varnish-cache.org/docs/trunk/reference/vcl.html#vcl-7-ban if (req.http.X-Dropsolid-Purge-Tags) { # Add bans for tags but only for the current site requesting the ban ban("obj.http.X-Dropsolid-Purge-Tags ~ " + req.http.X-Dropsolid-Purge-Tags + " && obj.http.X-Dropsolid-Site == " + req.http.X-Dropsolid-Purge); return (synth(200, "Ban added.")); } }

We check if the request comes from an IP that is whitelisted. We then add bans for every cache object that matches our unique site identifier and matches at least one of the cache tags we sent along. 

You can easily test this by updating a node and seeing that Varnish will be serving you a new version of its page. 
 

Everything invalidation

When the everything invalidation is triggered, a BAN request is sent with the following headers:

  • X-Dropsolid-Purge-All: True
  • X-Dropsolid-Purge: Unique site identifier

And we execute the following logic on Varnish’s side:
 

sub vcl_recv { # Only allow BAN requests from IP addresses in the 'purge' ACL. if (req.method == "BAN") { # Same ACL check as above: if (!client.ip ~ purge) { return (synth(403, "Not allowed.")); } # Logic for banning everything if (req.http.X-Dropsolid-Purge-All) { # Add bans for the whole site ban("obj.http.X-Dropsolid-Site == " + req.http.X-Dropsolid-Purge); return (synth(200, "Ban added.")); } } }

When Varnish receives a BAN request with the X-Dropsolid-Purge-All header, it will ban all cache object that have the same unique site identifier. You can easily test this by executing the following command: drush cache-rebuild-external.

Beware: a normal drush cache-rebuild will not invalidate an external cache like Varnish.


Why this matters

To us, this is yet another step in making our cache smarter, our web applications faster and our servers leaner. If you have any questions about this post, you can always leave a comment in the comment section below or open an issue on drupal.org.

Are you looking for a partner that will help you to speed up your site, without having to switch hosting? The Dropsolid Platform helps you to adjust and streamline your development processes, without the typical vendor lock-in of traditional hosting solutions. At Dropsolid, we also offer dedicated hosting, but we never enforce our own platform. Dropsolid helps you to grow your digital business - from every possible angle!

 

Blog overview     Get in touch

Categories: Drupal

Permissions filtered by modules

New Drupal Modules - 18 April 2018 - 2:59am

Permissions filtered by modules

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal