Drupal Feeds

Drupal is a great platform that has a great community and a great number of sites developed thanks to it. What makes it so great? What helps Drupal stand out among the competition? We’ve explained you 6 reasons why you'll love Drupal websites, and if you do love them and have your own website on Drupal now, then this article will give you a hint about what you should pay attention to stand out among your business competitors and defeat them.

Read more
Drupal Modules: The One Percent — Link Attributes Widget (video tutorial) NonProfit Tue, 09/12/2017 - 10:15 Episode 35

Here is where we seek to bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll investigate Link Attributes Widget, a module which extends core's link field formatter, allowing you add attributes through the UI.

Drupal 8 Learning Series: 2. Disable Cache in a Devel Environment Leander Lindahl Tue, 09/12/2017 - 19:04

I had a very strange problem wherein I was not able to affect variables being passed to views-view-grid--my_view.html.twig.

A Developer’s Impact on Implementing an Accessible Web A Developer’s Impact on Implementing an Accessible Web Anthony Simone Tue, 09/12/2017 - 21:30

Creating accessible web applications can initially be quite a daunting task. Whether you’re working on a project that needs to be compliant with law or not, it can be hard to figure out what is most important to focus on. There’s ADA Compliance, WCAG 2.0 Compliance, and 508 Compliance, and navigating the technical differences between them all can end up taking more time than simply focusing on building accessible applications in the first place.

All three of the above types of compliance have different histories and different rules about the types of websites, web applications, or organizations they affect, however, at their core, they all are trying to accomplish the same thing: Make an accessible web.

Accessibility

So then what is accessibility? From a developer’s point of view, this can be a difficult question to answer when initially delving into the subject matter. Digging through documents related to the compliance patterns can be complicated, especially if your main concern is ensuring you pass compliance by any of the above definitions.

It can be easy to lose sight of the purpose of implementing an accessible web when trying to sift through the regulations. The goal is to make your application usable by everyone! Despite the somewhat complicated language around some of these compliance patterns, the WCAG 2 At a Glance page gives a good general baseline of what to consider. It breaks accessibility down into 4 general requirements: perceivable, operable, understandable, robust.

Perceivable

  • Provide text alternatives for non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
  • Provide captions and other alternatives for multimedia.
  • Create content that can be presented in different ways,
  • including by assistive technologies, without losing meaning.
  • Make it easier for users to see and hear content.

Operable

  • Make all functionality available from a keyboard.
  • Give users enough time to read and use content.
  • Do not use content that causes seizures.
  • Help users navigate and find content.

Understandable

  • Make text readable and understandable.
  • Make content appear and operate in predictable ways.
  • Help users avoid and correct mistakes.

Robust  

  • Maximize compatibility with current and future user tools.

 

Maintaining the highest grade of AAA compliance will grow your audience, protect you from any future litigation, and provide equal access for Americans with disabilities.  

Ultimately, the intention is quite simple. Everyone should be able to use, access, and consume the content of your website. If this is the governing principle you use when planning a new web project, you’ll definitely be successful building an accessible web application.

Know Your Audiences

Accessibility considerations affect a wide variety of audiences. Understanding how these different audiences use the internet can give a great amount of insight into what a developer can accomplish.

There are two general groups of users we want to consider: users with some amount of vision impairment and users with some range of mobility issues. (Note: this is not to discount other groups that are specifically covered under some of the compliance documents. In this article, we are going to cover some best practices that a developer can implement while building a site, as opposed to considerations that may come up during UX or design like contrast issues, UI implementations, and more.)

Both of these groups of users are unique. If we look deeper at each of these cases, we’ll learn more about how they are interacting with the websites we build.

Motor Impairment

Internet users that experience some amount of motor impairment are generally using different means of navigating the internet than the traditional keyboard and mouse/trackpad. Users may not be able to manipulate a mouse and instead, only use a keyboard. Inversely, they may not be able to use a traditional keyboard but use an alternate interface to interact with a website. Some people’s motor ability may limit them to using a small number of keys.

The big takeaway from the motor impairment user group is that web navigation must be clear, straightforward and possible with just a keyboard. Try this, go about some everyday tasks on the internet only using your keyboard. You’ll immediately start to notice websites that have or have not taken accessibility into account.

Visual Impairment

Users with some degree of visual impairment will typically consume data on a web page differently. This can vary widely on a case by case scenario, but users may increase the font size, they may rely on descriptive copy to understand the contents of images, and they may rely on a screen reader to translate all visual content into auditory content on a webpage.

The big takeaway here is that content of a web page is consumed in many different ways. Appropriate markup and theming goes a long way for someone using a screenreader. If you are on a mac, you can go to System Preferences > Accessibility and turn voiceover on, then use command + F5 to enable it. Try it out!

It’s important to keep in mind that many users employ a combination of features from both user categories. Which means these accessibility features are important for all device types, not just a desktop sized experience.

Where to Start?

If at all possible, start at the beginning! Accessibility shouldn’t be treated like browser testing and ignored until QA at the end of a project. By then, you’ll likely have a lot of work ahead of you. If you’re considering all of this functionality as you are planning elements like menus, sliders, tabs, accordions, or other functional components that either help with navigation or display content, then you can start with an appropriate implementation from the beginning. This lets you plan your features and components appropriately within the context of accessibility instead of having to build around them later.

The following list of considerations is a great place to start when planning for accessibility on a new project or going through an old project to test functionality.

Focus Ring

All browsers have a default style associated with items that have focus, like links and buttons. As a general rule, you should not remove this. Or, if you are modifying it, make sure the replacement style is very obvious and easy to identify.

 

 

A user who is navigating your website with a keyboard relies on focus styles to know where their current context is within the webpage. Without that they would be totally lost, it would be like using a mouse with an invisible cursor.

Menus

Menus are one of the most important components on many websites. They allow you to navigate through the whole web application. Top priority with menu implementation is ensuring all links can be accessed with the keyboard, specifically the tab key.

Visibility / Display

It’s important to know what a screen reader recognizes as an item in the flow, and what it doesn’t. Though some screen readers may have specific behavior, the general rule is that elements with display: none; or visibility: hidden; are ignored by screen readers. Generally, content that is off screen, but not hidden in either of the above ways is considered an element in the flow by a screen reader. It’s important to know the difference because it can be used to make the experience better, and misuse can create a keyboard navigation nightmare.

A good rule of thumb is anything that shouldn’t be visible by a user using a keyboard and mouse should likely be hidden in one of the above ways. For example, if there is a menu that slides into place from off screen after you’ve scrolled down the page a certain amount. If this item isn’t explicitly hidden, someone navigating with tabs may have to go through all of the items they can’t see before they reach the real content.

Note: the visibility property can be transitioned, whereas, the display property cannot. This may come in handy when implementing transitions!

Skip Link

A useful convention for keyboard navigation users is the implement a “skip link.” The idea is that the very first time you click tab on a page, it focuses on a previously hidden link, that when clicked, will move your focus to the main content of the page. Drupal has a default implementation of this out of the box, but depending on your site structure, some extra customization might be appropriate. The following is an example of a snippet you can use for skip link functionality.

var $skipLinkHolder = $('#skip-to-content'),
  $skipLink = $skipLinkHolder.find('.skip-to-content-link');

$skipLink.on('click', function(e) {
    e.preventDefault();
    var $target = $($(this).attr('href'));
    $target.attr('tabindex', '-1');
    $target.focus();
    $target.on('blur focusout', function() {
        $(this).removeAttr('tabindex');
    });
});

You can also take advantage of the fact that offscreen items can be focused here by positioning it off screen but giving it different styles on focus.

Tab Order

It’s important to be aware of actual DOM markup source order and tab order. Too often, we position things absolutely or fixed and neglect the actual source order of the element. This can cause confusing scenarios when navigating a website by tabbing. It is important to ensure absolute and fixed position items are placed reasonably in the DOM with respect to a tab user's arrival upon them. The page can go a long way to make tab navigation more straightforward.

ARIA / Functional Components / Existing Tools

ARIA is a specification that handles adding more descriptive, contextual information to elements that can be used by screen readers to give the users extra context. ARIA can get a little bit confusing. Generally, there isn’t a huge amount of documentation around it, and it’s a spec describing purpose but not the implementation of these tags. So, different screen readers can potentially have some different behavior. Rolling your own functional component can be a pretty complicated endeavor when accessibility is taken into account. Fortunately, there are a lot of great existing tools backed by fairly large communities that can get you pretty far if you’re willing to leverage them.

Many tools and frameworks have accessibility baked in. It’s worth taking a look at what’s available before deciding to roll your own for some established types of functionality, like menus, tabs, accordions, etc. Foundation is a great tool that is very flexible regarding implementation. The majority of its components support accessibility very well, specifically the menus, accordions, and tabs components. They are a great option to use as a starter, and you can potentially use them for their markup, js, and ARIA support and do your own completely custom theme implementation over top.

Some popular solutions for problems like better multi selects already exist with ARIA and accessibility considerations (Select2 and Selectize). Though they might not all be perfect, leveraging existing tools and communities can be a great help. Because we don’t all have first-hand access to groups of users who use assistive technologies, this is an essential tool when implementing accessible web applications.

Conclusion

We learned about specific ways a developer can take responsibility for web accessibility. The responsibility of building an accessible web goes far beyond the developers during implementation, but there’s a lot that a developer can do on their own. The many layers of compliance and rules notwithstanding, taking some time to learn who your users are and how they’re using the web gives us the opportunity to build solutions that are accessible to as many people as possible.

 

Hello, Drupal Community! Our team has prepared two BoFs for DrupalCon Vienna.

 

Drupal and a higher education: we invite Drupal experts and higher education representatives to see what problems a higher education wants to solve with the help of Drupal and how it can be done in practice. 

The BoF details

 

Marketing challenges: promoting and selling Drupal services, building the company image and communicating with a target audience are the hard processes. Specialists of all the categories are welcome to share the typical challenges and propose the solutions.

The BoF details

Last year, Matthew Tift and I examined Drupal.org's commit data to understand who develops Drupal, how much of that work is sponsored, and where that sponsorship comes from. We published our analysis in a blog post called "Who Sponsors Drupal Development?". A year later, I wanted to present an update. This year’s report will also cover additional data, including gender and geographical diversity, and project sponsorship.

Understanding how an open-source project works is important because it establishes a benchmark for project health and scalability. Scaling an open-source project is a difficult task. As an open-source project’s rate of adoption grows, the number of people that benefit from the project also increases. Often the open-source project also becomes more complex as it expands, which means that the economic reward of helping to improve the project decreases.

A recent article on the Bitcoin and Ethereum contributor communities illustrates this disparity perfectly. Ethereum and Bitcoin have market capitalizations valued at $30 billion and $70 billion, respectively. However, both projects have fewer than 40 meaningful contributors, and contribution isn’t growing despite the rising popularity of cryptocurrency.

According to Bitcoin's GitHub data, Bitcoin has less than 40 active contributors.According to Ethereum's GitHub data, Ethereum has less than 20 active contributors.

Drupal, by comparison, has a diverse community of contributors. In the 12-month period between July 1, 2016 to June 30, 2017 we saw code contributions on Drupal.org from 7,240 different individuals and 889 different companies. This does not mean that Drupal is exempt from the challenges of scaling an open-source project. We hope that this report provides transparency about Drupal project development and encourages more individuals and organizations incentive to contribute. We also will highlight areas where our community can and should do better.

What is the Drupal.org credit system?

In the spring of 2015, after proposing ideas for giving credit and discussing various approaches at length, Drupal.org added the ability for people to attribute their work to an organization or customer in the Drupal.org issue queues. Maintainers of Drupal modules, themes and distributions can award issues credits to people who help resolve issues with code, translations, documentation, design and more.

A screenshot of an issue comment on Drupal.org. You can see that jamadar worked on this patch as a volunteer, but also as part of his day job working for TATA Consultancy Services on behalf of their customer, Pfizer.

Credits are a powerful motivator for both individuals and organizations. Accumulating credits provides individuals with a way to showcase their expertise. Organizations can utilize credits to help recruit developers or to increase their visibility in the Drupal.org marketplace.

While the benefits are evident, it is important to note a few of the limitations in Drupal.org’s current credit system:

  • Contributing to issues on Drupal.org is not the only way to contribute. Other activities, such as sponsoring events, promoting Drupal, and providing help and mentorship, are important to the long-term health of the Drupal project. Many of these activities are not currently captured by the credit system. For this post, we chose to only look at code contributions.
  • We acknowledge that parts of Drupal are developed on GitHub and therefore aren't fully credited on Drupal.org. The actual number of contributions and contributors could be significantly higher than what we report.
  • Even when development is done on Drupal.org, the credit system is not used consistently; because using the credit system is optional, a lot of code committed on Drupal.org has no or incomplete contribution credits.
  • Not all code credits are the same. We currently don't have a way to account for the complexity and quality of contributions; one person might have worked several weeks for just one credit, while another person might receive a credit for ten minutes of work. In the future, we should consider issuing credit data in conjunction with issue priority, patch size, etc. We can also reduce the need for trivial credits by automating patch rerolls and automating coding style fixes.
Who is working on Drupal?

For our analysis we looked at all the issues that were marked "closed" or "fixed" in the 12-month period from July 1, 2016 to June 30, 2017. What we learned is that there were 23,238 issues marked "closed" or "fixed", a 22% increase from the 19,095 issues in the 2015-2016 period. Those 23,238 issues had 42,449 issue credits, a 30% increase from the 32,711 issue credits recorded in the previous year. Issue credits against Drupal core remained roughly the same year over year, meaning almost all of this growth came from increased activity in contributed projects. This is no surprise. Drupal development is cyclical, and during this period of the Drupal 8 development cycle, most of the Drupal community has been focused on porting modules from Drupal 7 to Drupal 8. Of the 42,449 issue credits reported this year, 20% (8,619 credits) were for Drupal core, while 80% (33,830 credits) went to contributed themes, modules and distributions.

Compared to the previous year, we also saw an increase in both the number of people contributing and the number of organizations contributing. Drupal.org received code contributions from 7,240 different individuals and 889 different organizations.

The number of individual contributors is up 28% year over year and the number of organizations contributing is up 26% year over year.

While the number of individual contributors rose, a relatively small number of individuals still do the majority of the work. Approximately 47% of individual contributors received just one credit. Meanwhile, the top 30 contributors (the top 0.4%) account for over 17% of the total credits, indicating that these individuals put an incredible amount of time and effort in developing Drupal and its contributed projects:

RankUsernameIssues1jrockowitz5372dawehner4213RenatoG4084bojanz3515Berdir3356mglaman3347Wim Leers3328alexpott3299DamienMcKenna24510jhodgdon24211drunken monkey23812naveenvalecha19613Munavijayalakshmi19214borisson_19115yongt941218916klausi18517Sam15218418miro_dietiker18219Pavan B S18020ajay_reddy17621phenaproxima17222sanchiz16223slashrsm16124jhedstrom15525xjm15126catch14727larowlan14528rakesh.gectcr14129benjy13930dhruveshdtripathi138

Out of the top 30 contributors featured, 19 were also recognized as top contributors in our 2015-2016 report. These Drupalists’ dedication and continued contribution to the project has been crucial to Drupal’s development. It’s also exciting to see 11 new names on the list. This mobility is a testament to the community’s evolution and growth.

Next, we looked at both the gender and geographic diversity of Drupal.org code contributors. While these are only two examples of diversity, this is the only available data that contributors can choose to share on their Drupal.org profiles. The reported data shows that only 6% of the recorded contributions were made by contributors that identify as female, which indicates a steep gender gap. Like in most open-source projects, the gender imbalance in Drupal is profound and underscores the need to continue fostering diversity and inclusion in our community.

The gender representation behind the issue credits. When measuring geographic diversity, we saw individual contributors from 6 different continents and 116 different countries: The top 20 countries from which contributions originate. The data is compiled by aggregating the countries of all individual contributors behind each commit. Note that the geographical location of contributors doesn't always correspond with the origin of their sponsorship. Wim Leers, for example, works from Belgium, but his funding comes from Acquia, which has the majority of its customers in North America.How much of the work is sponsored?

Drupal is used by more than one million websites. The vast majority of the individuals and organizations behind these Drupal websites never participate in the development of the project. They might use the software as it is or might not feel the need to help drive its development. We have to provide more incentive for these individuals and organizations to contribute back to the project.

Issue credits can be marked as "volunteer" and "sponsored" simultaneously (shown in jamadar's screenshot near the top of this post). This could be the case when a contributor does the minimum required work to satisfy the customer's need, in addition to using their spare time to add extra functionality.

While Drupal started out as a 100% volunteer-driven project, today the majority of the code on Drupal.org is sponsored by organizations. Only 11% of the commit credits that we examined in 2016-2017 were "purely volunteer" credits (4,498 credits), in stark contrast to the 46% that were "purely sponsored". In other words, there were four times as many "purely sponsored" credits as "purely volunteer" credits.

A few comparisons with the 2015-2016 data:

  • The credit system is used more. Between July 1, 2015 and June 30, 2016, 37% of all credits had no attribution while in the more recent period between July 1, 2016 to June 30, 2017, only 28% of credits lacked attribution. More people have become aware of the credit system, the attribution options, and their benefits.
  • Sponsored credits are growing faster than volunteer credits. Both "purely volunteer" and "purely sponsored" credits grew, but "purely sponsored" credits grew faster. There are two reasons why this could be the case: (1) more contributions are sponsored and (2) organizations are more likely to use the credit system compared to volunteers.

No data is perfect, but it feels safe to conclude that most of the work on Drupal is sponsored. At the same time, the data shows that volunteer contribution remains very important to Drupal. Maybe most importantly, while the number of volunteers and sponsors has grown year over year in absolute terms, sponsored contributions appear to be growing faster than volunteer contributions. This is consistent with how open source projects grow and scale.

Who is sponsoring the work?

Now that we have established that most of the work on Drupal is sponsored, we want to study which organizations contribute to Drupal. While 889 different organizations contributed to Drupal, approximately 50% of them received four credits or fewer. The top 30 organizations (roughly the top 3%) account for about 48% of the total credits, which implies that the top 30 companies play a crucial role in the health of the Drupal project. The graph below shows the top 30 organizations and the number of credits they received between July 1, 2016 and June 30, 2017:

While not immediately obvious from the graph above, different types of companies are active in Drupal's ecosystem:

Category Description Traditional Drupal businesses Small-to-medium-sized professional services companies that make money primarily using Drupal. They typically employ fewer than 100 employees, and because they specialize in Drupal, many of these professional services companies contribute frequently and are a huge part of our community. Examples are Chapter Three (shown on graph) and Lullabot (shown on graph). Digital marketing agencies Larger full-service agencies that have marketing-led practices using a variety of tools, typically including Drupal, Adobe Experience Manager, Sitecore, WordPress, etc. They tend to be larger, with the larger agencies employing thousands of people. Examples are Wunderman and Mirum. System integrators Larger companies that specialize in bringing together different technologies into one solution. Example system agencies are Accenture, TATA Consultancy Services, Capgemini and CI&T. Technology and infrastructure companies Examples are Acquia (shown on graph), Lingotek, BlackMesh, Rackspace, Pantheon and Platform.sh. End-users Examples are Pfizer (shown on graph) or NBCUniversal.

A few observations:

  • Almost all of the sponsors in the top 30 are traditional Drupal businesses. Companies like MD Systems (12 employees), Valuebound (34 employees), Chapter Three (27 employees), Commerce Guys (7 employees) and PreviousNext (20 employees) are, despite their size, critical to Drupal's success.

    It's worth highlighting MD Systems, which ranks second in the list of the top 30 contributing organizations, and is the number-one contributor among traditional Drupal businesses. What distinguishes MD Systems from most others is that it has embedded contribution into its corporate philosophy. For every commercial project, MD Systems invests 20% of that project’s value back into Drupal. They believe that using commercial projects as the foundation for community contribution leads to more meaningful and healthier contributions for Drupal and a lower total cost of ownership for their customers. This is different from other organizations, where employees are allotted a number of hours per month to contribute outside of customer-facing projects. There is no denying that MD Systems has had a tremendous impact on the Drupal community with contributions that are both frequent and impactful.

  • Compared to these traditional Drupal businesses, Acquia has nearly 800 employees and several full-time Drupal contributors. Acquia’s Office of the CTO (OCTO) works to resolve some of the most complex issues on Drupal.org, many of which are not recognized by the credit system (e.g. release management, communication, sprint organizing, and project coordination). However, I believe that Acquia should contribute even more due to our comparative size.
  • No digital marketing agencies show up in the top 30, though some of them are starting to contribute. It is exciting that an increasing number of digital marketing agencies are delivering beautiful experiences using Drupal. As a community, we need to work to ensure that each of these firms are contributing back to the project with the same commitment that we see from firms like Chapter Three, MD Systems or CI&T.
  • The only system integrator in the top 30 is CI&T, which ranked 6th with 664 credits. As far as system integrators are concerned, CI&T is a smaller player with approximately 2,500 employees. However, we do see various system integrators outside of the top 30, including Globant, Capgemini, Sapient and TATA Consultancy Services. Each of these system integrators reported 30 to 70 credits in the past year. Finally, Wipro began contributing this year with 2 credits. We expect, or hope, to see system integrators contribute more and more, especially given the number of Drupal developers they employ. Many have sizable Drupal practices with hundreds of Drupal developers, yet contributing to open source is relatively new and often not well-understood.
  • Infrastructure and software companies play an important role in our community, yet only Acquia appears in the top 30. While Acquia has a professional services division, 75% of the contributions come from the product organization (including the Office of the CTO and the Acquia Lightning team). Other contributing infrastructure companies include Pantheon and Platform.sh, which are both venture-backed platform-as-a-service companies that originated from the Drupal community. Pantheon has 17 credits and Platform.sh has 47 credits. Amazee Labs, who is building an infrastructure business, reported 51 credits. Rackspace is a public company hosting thousands of Drupal sites; they have 48 credits. Lingotek offers cloud-based translation management software and has 94 credits.
  • We saw two end-users in the top 30 corporate sponsors: Pfizer (251 credits, up from 158 credits the year before) and the German company bio.logis (212 credits). Other notable customers outside of the top 30 were Workday, Wolters Kluwer, Burda Media, University of Colorado Boulder, YMCA and OpenY, CARD.com and NBCUniversal.
Sponsored code contributions to Drupal.org from technology and infrastructure companies. The chart does not reflect sponsored code contributions on GitHub, Drupal event sponsorship, and the many forms of value that these companies add to Drupal and other open-source communities.

We can conclude that technology and infrastructure companies, digital marketing agencies, system integrators and end-users are not meaningfully contributing code to Drupal.org today. How can we explain this disparity in comparison to traditional Drupal businesses who contribute the most? We believe the biggest reasons are:

  1. Drupal's strategic importance. A variety of the traditional Drupal agencies have been involved with Drupal for 10 years and almost entirely depend on Drupal to support their business. Given both their expertise and dependence on Drupal, they are most likely to look after Drupal's development and well-being. These organizations are typically recognized as Drupal experts and are sought out by organizations that want to build a Drupal website. Contrast this with most of the digital marketing agencies and system integrators who are sized to work with a diversified portfolio of content management platforms and who are historically only getting started with Drupal and open source. They deliver digital marketing solutions and aren't necessarily sought out for their Drupal expertise. As their Drupal practices grow in size and importance, this could change. In fact, contributing to Drupal can help grow their Drupal business because it helps their name stand out as Drupal experts and gives them a competitive edge with their customers.
  2. The level of experience with Drupal and open source. Drupal aside, many organizations have little or no experience with open source, so it is important that we motivate and teach them to contribute.
  3. Legal reservations. We recognize that some organizations are not legally permitted to contribute, let alone attribute their customers. We hope that will change as open source continues to get adopted.
  4. Tools and process barriers. Drupal contribution still involves a patch-based workflow on Drupal.org's unique issue queue system. This presents a fairly steep learning curve to most developers, who primarily work with more modern and common tools such as GitHub. Getting the code change proposal uploaded is just the first step; getting code changes accepted into an upstream Drupal project — especially Drupal core — is hard work. Peer reviews, gates such as automated testing and documentation, required sign-offs from maintainers and committers, knowledge of best practices and other community norms are a few of the challenges a contributor must face to get code accepted into Drupal.

Consequently, this data shows that the Drupal community can do more to entice companies to contribute code to Drupal.org. The Drupal community has a long tradition of encouraging organizations to share code rather than keep it behind firewalls. While the spirit of the Drupal project cannot be reduced to any single ideology — not every organization can or will share their code — we would like to see organizations continue to prioritize collaboration over individual ownership. Our aim is not to criticize those who do not contribute, but rather to help foster an environment worthy of contribution. Given the vast amount of Drupal users, we believe continuing to encourage organizations and end-users to contribute could be a big opportunity.

There are substantial benefits and business drivers for organizations that contribute: (1) it improves their ability to sell and win deals and (2) it improves their ability to hire. Companies that contribute to Drupal tend to promote their contributions in RFPs and sales pitches. Contributing to Drupal also results in being recognized as a great place to work for Drupal experts.

The uneasy alliance with corporate contributions

As mentioned above, when community-driven open-source projects grow, there is a bigger need for organizations to help drive their development. It almost always creates an uneasy alliance between volunteers and corporations.

This theory played out in the Linux community well before it played out in the Drupal community. The Linux project is 25 years old and has seen a steady increase in the number of corporate contributors for roughly 20 years. While Linux companies like Red Hat and SUSE rank high on the contribution list, so do non-Linux-centric companies such as Samsung, Intel, Oracle and Google. All of these corporate contributors are (or were) using Linux as an integral part of their business.

The 889 organizations that contribute to Drupal (which includes corporations) is more than four times the number of organizations that sponsor development of the Linux kernel. This is significant because Linux is considered "one of the largest cooperative software projects ever attempted". In fairness, Linux has a different ecosystem than Drupal. The Linux business ecosystem has various large organizations (Red Hat, Google, Intel, IBM and SUSE) for whom Linux is very strategic. As a result, many of them employ dozens of full-time Linux contributors and invest millions of dollars in Linux each year.

What projects have sponsors?

In total, the Drupal community worked on 3,183 different projects (modules, themes and distributions) in the 12-month period between July 1, 2016 to June 30, 2017. To understand where the organizations sponsoring Drupal put their money, I’ve listed the top 20 most sponsored projects:

RankUsernameIssues1Drupal core47452Drupal Commerce (distribution)5263Webform3614Open Y (distribution)3245Paragraphs2316Inmail2237User guide2188JSON API2049Paragraphs collection20010Entity browser19611Diff19012Group17013Metatag15714Facets15515Commerce Point of Sale (PoS)14716Search API14317Open Social (distribution)13318Drupal voor Gemeenten (distribution)13119Solr Search12220Geolocation field118
Who is sponsoring the top 30 contributors? Rank Username Issues Volunteer Sponsored Not specified Sponsors 1 jrockowitz 537 88% 45% 9% The Big Blue House (239), Kennesaw State University (6), Memorial Sloan Kettering Cancer Center (4) 2 dawehner 421 67% 83% 5% Chapter Three (328), Tag1 Consulting (19), Drupal Association (12), Acquia (5), Comm-press (1) 3 RenatoG 408 0% 100% 0% CI&T (408) 4 bojanz 351 0% 95% 5% Commerce Guys (335), Adapt A/S (38), Bluespark (2) 5 Berdir 335 0% 93% 7% MD Systems (310), Acquia (7) 6 mglaman 334 3% 97% 1% Commerce Guys (319), Thinkbean, LLC (48), LivePerson, Inc (46), Bluespark (22), Universal Music Group (16), Gaggle.net, Inc. (3), Bluehorn Digital (1) 7 Wim Leers 332 14% 87% 2% Acquia (290) 8 alexpott 329 7% 99% 1% Chapter Three (326), TES Global (1) 9 DamienMcKenna 245 2% 95% 4% Mediacurrent (232) 10 jhodgdon 242 0% 1% 99% Drupal Association (2), Poplar ProductivityWare (2) 11 drunken monkey 238 95% 11% 1% Acquia (17), Vizala (8), Wunder Group (1), Sunlime IT Services GmbH (1) 12 naveenvalecha 196 74% 55% 1% Acquia (152), Google Summer of Code (7), QED42 (1) 13 Munavijayalakshmi 192 0% 100% 0% Valuebound (192) 14 borisson_ 191 66% 39% 22% Dazzle (70), Acquia (6) 15 yongt9412 189 0% 97% 3% MD Systems (183), Acquia (6) 16 klausi 185 9% 61% 32% epiqo (112) 17 Sam152 184 59% 92% 7% PreviousNext (168), amaysim Australia Ltd. (5), Code Drop (2) 18 miro_dietiker 182 0% 99% 1% MD Systems (181) 19 Pavan B S 180 0% 98% 2% Valuebound (177) 20 ajay_reddy 176 100% 99% 0% Valuebound (180), Drupal Bangalore Community (154) 21 phenaproxima 172 0% 99% 1% Acquia (170) 22 sanchiz 162 0% 99% 1% Drupal Ukraine Community (107), Vinzon (101), FFW (60), Open Y (52) 23 slashrsm 161 6% 95% 3% MD Systems (153), Acquia (47) 24 jhedstrom 155 4% 92% 4% Phase2 (143), Workday, Inc. (134), Memorial Sloan Kettering Cancer Center (1) 25 xjm 151 0% 91% 9% Acquia (137) 26 catch 147 3% 83% 16% Third and Grove (116), Tag1 Consulting (6) 27 larowlan 145 12% 92% 7% PreviousNext (133), University of Technology, Sydney (30), amaysim Australia Ltd. (6), Australian Competition and Consumer Commission (ACCC) (1), Department of Justice & Regulation, Victoria (1) 28 rakesh.gectcr 141 100% 91% 0% Valuebound (128) 29 benjy 139 0% 94% 6% PreviousNext (129), Brisbane City Council (8), Code Drop (1) 30 dhruveshdtripathi 138 15% 100% 0% DevsAdda (138), OpenSense Labs (44)

We observe that the top 30 contributors are sponsored by 46 organizations. This kind of diversity is aligned with our desire not to see Drupal controlled by a single organization. These top contributors and organizations are from many different parts of the world and work with customers large and small. Nonetheless, we will continue to benefit from more diversity.

Evolving the credit system

Like Drupal itself, the credit system on Drupal.org is an evolving tool. Ultimately, the credit system will only be useful when the community uses it, understands its shortcomings, and suggests constructive improvements. In highlighting the organizations that sponsor the development of code on Drupal.org, we hope to elicit responses that help evolve the credit system into something that incentivizes business to sponsor more work and enables more people to participate in our community, learn from others, teach newcomers and make positive contributions. Drupal is a positive force for change and we wish to use the credit system to highlight (at least some of) the work of our diverse community, which includes volunteers, companies, nonprofits, governments, schools, universities, individuals, and other groups.

One of the challenges with the existing credit system is it has no way of "weighting" contributions. A typo fix counts just as much as giving multiple detailed technical reviews on a critical core issue. This appears to have the effect of incentivizing organizations' employees to work on "lower-hanging fruit issues", because this bumps their companies' names in the rankings. One way to help address this might be to adjust the credit ranking algorithm to consider things such as issue priority, patch size, and so on. This could help incentivize companies to work on larger and more important problems and save coding standards improvements for new contributor sprints. Implementing a scoring system that ranks the complexity of an issue would also allow us to develop more accurate reports of contributed work.

Conclusion

Our data confirms Drupal is a vibrant community full of contributors who are constantly evolving and improving the software. While we have amazing geographic diversity, we need greater gender diversity. Our analysis of the Drupal.org credit data concludes that most contributions to Drupal are sponsored. At the same time, the data shows that volunteer contribution remains very important to Drupal.

As a community, we need to understand that a healthy open-source ecosystem includes more than traditional Drupal businesses that contribute the most. For example, we don't see a lot of contribution from the larger digital marketing agencies, system integrators, technology companies, or end-users of Drupal — we believe that might come as these organizations build out their Drupal practices and Drupal becomes more strategic for them.

To grow and sustain Drupal, we should support those that contribute to Drupal and find ways to get those that are not contributing involved in our community. We invite you to help us continue to strengthen our ecosystem.

Special thanks to Tim Lehnen and Neil Drumm from the Drupal Association for providing us with the Drupal.org credit system data and for supporting us during our research. I would also like to extend a special thanks to Matthew Tift for helping to lay the foundation for this research, collaborating on last year’s blog post, and for reviewing this year’s edition. Finally, thanks to Angie Byron, Gábor Hojtsy, Jess (xjm), Preston So, Ted Bowman, Wim Leers and Gigi Anderson for providing feedback during the writing process.

With the Drupal Commerce 2.0 release slated for September 20th, we are making an effort to provide excellent documentation so that our implementers and end users can work with Drupal Commerce efficiently. We also want to encourage contribution at all levels, such as documentation. I am happy to announce we have moved from using Sphinx, a Restructured Text documentation tool, to GravCMS. GravCMS is a PHP based flat-file CMS, which uses Markdown.

Why the change?

We found that while Sphinx provided robust features, it also added a high entry barrier for documentation contributors:

Change is hard, but sometimes it's also for the better.

All platforms have their issues, and Drupal is no different. These quirks, known as Drupalisms, can be the source of many WTF moments for developers as the code or functionality does not work in a way they expected.

As Drupal leaves the island of doing things in its own way, one of the stowaways still onboard is user 1.

User 1 is the first Drupal user on a Drupal site with the user ID number of 1. User 1 is hardcoded to have all permissions; their access cannot be controlled through the administration interface. User 1 has all the site keys and has to be dealt with uniquely in code.

It’s time for us to kill user 1. 

In its place, all users will be treated in the same way using the standard roles and permissions model.

Key benefits

There are several benefits, some of them rather major:

Security improvement: Once a site has been built or has proper roles defined, you can take away the admin role from all users. This ensures there are no accounts that put your entire website at risk should they be compromised.

Code stability: I had to fix a few dozen tests because they relied on user 1 being special. The tests were not functioning meaning they were not actually covering the code they should have. Removing the UID1 Drupalism will ensure our tests need to run with the right permissions defined.

Consistency: What good is an access layer if there is a special exception that can bypass everything? An example of this being a downside is a bunch of administrative local tasks (tabs) or actions ("+"-icon links) being put behind sensible access checks, only to have all gazillion of them clutter the UI for user 1 because he has god-mode haxx turned on.

Reducing the number of Drupalisms: We need to distinguish between Drupalisms that define what Drupal is and those that negatively characterize Drupal by needlessly increasing its learning curve. The special case of UID1 belongs to the latter category. There are very few systems that still have god-mode accounts. And for good reason (see above items). So let's destroy yet another barrier for outside devs to join our project.

Summary

The issue to remove user 1 has been around since 2009, so the concept isn’t new. I resurrected the issue earlier this year and it seems to be building momentum now.

If this is something that interests you, then please head over to the issue queue, read the discussions and try out the patch: https://www.drupal.org/node/540008

Let’s get this into Drupal 8.5.x!

Interested in joining our team? Deeson is hiring!

As Drupal specialists, we’re proud to be the largest Acquia Certified team in Europe. And last month our development manager Mark Pavlitski became the first person in the UK to achieve Drupal 8 Grand Master status!

This special recognition is awarded to best of the best Drupal Developers, and requires the participant to pass three exams: Acquia Certified Developer, Back-end Specialist, and Front-end Specialist.

In this post, Mark shares his insights into the certification process.

The exams

I started with the Drupal 8 Developer test, which is more general than the subsequent two, and covers Drupal site building, theming, module development and fundamental web concepts. 

Then I sat the Drupal 8 Front-end Specialist exam which, as the name implies, is focussed on front-end development and Drupal theming concepts. I found this the most challenging of the three, having had more back-end experience. But most of the questions are written in a way that will be familiar to an experienced Drupal developer.

Finally, I sat the Drupal 8 Back end specialist exam. I found this one more straightforward, given my experience, though still challenging at times.

My tips for other developers

Acquia’s certification tests take place on Kryterion’s WebAssessor platform. Officially it supports Macs, but I found I had various issues with the software. Although their support was very helpful, I ended up switching to a Windows laptop to take the tests.

All of the questions are scenario based, describing a Drupal development problem with multiple choice answers. There were a couple of typos and one or two ambiguously worded questions, but overall the tests are presented in a way that will make sense to any seasoned Drupal developer.

The results

I was pleasantly surprised by how quickly the test results appear on the Acquia certification registry. The test portal says the results will take a couple of weeks to appear, but in my case it was as quick as a few hours.

Overall my experience with the Acquia Certification programme was great. The tests were well structured, and challenging but not confusing. I’d definitely recommend certification as a way for Drupal businesses and professionals to validate their skills and experience.

Want to be part of the largest Acquia Certified team in Europe and get paid time to support your open source projects? We’re hiring.

Building URL Aliases Based on Specific Conditions

Have you ever needed to generate URL aliases for an entity based on specific set of conditions? I was recently on a Drupal 8 project that needed the ability to generate custom URL aliases based on very specific criteria outlined by the client. Out of the box, Pathauto module was not flexible enough to handle the customization, but leveraging its API and providing my own hook implementation in a custom module allowed me to perform conditional checks on data and build the conditional URL structures.

How to allow an Editor Choose the View Mode of an Entity Reference Field in Drupal 8

Say you are building a website which has a 'Related Content' feature. Then say your client says something like "This is great, but all the related content looks like the teaser on the listing page. Can't we choose ourselves how we want it to look?" What's your response? You say yes, and you go install Display Suite or Panels or some other heavy duty module? Or, say yes and follow these neat little instructions. No one says no to clients, do they?

Here's what you need to do:

Share:

In this post, we will show the pain points of running Xdebug in a Docker local development environment and how we overcame them.

by nick.schuch / 15 September 2017

Xdebug is essential when it comes to local development.

Normally the hardest part about configuring Xdebug is setting the IP address which it should send its debugging data to (eg. PHPStorm).

Configuring this with Vagrant was very simple since we were able to use the following setting for it to "Just Work":

xdebug.remote_connect_back = 1

Remote Connect Back is awesome, it allows for Xdebug to send its debugger information back to the IP address making the web request, where PHPStorm is running.

However, running Xdebug with "Docker for Mac" (D4M) is hard. D4M runs over multiple networks:

  • OSX host
  • Linux VM

This means that the IP address Xdebug ends up sending data to is the IP address of the Linux VM.

Existing solutions in the Docker community usually end up with the developer running additional configuration that they have to manage:

eg. https://forums.docker.com/t/ip-address-for-xdebug/10460/21

To solve this we wrote a tool called "D4M TCP Forwarder", which receives requests being sent to a port on the D4M host and forwards them to the OSX users host IP.

https://github.com/nickschuch/d4m-tcp-forwarder

To add this to your project you simply add this service to your Docker Compose file:

xdebug: image: nickschuch/d4m-tcp-forwarder network_mode: host

The solution results in:

  • No configuration for a developer
  • Reusable solution for the community
Tagged Docker

Posted by nick.schuch
Sys Ops Lead

Dated 15 September 2017

Add new comment

Drupal 8’s “fruitful fields” of opportunities are endless — so let’s take another walk through them!

Read more

Features Module has played a significant role in deploying site configuration for Drupal 7. If you’ve ever build a site in Drupal 7, then possibly you have worked with the Features Module. However, CMI in Drupal 8 solved a lot of problems that we faced with Features in Drupal 7. In this blog, we will discuss - Why do we need Features Module in Drupal 8? What is the use of it? We will also attempt to export photo gallery feature.

Let’s take a use-case where you are working on a media and publishing company project and your client wants a feature of ‘…

A big thank you to all our CiviCON UK Sponsors. Here's a special post from Gold Sponsor Yoti:

Doing things differently: Registrations in seconds, logins without passwords and minimising data.

Over the last 15 years I’ve probably been responsible for around 50 or so websites or microsites that in some way or another have tried to gather people’s data.  Either to enter into an event, join a forum or buy something.  And like most other marketeers I’ve been obsessed by two things.  Funnels and Data. i.e how easily are people signing up and how much do I now know about my customers.  I’ve always known that by asking people for more information there was a danger people would drop out of my acquisition funnel but we marketeers are hungry for data. We want it all and we want it now.

I’ve now come to realise that less is more.  I still want the customers, and loads of them, but I want them to join me on their terms. If I ask people less about themselves I’m more likely to get an answer. 

I always try to liken marketing situations with personal situations.  When you first meet someone in a bar you don’t tend to ask them everything about themselves in the first sentence.  You might introduce yourself and ask them their name.  And perhaps ask them where they’re from.  You certainly wouldn’t ask their address or birthday.  If you did, you can be fairly sure they’d either not tell you or they’d give you a fake one and then avoid you for the rest of the night.  So why do we do it in business?  

So we can send them emails they’ll never read?  Send them mail that’ll clog up their recycling bin. Profiling our user base?  Most businesses can’t afford this kind of wastage.  We can’t afford to be sending emails that damage our brand by clogging up people’s inboxes or sending people mail that costs us thousands of pounds.  And just how much effective user profiling can be done if the data they are giving us isn't actually real in the first place?

I want to suggest a revolutionary new idea.  Why not just ask for less, just their first name? Or maybe, not even ask them anything at all. Imagine if you could give them access to a secure user profile on your website even though you didn't even have a name or email address for them.  And they could return to that profile whenever they want to tell you a bit more about themselves. Imagine if you could give them a special key to your world.

A special key?  What like a password?  Surely not...No, not like a password.  Just let them use their phone and their biometrics.  Let them then build their trust with you by adding more details when they want to.  When they need to.  Let them feel special by showing them all the awesome stuff they can now see that nobody else can, and then when you need their address to send them something they've bought you can ask for it.  You could even give them the option of giving you their phone number or email so you can tell them when you’ve got something new and cool to sell. Or you could just say ‘come and stop by whenever you fancy. You’ve got the keys and you can’t lose them so come and have a browse whenever you fancy it.’

It feels a little scary doesn't it? Having anonymous customers that are in control of what information they give you and when.  But there's also all sorts of other interesting stuff it means you could do. You can create chat forums where people just prove they are from a certain city but otherwise remain anonymous.  You could build web forums for children that only allowed people under a certain age or over another age to register.

However, I know there are plenty of us who do actually need all the data up front, just because that’s how business works and it may take a while for my utopian customer-centric world to exist.  And plenty of businesses need to be absolutely sure they have the right name and address to eliminate fraud that’s costing us billions of pounds every year.

But these businesses still want to get people signed up quickly and they’re still scared about getting their data hacked.  And a lot of businesses do end up giving their customers passwords, which their customers usually forget.

We created Yoti to try and let people and businesses do all of the above. We want to encourage businesses to ask for less, but give you the confidence people are who they claim to be.  We want to make it frictionless for you to sign up new verified customers. We don't want anyone to ever hate your website just because they forgot their password.

Yoti is an easy to use digital identity app for consumers and secure digital identity attribute exchange platform for organisations. Our phones help us connect, make payments and board planes, it’s time that they helped us prove our identity.

People create their Yoti by downloading our free app, prove they’re a real person and match their selfie to their passport or driving licence photo. In less than 5 minutes, out pops their verified digital identity that they control for life. Yoti uses AES 256 encryption to store and share user data in such a way that only they have access to their personal details. Yoti cannot see or access any personal information once the accounts have been verified.

Once people have Yoti they can then prove any element of their identity in seconds to businesses and organisations that accept Yoti.  They simply scan a QR code if they are on a desktop, or press ‘Use Yoti’ if on their mobile.  They’ll then be told what information is being requested and they allow the information to be shared.  Registered in seconds.  They can then log back in using their Yoti. No password is required meaning they’ll never forget them and the business need never worry about whether or not they chose a secure password.  

We are building an ecosystem of places where people can use Yoti in their everyday life. They will use Yoti to prove their age at the supermarket self checkout, apply for jobs online, sign up to new web services, prove their age on nights out instead of having to carry their passport.

We’re in our ‘pre-launch’ phase at the moment (we launch in November) but people seem interested.  Over 65,000 people have installed the app already and some great businesses and organisations like Reed, Worldpay and NSPCC are already working with Yoti.

To make it as easy as possible for businesses and organisations to use Yoti we've developed a number of SDKs in seven different coding languages and plugins for Wordpress and Drupal 7, with Joomla and Drupal 8 in development right now.

If you'd like to find out more about Yoti please visit www.yoti.com

ArchitectureCiviConDrupal

Last week, Equifax, one of the largest American credit agencies, was hit by a cyber attack that may have compromised the personal data of nearly 143 million people, including name, address, social security numbers, birthdates and more. The forfeited information reveals everything required to steal someone's identity or to take out a loan on someone else's name. Considering that the current US population is 321 million, this cyberattack is now considered to be one of the largest and most intrusive breaches in US history.

It's Equifax that is to blame, not open-source

As Equifax began to examine how the breach occurred, many unsubstantiated reports and theories surfaced in an attempt to pinpoint the vulnerability. One such theory targeted Apache Struts as the software responsible for the breach. Because Apache Struts is an open-source framework used for developing Java applications, this resulted in some unwarranted open source shaming.

Yesterday, Equifax confirmed that the security breach was due to an Apache Struts vulnerability. However, here is what is important; it wasn't because Apache Struts is open-source or because open-source is less secure. Equifax was hacked because the firm failed to patch a well-know Apache Struts flaw that was disclosed months earlier in March. Running an old, insecure version of software — open-source or proprietary — can and will jeopardize the security of any site. It's Equifax that is to blame, not open-source.

The importance of keeping software up-to-date

The Equifax breach is a good reminder of why organizations need to remain vigilant about properly maintaining and updating their software, especially when security vulnerabilities have been disclosed. In an ideal world, software would update itself the moment a security patch is released. Wordpress, for example, offers automatic updates in an effort to promote better security, and to streamline the update experience overall. It would be interesting to consider automatic security updates for Drupal (just for patch releases, not for minor or major releases).

In absence of automatic updates, I would encourage users to work with PaaS companies that keep not only your infrastructure secure, but also your Drupal application code. Too many organizations underestimate the effort and expertise it takes to do it themselves.

At Acquia, we provide customers with automatic security patching of both the infrastructure and Drupal code. We monitor our customers sites for intrusion attempts, DDoS attacks, and other suspicious activity. If you prefer to do the security patching yourself, we offer continuous integration or continuous delivery tools that enable you to get security patches into production in minutes rather than weeks or months. We take pride in assisting our customers to keep their sites current with the latest patches and upgrades; it's good for our customers and helps dispel the myth that open-source software is more susceptible to security breaches.

Everyone is welcome (including you!)

With just about two weeks to go until DrupalCon Vienna we are anticipating an amazing week of learning and collaborating ahead! There will be code sprints all week, but Friday is our dedicated sprint day when anyone and everyone can come contribute to Drupal core and participate together in guided sprints.

If you ever had to overwrite a module’s css file or a core javascript library in Drupal 7, you likely remember the experience. And not because it was a glorious encounter that left you teary-eyed at the sheer beauty of its ease and simplicity.

Along with Drupal 8 came the Libraries API and a whole new way of adding CSS and JS assets and managing libraries. In true Drupal 8 fashion, the new system uses YAML files to grant developers flexibility and control over their CSS and JS assets. This gives you the ability to overwrite core libraries, add libraries directly to templates, specify dependencies and more.

There are many pros to this approach. The most important improvement being that you can add these assets conditionally. The FOAD technique and other hackish ways to overwrite core CSS files or javascript libraries are long gone. This is extraordinarily good news!

However, the simplicity of the drupal_add_js() and drupal_add_css() functions have also disappeared, and now you have to navigate a potentially overwhelming and confusing nest of yml’s just to add some custom CSS or javascript to a page. (No, you can’t just add css via the theme’s .info file). In this post, I’ll guide you through the new Libraries API in Drupal 8 so you can nimbly place assets like you’ve always dreamed.

Prerequisites

If you haven’t yet experienced the glory that is the yml file, you’ll want to get familiar. Read this great introduction to YAML then come back to this post.

Creating Libraries

First step is to create your libraries.yml file at your-theme-name.libraries.yml or your-module-name.libraries.yml.

Here’s an example of how you define a Drupal 8 library.

A few things to note:

  • The path to CSS and JS files are relative to the theme or module directory that contains the libraries.yml file. We’ll cover that in more depth shortly.
  • The dependencies, in this case jQuery, are any other library your library depends on. They will automatically be attached wherever you attach your library and will load before yours.
  • Multiple libraries can be defined in one libraries.yml file, so each library in the file must have a unique name. However the libraries will be namespaced as mytheme/mylibrary or mymodule/mylibrary so a libraries.yml file in your theme and libraries.yml file in your module can contain libraries with the same name.
  • The css files are organized according to the SMACSS categories. This gives some control over the order of which assets are added to your page. The css files will be added according to their category. So any css file in the theme category will be added last, regardless of whether or not it comes from the base theme or the active child theme. Javascript files are not organized by SMACSS category.

Now that you know the library basics, it’s time to up the ante.

Properties

You can add additional properties inside the curly braces that allow you to define where the javascript is included, additional ordering of files, browser properties and more. We won’t cover all the possibilities just now, but here are some examples

Attaching Libraries

The simplest way to attach libraries globally is through the your-theme-name.info.yml file. Instead of adding stylesheets and scripts ala Drupal 7, you now attach libraries like so:

Global is great and all, but perhaps the coolest libraries upgrade in Drupal 8 is the ability to attach libraries via twig templates. For example, if you have a search form block, you can define the css and js for the block, add it to a library, and add that library to the search form block twig template. Those assets specific to the search form block will only be included when the block is rendered.

And yes, you can also attach libraries with our ol’ pal php.

Extending and Overriding Libraries

Another boon is the ability to extend and override libraries. These extensions and overrides take place in the your-theme-name.info.yml file.

As you might expect, libraries-extend respects the conditions of the library is being extended. Maybe you have a forum module that comes with css and js out-of-the-box. If you want to tweak the styling, you can extend the forum modules library, and add your own css file.

For overrides, you can remove or override a specific file or an entire library.

Final Considerations

Before we wrap up, I'll send you on your way with a couple final considerations and gotcha's that you need to be aware of.

  • The Libraries API Module is still relevant in Drupal 8, and should be used to handle external libraries that don't ship with drupal or a module or theme. It also allows libraries to be used by multiple modules or sites.
  • If a file is already linked to within a library it won't get added a second time.
  • Module CSS files are grouped before theme CSS files, so a module's css file will always be loaded before a theme's css file.
  • Refer to the Drupal 8 Theming Guide for more info.

Thanks for reading. Now go forth and use your asset placing powers for good, not evil.

I've completely revamped the Drush commands for Drupal Code Builder:

  • First, they're now in their own project on Github
  • Second, I've rewritten them completely for Drush 9, completely interactive.
  • Third, they are now geared towards adding to existing modules, rather than generating a module as a single shot. That approach made sense in the days of Drupal 6 when it was just hook implementations, but I increasingly find I want to add a plugin, a service, a form, to a module I've already started.

The downside is that installing these is rather tricky at the moment due to some current limitations in Drush 9 beta; see details in the project README, which has full instructions for workarounds.

Now that's out of the way, I'm pushing on with some new generators for the Drupal Code Builder library itself. On my list is:

  • plugin types (as in the plugin manager service, base class and interface, and declaration for Plugins module)
  • entity type
  • entity type handlers
  • your suggestions in the issue queue...

And of course more unit tests and refactoring of the codebase.

Pages