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.
  • DrupalCamp London

    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

  • Has Drupal 8 Usage Hit a Tipping Point?

    The following blog was written by Drupal Association Premium Technology Partner, Lingotek.

    It wasn’t a question of if, but a question of when and the Drupal.org weekly usage statistics are showing it’s happening now. Usage of Lingotek’s Drupal 8 Module finally caught up to and exceeded that of Drupal 7. Is this the tipping point? Is the community finally making the switch to the latest Drupal module?

    The Drupal.org Usage Statistics for Lingotek Translation provides information about the usage of the Lingotek Translation project--Lingotek - Inside Drupal 7 Module and the Lingotek - Inside Drupal 8 Module--with summaries across all versions and details for each release. It shows the week and the number of sites that reported using a given version of the project.

    The usage figures reflect the number of sites using the project/item that week. The results can give an idea of how popular the different projects are and may help users choose modules and themes for their own sites. The figures are an indicator of which modules are being used. Note: Only Drupal websites using the Update Status module are included in the data.

    In the past 6 months, the Drupal.org weekly statistics showed Drupal 7 usage was still going strong. There were twice as many users using the Drupal 7 version in April, May, June, July, August, and September. But starting in October, Drupal 8 usage began to tick upward. In the first week, only 269 reported using the D8 version. Then the momentum quickly shifted. By the second week of October, they were almost equal with 441 users of Drupal 7 and 420 using Drupal 8; they were a scant 19 users apart. Then came the tipping point.

    In the third week of October, Drupal 8 usage overtook that of Drupal 7. In a huge turnaround, 772 reported using Drupal 8 when compared to only 447 using Drupal 7.

    Since then, the gap narrowed somewhat, but regained a solid lead once again in early November with 894 D8 users and 416 using the D7 version. We’re predicting the lead is here to stay. The tipping point was inevitable.

    The support is likely the result of the growing need for localized content. Multilingual web content is critical to engage a global audience that wants to search, shop, and buy in their own language. The Drupal 8 version, with its built in multilingual capability, makes it easier than ever to create content for a global audience. The module supports translation of any content and configuration, including:

    • Content entities - nodes, comments, messages, taxonomy terms and even paragraphs (including nested ones)
    • Configuration entities - fields, blocks, taxonomy vocabularies, views, fields, etc.
    • Configuration items - site name, system emails, etc.

    The Lingotek - Inside Drupal Module is the only Drupal module to integrate a Translation Management System directly into Drupal, allowing the Drupal community to use professional-grade translation technologies (e.g. machine translation, translation memory, CAT tool) without ever leaving the Drupal environment. It is built on Drupal's standard multilingual modules (Locale, content translation, entity translation, internationalization, etc.) and helps Drupal administrators, agencies, and web marketers get a Drupal site multilingual-ready within minutes, instead of days.

    Many Drupal users have strong opinions about which is better--Drupal 7 or Drupal 8, but one thing is clear: Drupal 8 is the future. The level of innovation and improved functionality available in each new release will be hard to ignore. These usage statistics reflect that the community has begun wholesale migration to Drupal 8 and that we’ve finally reached the tipping point.

  • Happy seventeenth birthday Drupal

    This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

    Seventeen years ago today, I open-sourced the software behind Drop.org and released Drupal 1.0.0. When Drupal was first founded, Google was in its infancy, the mobile web didn't exist, and JavaScript was a very unpopular word among developers.

    Over the course of the past seventeen years, I've witnessed the nature of the web change and countless internet trends come and go. As we celebrate Drupal's birthday, I'm proud to say it's one of the few content management systems that has stayed relevant for this long.

    While the course of my career has evolved, Drupal has always remained a constant. It's what inspires me every day, and the impact that Drupal continues to make energizes me. Millions of people around the globe depend on Drupal to deliver their business, mission and purpose. Looking at the Drupal users in the video below gives me goosebumps.

    Drupal's success is not only marked by the organizations it supports, but also by our community that makes the project more than just the software. While there were hurdles in 2017, there were plenty of milestones, too:

    • At least 190,000 sites running Drupal 8, up from 105,000 sites in January 2016 (80% year over year growth)
    • 1,597 stable modules for Drupal 8, up from 810 in January 2016 (95% year over year growth)
    • 4,941 DrupalCon attendees in 2017
    • 41 DrupalCamps held in 16 different countries in the world
    • 7,240 individual code contributors, a 28% increase compared to 2016
    • 889 organizations that contributed code, a 26% increase compared to 2016
    • 13+ million visitors to Drupal.org in 2017
    • 76,374 instance hours for running automated tests (the equivalent of almost 9 years of continuous testing in one year)

    Since Drupal 1.0.0 was released, our community's ability to challenge the status quo, embrace evolution and remain resilient has never faltered. 2018 will be a big year for Drupal as we will continue to tackle important initiatives that not only improve Drupal's ease of use and maintenance, but also to propel Drupal into new markets. No matter the challenge, I'm confident that the spirit and passion of our community will continue to grow Drupal for many birthdays to come.

    Tonight, we're going to celebrate Drupal's birthday with a warm skillet chocolate chip cookie topped with vanilla ice cream. Drupal loves chocolate! ;-)

    Note: The video was created by Acquia, but it is freely available for anyone to use when selling or promoting Drupal.