Drupal News

Drupal News

Come for the software, stay for the community Drupal is an open source content management platform powering millions of websites and applications. It’s built, used, and supported by an active and diverse community of people around the world.
  • Drupal 8.5.0-rc1 is available for testing

    The first release candidate for the upcoming Drupal 8.5.0 release is now available for testing. Drupal 8.5.0 is expected to be released March 7.

    8.5.x makes the Media module available for all, improves migrations significantly, stabilizes the Content Moderation and Settings Tray modules, serves dynamic pages faster with BigPipe enabled by default, and introduces the new experimental Layout Builder module. The release includes several very important fixes for workflows of content translations and supports PHP 7.2. Finally, 8.5.0-rc1 also includes the same security updates that are provided in 8.4.5.

    What does this mean to me?

    For Drupal 8 site owners

    Drupal 8.4.5, a security update and the final release of the 8.4.x series, has also been released this week. 8.4.x sites should update immediately to 8.4.5, but going forward, 8.4.x will receive no further releases following 8.5.0's release date, and sites should prepare to update from 8.4.x to 8.5.x in order to continue getting bug and security fixes. Use update.php to update your 8.4.x sites to the 8.5.x series, just as you would to update from (e.g.) 8.4.2 to 8.4.3. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

    If you're an early tester who is already running 8.5.0-alpha1 or 8.5.0-beta1, you should update to 8.5.0-rc1 immediately. 8.5.0-rc1 includes security fixes (the same fixes that were released in Drupal 8.4.5).

    Site owners should also take note of the fact that Drupal 8's support for PHP 5 will end in one year, in March 2019. PHP 7.2 is now the best recommended PHP version to use with Drupal 8.

    For module and theme authors

    Drupal 8.5.x is backwards-compatible with 8.4.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.5.x, and test modules and themes with the release candidate now.

    For translators

    Some text changes were made since Drupal 8.4.0. Localize.drupal.org automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

    For core developers

    All outstanding issues filed against 8.4.x were automatically migrated to 8.5.x. Future bug reports should be targeted against the 8.5.x branch. 8.6.x will remain open for new development during the 8.5.x release candidate phase. The 8.5.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.

    Your bug reports help make Drupal better!

    Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

  • Drupal core - Critical - Multiple Vulnerabilities - SA-CORE-2018-001

    Project: 
    Version: 
    8.4.x-dev
    7.x-dev
    Date: 
    2018-February-21
    Vulnerability: 
    Multiple Vulnerabilities
    Description: 

    This security advisory fixes multiple vulnerabilities in both Drupal 7 and Drupal 8. See below for a list.

    Comment reply form allows access to restricted content - Critical - Drupal 8 - CVE-2017-6926

    Users with permission to post comments are able to view content and comments they do not have access to, and are also able to add comments to this content.

    This vulnerability is mitigated by the fact that the comment system must be enabled and the attacker must have permission to post comments.

    JavaScript cross-site scripting prevention is incomplete - Critical - Drupal 7 and Drupal 8 - CVE-2017-6927

    Drupal has a Drupal.checkPlain() JavaScript function which is used to escape potentially dangerous text before outputting it to HTML (as JavaScript output does not typically go through Twig autoescaping). This function does not correctly handle all methods of injecting malicious HTML, leading to a cross-site scripting vulnerability under certain circumstances.

    The PHP functions which Drupal provides for HTML escaping are not affected.

    Private file access bypass - Moderately Critical - Drupal 7 - CVE-2017-6928

    When using Drupal's private file system, Drupal will check to make sure a user has access to a file before allowing the user to view or download it. This check fails under certain conditions in which one module is trying to grant access to the file and another is trying to deny it, leading to an access bypass vulnerability.

    This vulnerability is mitigated by the fact that it only occurs for unusual site configurations.

    jQuery vulnerability with untrusted domains - Moderately Critical - Drupal 7 - CVE-2017-6929

    A jQuery cross site scripting vulnerability is present when making Ajax requests to untrusted domains. This vulnerability is mitigated by the fact that it requires contributed or custom modules in order to exploit.

    For Drupal 8, this vulnerability was already fixed in Drupal 8.4.0 in the Drupal core upgrade to jQuery 3. For Drupal 7, it is fixed in the current release (Drupal 7.57) for jQuery 1.4.4 (the version that ships with Drupal 7 core) as well as for other newer versions of jQuery that might be used on the site, for example using the jQuery Update module.

    Language fallback can be incorrect on multilingual sites with node access restrictions - Moderately Critical - Drupal 8 - CVE-2017-6930

    When using node access controls with a multilingual site, Drupal marks the untranslated version of a node as the default fallback for access queries. This fallback is used for languages that do not yet have a translated version of the created node. This can result in an access bypass vulnerability.

    This issue is mitigated by the fact that it only applies to sites that a) use the Content Translation module; and b) use a node access module such as Domain Access which implement hook_node_access_records().

    Note that the update will mark the node access tables as needing a rebuild, which will take a long time on sites with a large number of nodes.

    Settings Tray access bypass - Moderately Critical - Drupal 8 - CVE-2017-6931

    The Settings Tray module has a vulnerability that allows users to update certain data that they do not have the permissions for.

    If you have implemented a Settings Tray form in contrib or a custom module, the correct access checks should be added. This release fixes the only two implementations in core, but does not harden against other such bypasses.

    This vulnerability can be mitigated by disabling the Settings Tray module.

    External link injection on 404 pages when linking to the current page - Less Critical - Drupal 7 - CVE-2017-6932

    Drupal core has an external link injection vulnerability when the language switcher block is used. A similar vulnerability exists in various custom and contributed modules. This vulnerability could allow an attacker to trick users into unwillingly navigating to an external site.

    Solution: 

    Install the latest version:

    Reported By: 
    • Comment reply form allows access to restricted content - Critical - Drupal 8

    • JavaScript cross-site scripting prevention is incomplete - Critical - Drupal 7 and Drupal 8)

    • Private file access bypass - Moderately Critical - Drupal 7

    • jQuery vulnerability with untrusted domains - Moderately Critical - Drupal 7

    • Language fallback can be incorrect on multilingual sites with node access restrictions - Moderately Critical - Drupal 8

    • Settings Tray access bypass - Moderately Critical - Drupal 8

    • External link injection on 404 pages when linking to the current page - Less Critical - Drupal 7

    Fixed By: 
  • DrupalCamp London 2-4 Mar'18

    The following blog was written by Drupal Association Premium Supporting Partner, DrupalCamp London.

    The people surrounding Drupal have always been one of its strongest selling points; hence the motto “Come for the code, stay for the community”. We bring individuals from a multitude of backgrounds and skill sets together to push forward towards a common goal whilst supporting and helping each other. Within the community, there are a number of ways to connect to each other; both online and in person. A good way to meet in person is by attending DrupalCons and DrupalCamps.

    DrupalCamps

    A DrupalCamp can be similar to a DrupalCon but is on a much smaller scale. Where a ‘Con has 1,600+ attendees a ‘Camp ranges anywhere from 50-600 people. In Europe alone there were over 50 camps in 2017, including DrupalCamp London.

    DrupalCamp London

    DrupalCamp London brings together hundreds of people from across the globe who use, develop, design, and support the Drupal platform. It’s a chance for Drupalers from all backgrounds to meet, discuss, and engage in the Drupal community and project. DrupalCamp London is the biggest camp in Europe (followed very closely by Kiev), at ~600 people over three days. Due to its size and location, we’re able to run a wide range of sessions, keynotes, BoFs, Sprints, and activities to take part in.

    What happens over the three days?

    Friday (CxO day)

    Friday (CxO day) is primarily aimed at business leaders who provide or make use of Drupal services (i.e web development agencies, training companies, clients etc), but naturally, everyone is welcome. Throughout the day we'll have speakers talking about their experiences working with Drupal and Open Source technologies in their sector(s) or personal life. With a hot food buffet for lunch and a free drinks reception at the end of the day, you'll also have ample time to network with the other attendees.

    Benefits of attending 

    Benefits for CTOs, CMOs, COOs, CEOs, Technical Directors, Marketing Directors and Senior Decision Makers: 

    • Understand how leading organisations leverage the many benefits of Drupal
    • Network with similar organisations in your sector
    • Learn directly from thought leaders via specific case studies

    Saturday/Sunday (Weekend event)

    Over the weekend, we have 3 Keynote speakers, a choice of over 40 sessions to attend, BoF (Birds of a Feather) talks, Sprints, great lunch provided (both days) and a Saturday social. With all the activity there is something for everyone to get involved in.

    Benefits of attending 

    Networking 

    Over 500 people attended the weekend event last year and we are expecting it to grow even more this year. Not all attendees are devs either, with a fair share of managers, designers, C-Level, and UX leads there's a great opportunity for all skill sets to interact with each other. Big brands use Drupal (MTV, Visit England, Royal.gov, Guardian, Twitter, Disney) and this is a chance to meet with people from those companies to compare notes, and learn from each other. 

    Recruitment

    As above, the chance to meet so many people from various skill sets is a great way to line up potential interviews and hires for any aspect of your business. At the very least you'll be able to meet interesting people for any future potential hires. 

    Marketing & Raising company profile 

    Attending an event with a huge turnout is a great way to meet people and talk to them about what you and your company do. Embedding your name within the tight-knit Drupal community can attract the attention of other companies. Sponsoring the camp means that your logo and additional information can be seen around the camp, in tote bags given to attendees, and online. The social and sponsors stands are the perfect chance to talk to other companies and people attending DrupalCamp, to find out how they use Drupal for their benefit. 

    Learning 

    DrupalCamp isn't just for Devs, over the weekend there are sessions on a broad range of topics including community & business, UX, and general site building/using Drupal. The technical topics aren’t just Drupal specific either, this gives developers (and others) the ability to learn more about general core coding concepts and methodologies. The methods and techniques learnt help with day to day development and long-term work. In addition to the planned sessions, BoF (birds of a feather) sessions, there are ad-hoc get-togethers where people can talk on any topic, allowing a free discussion to share ideas. 

    Warm fuzzy feeling/giving back 

    Drupal (like any open source software) wouldn't survive without the community. Camps and other events allow the members to come together and see ‘first hand’ that they’re giving back to a community that helps power their tech, maintains their interests, and enables them to make a living.

    How to get involved?

    It’s easy to get involved with DrupalCamp London, check us out on Twitter for updates and you can find out more about the event and buy tickets on our website.

  • Dries Buytaert Shares His View on Decoupled Drupal: When, Why, and How

    More and more developers are choosing content-as-a-service solutions known as decoupled CMSes, and due to this trend, people are asking whether decoupled CMSes are challenging the market for traditional CMSes.

    By nature, decoupled CMSes lack end-user front ends, provide few to no editorial tools for display and layout, and as such leave presentational concerns almost entirely up to the front-end developer. Luckily, Drupal has one crucial advantage that propels it beyond these concerns of emerging decoupled competitors.

    Join Dries Buytaert, founder of Drupal and CTO at Acquia, as he shares his knowledge on how Drupal has an advantage over competitors, and discusses his point-of-view on why, when, and how you should implement decoupled Drupal.

    Dries will touch on:

    • His thoughts on decoupled CMSes - where is the CMS market headed and when?
    • His opinion on whether decoupled CMSes will replace traditional CMSes
    • The advantages of decoupled Drupal vs. emerging decoupled competitors
    • Considerations when determining if decoupled Drupal is right for your project

    Click here to watch the webinar.


    Dries Buytaert

    CHAIRMAN, CHIEF TECHNOLOGY OFFICERACQUIA, INC.

    Dries Buytaert is an open source developer and technology executive. He is the original creator and project lead for Drupal, an open source platform for building websites and digital experiences. Buytaert is also co-founder and chief technology officer of Acquia, a venture-backed technology company. Acquia provides an open cloud platform to many large organizations, which helps them build, deliver and optimize digital experiences. A Young Global Leader at the World Economic Forum, he holds a PhD in computer science and engineering from Ghent University and a Licentiate Computer Science (MsC) from the University of Antwerp. He was named CTO of the Year by the Massachusetts Technology Leadership Council, New England Entrepreneur of the Year by Ernst & Young, and a Young Innovator by MIT Technology Review. He blogs frequently on Drupalopen sourcestartupsbusiness, and the future at dri.es.

    LinkedIn

    Twitter


    https://www.acquia.com/resources/webinars/dries-buytaert-shares-his-view-decoupled-drupal-when-why-and-how?cid=7010c000002ZXDSAA4&ct=online-advertising&ls=drupalorg&lls=pro_us_ola_drupalorg_q12018

  • Creating a Living Style Guide with Open Social

    The following blog was written by Drupal Association Signature Supporting Partner, Open Social by GoalGorilla.

    A living style guide - a way to control markup or CSS - has been making a name for itself. And for a good reason; they’re an important tool for web development. They keep developers in sync, communicate design standards, and help organize complex interfaces. In this post, I want to discuss how and why living style guides are important and how to implement one for Open Social using Drupal for software.

    We're using a living style guide because it serves as a valuable internal resource for development; we’re able to write reusable and consistent code that's easy to maintain. And it’s a great external resource for client deliverables. Ready to see how to make a living style guide work with Drupal software? Let’s go!

    Moving From Static to Dynamic

    We didn’t always rely on a living style guide. Open Social was built and maintained using different strategies such as component libraries and atomic designs. These strategies have advantages, such as reusability, facilitating collaboration within the team, and ensuring design consistency. There were, however, disadvantages to a static style of working.

    In the past, a component library or style guide was usually graphic-based. The designer would create a visual representation of a component (in PS or Sketch, for example) and then the front-end developer would transfer these visuals to HTML and CSS. This immediately meant double maintenance; for instance, if the markup or CSS changes, the graphics style guide would need to be updated to reflect this change and vice-versa. In our experience, the shelf life of these “static” systems is only a few iterations before the graphic version gets left behind and forgotten due to too much maintenance and not enough return. Yikes.

    This is why we decided that it was time for a change. What we needed what a more dynamic system: a living style guide.

    A Living Style Guide Is the Best

    Any style guide is better than none but a living style guide is the best.

    A living style guide consists of a single source of code, thankfully. The style guide’s markup, javascript, and CSS are the same as what was used in production. This provides a wide array of benefits. See below!

    • Sharing design capabilities. Our team easily shares design capabilities between designers and front-end developers, which also benefits the backend developers and project managers who work with us.
    • Less reliance on other team members. The developers refer to the style guide and reuse components for new features without being heavily reliant on the designers and front-end developers for implementation.
    • Most importantly, the client benefits. The project manager offers new feature ideas and lower-cost solutions to the client, based on reusing and recombining existing components. Inevitably our clients benefit from this, especially when they begin thinking this way themselves.

    While this blog post focuses on how we work on Open Social enterprise projects, it is also an accurate reflection of working in the Drupal frontend nowadays. A quick google for “Drupal Living Style Guide” can give you some ideas about the current popularity, challenges, and general atmosphere surrounding the subject. In the next section of the blog, I will take you through the steps of setting up a living style guide with Open Social.

    Creating the Living Style Guide

    It’s important to note that this section assumes you have a copy of the Open Social distribution running locally on your development machine (here’s where you can install the Open Social distro if you’re looking for it).

    This demonstration uses a copy of the Social Blue theme, but you can implement the style guide using any custom theme. The Social Blue theme ships with the KSS style guide. Once we have the style guide up and running, the final result will look like this. Here we go!

    Side note: refer to this GitHub repo for an example of a component library within a Drupal theme folder structure, and package.json with dependencies, gulpfile.js for run KSSnode style guide and generate assets for the Drupal theme.

    The Drupal Component Library Module and Twig Namespaces

    The living style guide firstly requires the Component Library Drupal module to get up and running. The Drupal components library allows us to create custom twig namespaced paths. This means we are not limited to placing our components in the Drupal theme templates folder (as the current Drupal 8 architecture dictates).

    The KSS style guide lives in our theme directory but has no knowledge of Drupal. This is what makes it so flexible. In theory, we can copy the component library directory and use it in other (non-Drupal) projects. A big thanks to John Albin, the maintainer of Zen Theme and KSS node, for paving the way for us to implement our theme and style guide.

    In this demonstration, a namespace was created in the theme’s .info.yml file, just like this:

    (More documentation is available on the module’s drupal.org project page)

    Once the namespace has been defined, you can include and extend twig templates from the component library, Drupal’s template override files and other components (like in an atomic design approach) by simply referring to the files like this:

    Social Blue comes with the style guide ready to go (read the Social Blue readme and follow the instructions on how to create a custom theme from it). However, because we have copied this to our custom theme folder, the gulpfile that runs the different tasks needs to be updated to reflect the new location in relation to the base theme (socialbase).

    Read the Social Blue readme and follow the instructions to create your own custom theme. Once you have updated the package.json file and the gulpfile.js with those provided in Lisa's demo repo, refer to the Social Blue readme again, and follow instructions under the heading “Working with Gulp”. These steps will install the theme’s dependencies.

    Compiling the Style Guide

    Basically, most of the action happens in the gulpfile. Spending some time reading its comments and exploring it really helps you understand the dynamics of linking a Drupal theme with a living style guide.

    If we refer to the package.json, we will see which packages we have installed, and by examining the gulp tasks and configuration, we can get a sense of how the style guide is compiled from our component library and theme files.

    The Theory

    We are relying on Drupal's theme layer to render the twig files from our components and attach the libraries (our CSS and js). We also rely on the component module to create the namespace allowing us to map Drupal variables with the json variables in our style guide.

    The style guide copies Drupal’s theme assets (CSS and js) and has its own twig compiler (see os-builder folder).

    The end result is the style guide made up of CSS/js copied from the base theme’s assets folder, our theme’s assets folder, and HTML generated from the twig and json, from our component library. The CSS/js copied from the assets folders need to be included in the gulpfile to be copied into your style guide.

    (Side note: a nice little improvement is to have a designated folder, therefore avoiding the need to list each file.)

    The Drupal HTML pages and the style guides are not shared. This is important to point out because caching might affect each differently.

    Conceptually, we are dealing with 3 layers.

    1. Drupal core
    2. SocialBase component library (as CSS/js already compiled) and Drupal templates (handled by Drupal’s theme layer)
    3. Custom theme extending base component library and drupal template

    The style guide isn’t a layer because it doesn’t know Drupal exists beyond sharing the files in the component library directory. This concept illustrates one of the powerful elements of a dynamic component library - you can copy it from project to project, regardless of the environment, because in the end, all it really is is HTML, CSS, and javascript (see image below).


    Diagram of how a component library, KSSNode style guide, and Drupal theme work together to make a living style guide

    In Conclusion...

    For front-end developers and designers, a living style guide is becoming an essential part of the web developer’s toolkit.

    We are able to focus on the implementation of design components while the backend is being built, thus working in parallel with our team members instead of relying on others to finish before we can start.

    We can do browser and accessibility tests on a component level, thus improving the quality of features (current and future). Another benefit (one that deserves a blog post on its own) is implementing visual regression testing on the living style guide to help spot changes in HTML or CSS negatively affecting existing elements.

    The time investment needed, especially for a complex project, is nothing compared to the peace of mind knowing adding new elements does not break others.

    What you need to know:

    Written by Lisa Corcoran