Drupal Planet

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

3 months 3 weeks ago
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: 

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

3 months 3 weeks ago

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

Lullabot: Decoupled Drupal Summit at DrupalCon Nashville

3 months 3 weeks ago

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

3 months 3 weeks ago
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

3 months 3 weeks ago
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

3 months 3 weeks ago
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

3 months 3 weeks ago

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

3 months 3 weeks ago

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!

Electric Citizen: Electric Citizen and DrupalCon Nashville

3 months 3 weeks ago
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?

3 months 3 weeks ago
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

3 months 3 weeks ago

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

3 months 3 weeks ago

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

3 months 3 weeks ago

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.

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

3 months 3 weeks ago

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.

Dries Buytaert: State of Drupal presentation (April 2018)

3 months 3 weeks ago
© Yes Moon

Last week, I shared my State of Drupal presentation at Drupalcon Nashville. In addition to sharing my slides, I wanted to provide more information on how you can participate in the various initiatives presented in my keynote, such as growing Drupal adoption or evolving our community values and principles.

Drupal 8 update

During the first portion of my presentation, I provided an overview of Drupal 8 updates. Last month, the Drupal community celebrated an important milestone with the successful release of Drupal 8.5, which ships with improved features for content creators, site builders, and developers.

Drupal 8 continues to gain momentum, as the number of Drupal 8 sites has grown 51 percent year-over-year:

This graph depicts the number of Drupal 8 sites built since April 2015. Last year there were 159,000 sites and this year there are 241,000 sites, representing a 51% increase year-over-year.

Drupal 8's module ecosystem is also maturing quickly, as 81 percent more Drupal 8 modules have become stable in the past year:

This graph depicts the number of modules now stable since January 2016. This time last year there were 1,028 stable projects and this year there are 1,860 stable projects, representing an 81% increase year-over-year.

As you can see from the Drupal 8 roadmap, improving the ease of use for content creators remains our top priority:

This roadmap depicts Drupal 8.5, 8.6, and 8.7+, along with a column for "wishlist" items that are not yet formally slotted. The contents of this roadmap can be found at https://www.drupal.org/core/roadmap.
Four ways to grow Drupal adoption

Drupal 8 was released at the end of 2015, which means our community has had over two years of real-world experience with Drupal 8. It was time to take a step back and assess additional growth initiatives based on what we have learned so far.

In an effort to better understand the biggest hurdles facing Drupal adoption, we interviewed over 150 individuals around the world that hold different roles within the community. We talked to Drupal front-end and back-end developers, contributors, trainers, agency owners, vendors that sell Drupal to customers, end users, and more. Based on their feedback, we established four goals to help accelerate Drupal adoption.

Goal 1: Improve the technical evaluation process

Matthew Grasmick recently completed an exercise in which he assessed the technical evaluator experience of four different PHP frameworks, and discovered that Drupal required the most steps to install. Having a good technical evaluator experience is critical, as it has a direct impact on adoption rates.

To improve the Drupal evaluation process, we've proposed the following initiatives:

Initiative Issue link Stakeholders Initiative coordinator Status Better discovery experience on Drupal.org Drupal.org roadmap Drupal Association hestenet Under active development Better "getting started" documentation #2956879 Documentation Working Group grasmash In planning More modern administration experience #2957457 Core contributors ckrina and yoroy Under active development

To become involved with one of these initiatives, click on its "Issue link" in the table above. This will take you to Drupal.org, where you can contribute by sharing your ideas or lending your expertise to move an initiative forward.

Goal 2: Improve the content creator experience

Throughout the interview process, it became clear that ease of use is a feature now expected of all technology. For Drupal, this means improving the content creator experience through a modern administration user interface, drag-and-drop media management and page building, and improved site preview functionality.

The good news is that all of these features are already under development through the Media, Workflow, Layout and JavaScript Modernization initiatives.

Most of these initiative teams meet weekly on Drupal Slack (see the meetings calendar), which gives community members an opportunity to meet team members, receive information on current goals and priorities, and volunteer to contribute code, testing, design, communications, and more.

Goal 3: Improve the site builder experience

Our research also showed that to improve the site builder experience, we should focus on improving the three following areas:

  • The configuration management capabilities in core need to support more common use cases out-of-the-box.
  • Composer and Drupal core should be better integrated to empower site builders to manage dependencies and keep Drupal sites up-to-date.
  • We should provide a longer grace period between required core updates so development teams have more time to prepare, test, and upgrade their Drupal sites after each new minor Drupal release.

We plan to make all of these aspects easier for site builders through the following initiatives:

Initiative Issue link Stakeholders Initiative coordinator Status Composer & Core #2958021 Core contributors + Drupal Association Coordinator needed! Proposed Config Management 2.0 #2957423 Core contributors Coordinator needed! Proposed Security LTS 2909665 Core committers + Drupal Security Team + Drupal Association Core committers and Security team Proposed, under discussion Goal 4: Promote Drupal to non-technical decision makers

The fourth initiative is unique as it will help our community to better communicate the value of Drupal to the non-technical decision makers. Today, marketing executives and content creators often influence the decision behind what CMS an organization will use. However, many of these individuals are not familiar with Drupal or are discouraged by the misconception that Drupal is primarily for developers.

With these challenges in mind, the Drupal Association has launched the Promote Drupal Initiative. This initiative will include building stronger marketing and branding, demos, events, and public relations resources that digital agencies and local associations can use to promote Drupal. The Drupal Association has set a goal of fundraising $100,000 to support this initiative, including the hiring of a marketing coordinator.

Megan Sanicki and her team have already raised $54,000 from over 30 agencies and 5 individual sponsors in only 4 days. Clearly this initiative resonates with Drupal agencies. Please consider how you or your organization can contribute.

Fostering community with values and principles

This year at DrupalCon Nashville, over 3,000 people traveled to the Music City to collaborate, learn, and connect with one another. It's at events like DrupalCon where the impact of our community becomes tangible for many. It also serves as an important reminder that while Drupal has grown a great deal since the early days, the work needed to scale our community is never done.

Prompted by feedback from our community, I have spent the past five months trying to better establish the Drupal community's principles and values. I have shared an "alpha" version of Drupal's values and principles at https://www.drupal.org/about/values-and-principles. As a next step, I will be drafting a charter for a new working group that will be responsible for maintaining and improving our values and principles. In the meantime, I invite every community member to provide feedback in the issue queue of the Drupal governance project.

An overview of Drupal's values with supporting principles.

I believe that taking time to highlight community members that exemplify each principle can make the proposed framework more accessible. That is why it was very meaningful for me to spotlight three Drupal community members that demonstrate these principles.

Principle 1: Optimize for Impact - Rebecca Pilcher

Rebecca shares a remarkable story about Drupal's impact on her Type 1 diabetes diagnosis:

Principle 5: Everyone has something to contribute - Mike Lamb

Mike explains why Pfizer contributes millions to Drupal:

Principle 6: Choose to Lead - Mark Conroy

Mark tells the story of his own Drupal journey, and how his experience inspired him to help other community members:

Watch the keynote or download my slides

In addition to the community spotlights, you can also watch a recording of my keynote (starting at 19:25), or you can download a copy of my slides (164 MB).

Checked
1 week 2 days ago
Drupal.org - aggregated feeds in category Planet Drupal
Subscribe to Drupal Planet feed