Drupal Planet

Subscribe to canal de noticias Drupal Planet
Drupal.org - aggregated feeds in category Planet Drupal
Actualizado: hace 13 horas 5 mins

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

Mié, 04/18/2018 - 14:57

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.

Aten Design Group: Consolidating Websites Using Pantheon Upstreams

Mié, 04/18/2018 - 12:34

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.

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

Mié, 04/18/2018 - 12:34
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: 

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

Mié, 04/18/2018 - 12:15

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

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

Mié, 04/18/2018 - 10:23

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

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

Mié, 04/18/2018 - 10:10

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

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

Mié, 04/18/2018 - 10:00
Chris Weber, software engineer at The Nerdery in Minneapolis, discusses his Drupal origins, as well as other related issues.

Lullabot: Decoupled Drupal Summit at DrupalCon Nashville

Mié, 04/18/2018 - 09:59

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!

Dropsolid: Varnish for Drupal 8

Mié, 04/18/2018 - 07:00
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

Matt Glaman: DrupalCon: friends, family & fun in Nashville

Mar, 04/17/2018 - 23:00
DrupalCon: friends, family & fun in Nashville mglaman Tue, 04/17/2018 - 21:00

DrupalCon is always something I look forward to, ever since attending my first one at DrupalCon Los Angeles 2015. As I wrote over a week ago, I drove down from Wisconsin with my wife and two boys to Nashville. We came down for the weekend before and stayed for the weekend after to do some touristing and vacationing. I tried to write one blog about DrupalCon but realized I couldn't really condense everything I had to say. So I plan on pushing out a few post-Nashville blogs.

Tandem's Drupal Blog: Tandem Named Leading Drupal Developer

Mar, 04/17/2018 - 21:00
April 18, 2018 Clutch has named Tandem one of the leading Drupal development agencies in SF for 2018. Last month, the B2B ratings and reviews platform Clutch named the top San Francisco agencies and developers in 2018. We are proud to announce that Tandem was recognized for our expertise and made the list! While we have experience with a variety...

Dries Buytaert: Acquia blocks 500,000 attack attempts for SA-CORE-2018-002

Mar, 04/17/2018 - 16:51

On March 28th, the Drupal Security Team released a bug fix for a critical security vulnerability, named SA-CORE-2018-002. Over the past week, various exploits have been identified, as attackers have attempted to compromise unpatched Drupal sites. Hackers continue to try to exploit this vulnerability, and Acquia's own security team has observed more than 100,000 attacks a day.

The SA-CORE-2018-002 security vulnerability is highly critical; it allows an unauthenticated attacker to perform remote code execution on most Drupal installations. When the Drupal Security Team made the security patch available, there were no publicly known exploits or attacks against SA-CORE-2018-002.

That changed six days ago, after Checkpoint Research provided a detailed explanation of the SA-CORE-2018-002 security bug, in addition to step-by-step instructions that explain how to exploit the vulnerability. A few hours after Checkpoint Research's blog post, Vitalii Rudnykh, a Russian security researcher, shared a proof-of-concept exploit on GitHub. Later that day, Acquia's own security team began to witness attempted attacks.

The article by Checkpoint Research and Rudnykh's proof-of-concept code have spawned numerous exploits, which are written in different programming languages such as Ruby, Bash, Python and more. As a result, the number of attacks have grown significantly over the past few days.

Fortunately, Acquia deployed a platform level mitigation for all Acquia Cloud customers one hour after the Drupal Security Team made the SA-CORE-2018-002 release available on March 28th. Over the past week, Acquia has observed over 500,000 attacks from more than 3,000 different IP addresses across our fleet of servers and customer base. To the best of our knowledge, every attempted exploitation of an Acquia customer has failed.



The scale and the severity of this attack suggests that if you failed to upgrade your Drupal sites, or your site is not supported by Acquia Cloud or another trusted vendor that provides platform level fixes, the chances of your site being hacked are very high. If you haven't upgraded your site yet, we recommend you do so as soon as possible, in addition to verifying that you haven't been compromised.

Drupal's responsible disclosure policy

It's important to keep in mind that all software has security bugs, and fortunately for Drupal, critical security bugs are rare. It's been nearly four years since the Drupal Security Team published a security release for Drupal core that is this critical.

What matters is how software projects or software vendors deal with security bugs. The Drupal Security Team follows a "coordinated disclosure policy": issues remain private until there is a published fix. A public announcement is made when the threat has been addressed and a secure version of Drupal core is also available. Even when a bug fix is made available, the Drupal Security Team is very thoughtful with its communication. The team is careful to withhold as many details about the vulnerability as possible to make it difficult for hackers to create an exploit, and to buy Drupal site owners as much time as possible to upgrade. In this case, Drupal site owners had two weeks before the first public exploits appeared.

Historically, many proprietary CMS vendors have executed a different approach, and don't always disclose security bugs. Instead, they often fix bugs silently. In this scenario, secrecy might sound like a good idea; it prevents sites from being hacked and it avoids bad PR. However, hiding vulnerabilities provides a false sense of security, which can make matters much worse. This approach also functions under the assumption that hackers can't find security problems on their own. They can, and when they do, even more sites are at risk of being compromised.

Drupal's approach to security is best-in-class — from fixing the bug, testing the solution, providing advance notice, coordinating the release, being thoughtful not to over communicate too many details, being available for press inquiries, and repeatedly reminding everyone to upgrade.

Acquia's platform level fix

In addition to the Drupal Security Team's responsible disclosure policy, Acquia's own security team has been closely monitoring attempted attacks on our infrastructure. Following the release of the Checkpoint Research article, Acquia has tracked the origin of the 500,000 attempted attacks:

This image captures the geographic distribution of SA-CORE-2018-002 attacks against Acquia's customers. The number denoted in each bubble is the total number of attacks that came from that location.

To date, over 50 percent of the attempted attacks Acquia has witnessed originate from the Ukraine:

At Acquia, we provide customers with automatic security patching of both infrastructure and Drupal code, in addition to platform level fixes for security bugs. Our commitment to keeping our customers safe is reflected in our push to release a platform level fix one hour after the Drupal Security Team made SA-CORE-2018-002 available. This mitigation covered all customers with Acquia Cloud Free, Acquia Cloud Professional, Acquia Cloud Enterprise, and Acquia Cloud Site Factory applications; giving our customers peace of mind while they upgraded their Drupal sites, with or without our help. This means that when attempted exploits and attacks first appeared in the wild, Acquia's customers were safe. As a best practice, Acquia always recommends that customers upgrade to the latest secure version of Drupal core, in addition to platform mitigations.

This blog post was co-authored by Dries Buytaert and Cash Williams.

Web Wash: Differentiate Websites using Environment Indicator in Drupal 8

Mar, 04/17/2018 - 12:00

As a web developer, you probably build your sites first in a local environment (aka localhost), then you commit all your changes to a staging server (i.e. an online server to which only you or the development team has access) and if everything works fine in the staging server, you’ll commit these changes to a production or live server (that’s your online site).

However, you don’t have a way to differentiate between your local, your staging and your production environments apart from the address box of your browser, so it’s very easy to mix up everything and that could lead to complications. The worst case scenario is making changes directly to your live site without testing and breaking it. In order to prevent this, you can use the Environment Indicator module.

The Environment Indicator module adds a visual hint to your site, that way you’ll always be aware of the environment you’re working on. We’re going to cover installation and usage of this module in this tutorial.

Let’s start!

Manifesto: Create conversational experiences with the Chatbot API for Drupal 8

Mar, 04/17/2018 - 09:07
This is my second post based on the talk I delivered at DrupalCamp London 2018: “Hi user, I am Drupal. How can I help you?” In the first post I looked at some of the scenarios in which chatbots and personal assistants might be used to beneficially serve website content to your audiences and briefly. Continue reading...

Electric Citizen: Electric Citizen and DrupalCon Nashville

Mar, 04/17/2018 - 08:30
Nashville Music City Center, a world-class venue

DrupalCon Nashville is in the history books and it was a doozy. The whole team was able to attend a stellar week of learning, sharing our hard-earned knowledge, and networking–interspersed with plenty of fun social events.

Seasoned Drupalers know that DrupalCon is a lot more than a tech conference. It is the community event of the year; a place to meet old friends and new, a celebration, and a barometer of the health of the Drupal platform itself–something we are collectively invested in. Attendees converged from far and wide to be part of it, to contribute, to engage, to learn and share, and to support our chosen technology.

As attendees, sponsors and presenters, Electric Citizen was fully in the mix this year. Read more in this blog post, or on our Twitter, LinkedIn and Facebook channels.

OPTASY: Artificial Intelligence Consulting: What Are the Typical Activities?

Mar, 04/17/2018 - 06:44
Artificial Intelligence Consulting: What Are the Typical Activities? adriana.cacoveanu Tue, 04/17/2018 - 09:44

So, you've (finally) overcome your skepticism regarding it: artificial intelligence does have the potential to propel your business right into the future! To drive productivity, enhance efficiency and flexibility and, overall, to transform your brand from the ground up. But how do you know what AI technology to go with? What are the AI use cases perfectly suited for your own business? And this is where artificial intelligence consulting comes in!

An AI consultant/AI consulting company's role is precisely that of answering all your questions and pointing out to you the right AI approach, the AI-powered solution(s) suitable for your own business:
 

Sooper Drupal Themes: How To Use Blocks And Custom Blocks In Drupal 8 | 8 Days To Drupal 8 | Day 2

Mar, 04/17/2018 - 06:34

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

Drupal 8 block management and drag and drop block video tutorial

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

Block Administration And Placement In Drupal 8

Same as in Drupal 7, Drupal 8 blocks are placed in regions from the blocks administration page, which is located at Structure > Block layout. A notable improvement in Drupal 8 is that you can now place the same block in different regions. For example: previously it was impossible to put a block in the sidebar on the blog section of your website and at the top of the masthead in another section of your website.

When placing a block in Drupal 8 you're offered block visibility settings that are familiar to people who have experience with Drupal 7. You limit visibility based on content type, paths, and user roles. Third party modules can extend this in Drupal 8, in the video below you see that the Webform module lets you place blocks whenever specific webfoms are showing. 

The Drupal 8 Blocks Administration Page

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

Custom Content Blocks In Drupal 8

To those familiar with Drupal 7: Drupal 8 lets you make new blocks and enter custom text or HTML. Except it's better. In the old system custom blocks were neutered content, without support for revisions, permissions, or custom block types.

In Drupal 8 blocks are proper first class citizens and support revisioning and custom block types. Basically Drupal 8 does with blocks what we did with the BEAN module in our Drupal 7 theme installation profiles. That's one less contrib module you'll need in Drupal 8! In our Drupal themes' demo installation profiles we offer "Basic Blocks" and "Drag and drop blocks" The latter option will let you design blocks with our front-end visual page builder.

Placing Blocks With Our Visual Page Builder Glazed Builder  Glazed Builder lets you place any Drupal block with our visual drag and drop module. The only blocks that will be missing from the blocks tab are views blocks. This is because we treat all views displays equally and put them under the Views tab. Here you will find every single views display, including Master displays. Moreover we allow you to override some useful views parameters, like pager settings, pager offset, exposed filters, and contextual filters. This is very powerful and you can use Glazed Builder to make news portal layouts, magazine layouts, and even personalized user dashboards. Creating A Footer Block In Drupal 8 I made a little video showing the complete process of creating a footer block in Drupal 8, you probably already found it at the top of this page. We start by adding a simple Copyright notice block using Drupal's native CKEditor. Then we show how you can build a 3 column footer easily with our frontend visual page builder. With Glazed Builder you can add any Drupal blocks and views in the footer, as well as all the standard drag and drop elements, and the extendable suite of HTML snippets in the Glazed Builder sidebar. If you add a drag and drop block to any region in your theme, you can view, edit, and save the block on any page where the blocks shows. It's very convenient and easy to get used to. Glazed Builder handles multiple blocks per page, automatically saves new revisions, and is also language aware.

Deeson: Warden release 1.3.0

Mar, 04/17/2018 - 06:07

At the end of March we released the next version of Warden, our open source solution that allows in-house development teams and agencies to keep track of the status of multiple Drupal sites hosted on different platforms. Release 1.3.0 contained the following changes:

  • Added Slack notification for sites on the dashboard
  • Logging request information from Drupal sites
  • Sorting the list of modules
Slack notifications.

This new feature provides a notification command which enables Warden to send details of the sites that need updating (those that are shown in the dashboard) to Slack.

In order to use this, a webhook needs to be set up within your Slack account to send notifications to a specific channel of your choice. Once this has been set up, the webhook URL can be added to the parameters settings within the Warden application (which will be asked for when running composer install after updating the application or can manually be added to the app/config/parameters.yml file to add it post install).

The notification can then be triggered using cron to generate the details and send them to the relevant Slack channel using the following command:

php app/console deeson:warden:dashboard-send-notification --type=slack Logging requests from Drupal sites.

This new feature shows a list of log requests that Warden makes to your Drupal sites. This enables users to be able to see when requests started failing, and will report on a relevant reason (depending upon what is returned from the request).

When viewing a site, there is an additional item in the ‘Actions’ list as well as a link next to the last successful request date time.

This provides a list in reverse chronological order of the requests that have been made to the site, highlighting which ones have failed. This helps users to be able to see when a sites started failing and potentially why.

Sorting the list of modules.

This update adds some additional functionality to the module listing page. By default, this page is sorted by the most used modules first, which is great for understanding how the modules are used, but not so great if you are trying to find a particular module.

With this update, this list can be sorted by module name as well as the number of sites that are using a module. This can be done by clicking on the table header to change the type of sorting that the table is displayed in.

Are you using Warden successfully? What else does the tool need? Come and let us know on our GitHub issues listing page.

Valuebound: Drupal highly critical vulnerability SA-CORE-2018–002 - We've got you covered

Mar, 04/17/2018 - 04:23

This blog post attempts to focus on the highly critical vulnerability that was announced by Drupal on 28th March tagged as SA-CORE-2018–002, Drupalgeddon 2.

Recently, Drupal core announced a security advisory rated as highly vulnerable - dubbed DrupalGeddon 2 (SA-CORE-2018-002 / CVE-2018-7600) - that has the potential to affect the vast majority of Drupal 6, 7 and 8 websites.

According to BuiltWith, around 9% of websites are running on Drupal and hence had a high probability of being affected by the vulnerability as the score is 24/25.

Páginas