A new look for Drupal.org

As you can see we’ve put a fresh coat of paint on Drupal.org – but the changes run below the surface. This latest iteration of the front page brings the key concepts of our design system to the forefront: Clean, Modern, Technical.

This change also bri…

Drupal 8.1.10 released

Drupal 8.1.10, a maintenance release which contains fixes for security vulnerabilities, is now available for download.
See the Drupal 8.1.10 release notes for further information.
Download Drupal 8.1.10
Upgrading your existing Drupal 8 sites is strong…

Can Drupal outdo native applications?

Republished from buytaert.net

I’ve made no secret of my interest in the open web, so it won’t come as a surprise that I’d love to see more web applications and fewer native applications. Nonetheless, many argue that “the future of the internet isn’t the web” and that it’s only a matter of time before walled gardens like Facebook and Google — and the native applications which serve as their gatekeepers — overwhelm the web as we know it today: a public, inclusive, and decentralized common good.

I’m not convinced. Native applications seem to be winning because they offer a better user experience. So the question is: can open web applications, like those powered by Drupal, ever match up to the user experience exemplified by native applications? In this blog post, I want to describe inversion of control, a technique now common in web applications and that could benefit Drupal’s own user experience.

Native applications versus web applications

Using a native application — for the first time — is usually a high-friction, low-performance experience because you need to download, install, and open the application (Android’s streamed apps notwithstanding). Once installed, native applications offer unique access to smartphone capabilities such as hardware APIs (e.g. microphone, GPS, fingerprint sensors, camera), events such as push notifications, and gestures such as swipes and pinch-and-zoom. Unfortunately, most of these don’t have corresponding APIs for web applications.

A web application, on the other hand, is a low-friction experience upon opening it for the first time. While native applications can require a large amount of time to download initially, web applications usually don’t have to be installed and launched. Nevertheless, web applications do incur the constraint of low performance when there is significant code weight or dozens of assets that have to be downloaded from the server. As such, one of the unique challenges facing web applications today is how to emulate a native user experience without the drawbacks that come with a closed, opaque, and proprietary ecosystem.

Inversion of control

In the spirit of open source, the Drupal Association invited experts from the wider front-end community to speak at DrupalCon New Orleans, including from Ember and Angular. Ed Faulkner, a member of the Ember core team and contributor to the API-first initiative, delivered a fascinating presentation about how Drupal and Ember working in tandem can enrich the user experience.

One of Ember’s primary objectives is to demonstrate how web applications can be indistinguishable from native applications. And one of the key ideas of JavaScript frameworks like Ember is inversion of control, in which the client side essentially “takes over” from the server side by driving requirements and initiating actions. In the traditional page delivery model, the server is in charge, and the end user has to wait for the next page to be delivered and rendered through a page refresh. With inversion of control, the client is in charge, which enables fluid transitions from one place in the web application to another, just like native applications.

Before the advent of JavaScript and AJAX, distinct states in web applications could be defined only on the server side as individual pages and requested and transmitted via a round trip to the server, i.e. a full page refresh. Today, the client can retrieve application states asynchronously rather than depending on the server for a completely new page load. This improves perceived performance. I discuss the history of this trend in more detail in this blog post.

Through inversion of control, JavaScript frameworks like Ember provide much more than seamless interactions and perceived performance enhancements; they also offer client-side storage and offline functionality when the client has no access to the server. As a result, inversion of control opens a door to other features requiring the empowerment of the client beyond just client-driven interactions. In fact, because the JavaScript code is run on a client such as a smartphone rather than on the server, it would be well-positioned to access other hardware APIs, like near-field communication, as web APIs become available.

Inversion of control in end user experiences

Animated transition between pages

When a user clicks a teaser image on the homepage of an Ember-enhanced Drupal.com, the page seamlessly transitions into the full content page for that teaser, with the teaser image as a reference point, even though the URL changes.

In response to our recent evaluation of JavaScript frameworks and their compatibility with Drupal, Ed applied the inversion of control principle to Drupal.com using Ember. Ed’s goal was to enhance Drupal.com’s end user experience with Ember to make it more application-like, while also preserving Drupal’s editorial and rendering capabilities as much as possible.

Ed’s changes are not in production on Drupal.com, but in his demo, clicking a teaser image causes it to “explode” to become the hero image of the destination page. Pairing Ember with Drupal in this way allows a user to visually and mentally transition from a piece of teaser content to its corresponding page via an animated transition between pages — all without a page refresh. The animation is very impressive and the animated GIF above doesn’t do it full justice. While this transition across pages is similar to behavior found in native mobile applications, it’s not currently possible out of the box in Drupal without extensive client-side control.

Rather than the progressively decoupled approach, which embeds JavaScript-driven components into a Drupal-rendered page, Ed’s implementation inverts control by allowing Ember to render what is emitted by Drupal. Ember maintains control over how URLs are loaded in the browser by controlling URLs under its responsibility; take a look at Ed’s DrupalCon presentation to better understand how Drupal and Ember interact in this model.

These impressive interactions are possible using the Ember plugin Liquid Fire. Fewer than 20 lines of code were needed to build the animations in Ed’s demo, much like how SDKs for native mobile applications provide easy-to-implement animations out of the box. Of course, Ember isn’t the only tool capable of this kind of functionality. The RefreshLess module for Drupal by Wim Leers (Acquia) also uses client-side control to enable navigating across pages with minimal server requests. Unfortunately, RefreshLess can’t tap into Liquid Fire or other Ember plugins.

Inversion of control in editorial experiences

Animated transitions between editorial features

In CardStack Editor, an editorial interface with transitions and animations is superimposed onto the content page in a manner similar to outside-in, and the editor benefits from an in-context, in-preview experience that updates in real time.

We can apply this principle of inversion of control not only to the end user experience but also to editorial experiences. The last demos in Ed’s presentation depict CardStack Editor, a fully decoupled Ember application that uses inversion of control to overlay an administrative interface to edit Drupal content, much like in-place editing.

CardStack Editor communicates with Drupal’s web services in order to retrieve and manipulate content to be edited, and in this example Drupal serves solely as a central content repository. This is why the API-first initiative is so important; it enables developers to use JavaScript frameworks to build application-like experiences on top of and backed by Drupal. And with the help of SDKs like Waterwheel.js (a native JavaScript library for interacting with Drupal’s REST API), Drupal can become a preferred choice for JavaScript developers.

Inversion of control as the rule or exception?

Those of you following the outside-in work might have noticed some striking similarities between outside-in and the work Ed has been doing: both use inversion of control. The primary purpose of our outside-in interfaces is to provide for an in-context editing experience in which state changes take effect live before your eyes; hence the need for inversion of control.

Thinking about the future, we have to answer the following question: does Drupal want inversion of control to be the rule or the exception? We don’t have to answer that question today or tomorrow, but at some point we should.

If the answer to that question is “the rule”, we should consider embracing a JavaScript framework like Ember. The constellation of tools we have in jQuery, Backbone, and the Drupal AJAX framework makes using inversion of control much harder to implement than it could be. With a JavaScript framework like Ember as a standard, implementation could accelerate by becoming considerably easier. That said, there are many other factors to consider, including the costs of developing and hosting two codebases in different languages.

In the longer term, client-side frameworks like Ember will allow us to build web applications which compete with and even exceed native applications with regard to perceived performance, built-in interactions, and a better developer experience. But these frameworks will also enrich interactions between web applications and device hardware, potentially allowing them to react to pinch-and-zoom, issue native push notifications, and even interact with lower-level devices.

In the meantime, I maintain my recommendation of (1) progressive decoupling as a means to begin exploring inversion of control and (2) a continued focus on the API-first initiative to enable application-like experiences to be developed on Drupal.

Conclusion

I’m hopeful Drupal can exemplify how the open web will ultimately succeed over native applications and walled gardens. Through the API-first initiative, Drupal will provide the underpinnings for web and native applications. But is it enough?

Inversion of control is an important principle that we can apply to Drupal to improve how we power our user interactions and build robust experiences for end users and editors that rival native applications. Doing so will enable us to enhance our user experience long into the future in ways that we may not even be able to think of now. I encourage the community to experiment with these ideas around inversion of control and consider how we can apply them to Drupal.

Special thanks to Preston So for contributions to this blog post and to Angie ByronWim LeersKevin O’LearyMatt Grill, and Ted Bowman for their feedback during its writing.

A roadmap for making Drupal more API-first

Republished from buytaert.net

In one of my recent blog posts, I articulated a vision for the future of Drupal’s web services, and at DrupalCon New Orleans, I announced the API-first initiative for Drupal 8. I believe that there is considerable momentum behind driving the web services initiative. As such, I want to provide a progress report, highlight some of the key people driving the work, and map the proposed vision from the previous blog post onto a rough timeline.

Here is a bird’s-eye view of the plan for the next twelve months:

8.2 (Q4 2016) 8.3 (Q2 2017) Beyond 8.3 (2017+)
New REST API capabilities
Waterwheel initial release
New REST API capabilities
JSON API module
GraphQL module?
Entity graph iterator?

New REST API capabilities

Wim Leers (Acquia) and Daniel Wehner (Chapter Three) have produced a comprehensive list of the top priorities for the REST module. We’re introducing significant REST API advancements in Drupal 8.2 and 8.3 in order to improve the developer experience and extend the capabilities of the REST API. We’ve been focused on configuration entity support, simplified REST configuration, translation and file upload support, pagination, and last but not least, support for user login, logout and registration. All this work starts to address differences between core’s REST module and various contributed modules like Services and RELAXed Web Services. More details are available in my previous blog post.

Many thanks to Wim Leers (Acquia), Daniel Wehner (Chapter Three), Ted Bowman (Acquia),Alex Pott (Chapter Three), and others for their work on Drupal core’s REST modules. Though there is considerable momentum behind efforts in core, we could always benefit from new contributors. Please consider taking a look at the REST module issue queue to help!

Waterwheel initial release

As I mentioned in my previous post, there has been exciting work surrounding Waterwheel, an SDK for JavaScript developers building Drupal-backed applications. If you want to build decoupled applications using a JavaScript framework (e.g. Angular, Ember, React, etc.) that use Drupal as a content repository, stay tuned for Waterwheel’s initial release later this year.

Waterwheel aims to facilitate the construction of JavaScript applications that communicate with Drupal. Waterwheel’s JavaScript library allows JavaScript developers to work with Drupal without needing deep knowledge of how requests should be authenticated against Drupal, what request headers should be included, and how responses are molded into particular data structures.

The Waterwheel Drupal module adds a new endpoint to Drupal’s REST API allowing Waterwheel to discover entity resources and their fields. In other words, Waterwheel intelligently discovers and seamlessly integrates with the content model defined on any particular Drupal 8 site.

A wider ecosystem around Waterwheel is starting to grow as well. Gabe Sullice, creator of the Entity Query API module, has contributed an integration of Waterwheel which opens the door to features such as sorts, conditions and ranges. The Waterwheel team welcomes early adopters as well as those working on other REST modules such as JSON API and RELAXed or using native HTTP clients in JavaScript frameworks to add their own integrations to the mix.

Waterwheel is the currently the work of Matt Grill (Acquia) and Preston So (Acquia), who are developing the JavaScript library, and Ted Bowman (Acquia), who is working on the Drupal module.

JSON API module

In conjunction with the ongoing efforts in core REST, parallel work is under way to build a JSON API module that embraces the JSON API specification. JSON API is a particular implementation of REST that provides conventions for resource relationships, collections, filters, pagination, and sorting, in addition to error handling and full test coverage. These conventions help developers build clients faster and encourages reuse of code.

Thanks to Mateu Aguiló BoschEd Faulkner and Gabe Sullice, who are spearheading the JSON API module work. The module could be ready for production use by the end of this year and included as an experimental module in core by 8.3. Contributors to JSON API are meeting weekly to discuss progress moving forward.

Beyond 8.3: GraphQL and entity graph iterator

While these other milestones are either certain or in the works, there are other projects gathering steam. Chief among these is GraphQL, which is a query language I highlighted in my Barcelona keynote and allows for clients to tailor the responses they receive based on the structure of the requests they issue.

One of the primary outcomes of the New Orleans web services discussion was the importance of a unified approach to iterating Drupal’s entity graph; both GraphQL and JSON API require such an “entity graph iterator.” Though much of this is still speculative and needs greater refinement, eventually, such an “entity graph iterator” could enable other functionality such as editable API responses (e.g. aliases for custom field names and timestamp formatters) and a unified versioning strategy for web services. However, more help is needed to keep making progress, and in absence of additional contributors, we do not believe this will land in Drupal until after 8.3.

Thanks to Sebastian Siemssen, who has been leading the effort around this work, which is currently available on GitHub.

Validating our work and getting involved

In order to validate all of the progress we’ve made, we need developers everywhere to test and experiment with what we’re producing. This means stretching the limits of our core REST offerings, trying out JSON API for your own Drupal-backed applications, reporting issues and bugs as you encounter them, and participating in the discussions surrounding this exciting vision. Together, we can build towards a first-class API-first Drupal.

Special thanks to Preston So for contributions to this blog post and to Wim Leers for feedback during its writing.

Drupal is for ambitious digital experiences

Republished from buytaert.net

What feelings does the name Drupal evoke? Perceptions vary from person to person; where one may describe it in positive terms as “powerful” and “flexible,” another may describe it negatively as “complex.” People describe Drupal differently not only as a result of their professional backgrounds, but also based on what they’ve heard and learned.

If you ask different people what Drupal is for, you’ll get many different answers. This isn’t a surprise, because over the years the answers to this fundamental question have evolved. Drupal started as a tool for hobbyists building community websites, but over time it’s evolved to support large and sophisticated use cases.

Perception is everything

Perception is everything; it sets expectations and guides actions and inactions. We need to better communicate Drupal’s identity, demonstrate its true value, and manage its perceptions and misconceptions. Words do lead to actions. Spending the time to capture what Drupal is for could energize and empower people to make better decisions when adopting, building, and marketing Drupal.

Truth be told, I’ve been reluctant to define what Drupal is for, as it requires making trade-offs. I’ve feared that we’d make the wrong choice or limit our growth. Over the years, it’s become clear that not defining what Drupal is used for leaves more people confused, even within our own community.

For example, because Drupal evolved from a simple tool for hobbyists to a more powerful digital experience platform, many people believe that Drupal is now “for the enterprise.” While I agree that Drupal is a great fit for the enterprise, I personally never loved that categorization. It’s not just large organizations that use Drupal. Individuals, small startups, universities, museums, and non-profits can be equally ambitious in what they’d like to accomplish, and Drupal can be an incredible solution for them.

Defining what Drupal is for

Rather than using “for the enterprise,” I thought “for ambitious digital experiences” was a good phrase to describe what people can build using Drupal. I say “digital experiences” because I don’t want to confine this definition to traditional browser-based websites. As I’ve stated in my Drupalcon New Orleans keynote, Drupal is used to power mobile applications, digital kiosks, conversational user experiences, and more. Today I really wanted to focus on the word “ambitious.”

“Ambitious” is a good word because it aligns with the flexibility, scalability, speed and creative freedom that Drupal provides. Drupal projects may be ambitious because of the sheer scale (e.g. The Weather Channel), their security requirements (e.g. The White House), the number of sites (e.g. Johnson & Johnson manages thousands of Drupal sites), or specialized requirements of the project (e.g. the New York MTA powering digital kiosks with Drupal). Organizations are turning to Drupal because it gives them greater flexibility, better usability, deeper integrations, and faster innovation. Not all Drupal projects need these features on day one—or needs to know about them—but it is good to have them in case you need them later on.

“Ambitious” also aligns with our community’s culture. Our industry is in constant change (responsive design, web services, social media, IoT), and we never look away. Drupal 8 was a very ambitious release; a reboot that took one-third of Drupal’s lifespan to complete, but maneuvered Drupal to the right place for the future that’s now coming. I’ve always believed that the Drupal community is ambitious, and I believe that attitude remains strong in our community.

Last but not least, our adopters are also ambitious. They are using Drupal to transform their organizations digitally, leaving established business models and old business processes in the dust.

I like the position that Drupal is ambitious. Stating that Drupal is for ambitious digital experiences, however, is only a start. It only gives a taste of Drupal’s objectives, scope, target audience, and advantages. I think we’d benefit from being much clearer. I’m curious to know how you feel about the term “for ambitious digital experiences” versus “for the enterprise” versus not specifying anything. Let me know in the comments so we can figure out how to collectively change the perception of Drupal.

PS: I’m borrowing the term “ambitious” from the Ember.js community. They use the term in their tagline and slogan on their main page.

Restructuring Drupal.org

In this post I’d like to talk about one of our major projects for 2016, which comes as a follow up to the content strategy project of 2015.
Content restructure
Last year we presented our findings from the content strategy developed by Drupal Associatio…

Launch of the Aaron Winborn Award 2016

Last year, in honor of long-time Drupal contributor Aaron Winborn, whose battle with Amyotrophic lateral sclerosis (ALS) (also referred to as Lou Gehrig’s Disease) came to an end, the Community Working Group, with the support of the Drupal Association …

Drupal 8.0.5 released

Drupal 8.0.5, a maintenance release with numerous bug fixes (no security fixes), is now available for download.
See the Drupal 8.0.5 release notes for a full list of included fixes.

Download Drupal 8.0.5
Upgrading your existing Drupal 8 sites is reco…

Top 10 contributing customers

We spent a lot of time thinking about how to highlight the organizations in our Marketplace that are actively contributing to the project. There are some awesome Drupal shops and hosting partners out there that are making a huge difference.

Service providers that you see in the marketplace are only part of the story of how Drupal is built.

Last week, we launched a new list of organizations on Drupal.org that shows every profile that has been created for an organization. This includes companies, universities, nonprofits, governments and more. These are our customers and community organizations that use Drupal to power their web experiences. By giving their developers time to contribute code back to the community, they are helping to ensure the project gets the best ideas from the most diverse group of makers and builders.

While the new view shows all organizations, I was able to pull out the top 10 customers—organizations that do not sell Drupal services or hosting—and community organizations (e.g. community from a region).

So who have been most active among this type of organization over the last 90 days?

  1. Examiner.com – 56 issue credits
  2. Pfizer – 29 issue credits
  3. Freitag – 19 issue credits
  4. Drupal Ukraine Community – 17 issue credits
  5. ARTE G.E.I.E. – 15 issue credits
  6. University of Waterloo – 13 issue credits
  7. Card.com – 13 issue credits
  8. Gemeente Venlo – 11 issue credits
  9. Dennis Publishing – 9 issue credits (and they are Drupal Association members to boot!)
  10. NBCUniversal – 7 issue credits

Check out the full list of every organization with a profile on Drupal.org. Keep in mind, we can only track issue credits when issue participants credit an organization and when maintainers award those credits.

Only organizations with a profile on Drupal.org can be credited. Confirmed users can add new organizations.

We are all excited to see where this takes us and what we can learn about how organizations that use Drupal are giving back.

If your company or organization wants to give back in ways other than contributing in the code and issue queues, consider becoming an organization member, joining one of our supporter programs, or sponsoring a DrupalCon or camp.

Introducing a new Community Initiatives Process

One of the most important lessons of 2015 for the Engineering Team here at the Drupal Association is that we need better ways to engage with you, the community. We realized we need better tools and ways to communicate with you about our current priorities, how you can influence those priorities, and how you can help make Drupal.org and the Drupal project better than ever.

All of the work we do stems from the mission of the Drupal Association. It’s our duty and responsibility to unite a global open source community to build and promote Drupal. As the home of that community, and the codebase, Drupal.org is perhaps the most critical piece of that mission, and at the most basic level all of the initiatives we prioritize must support that goal.

As part of reviewing our work in 2015, and in the interests of being transparent with the Drupal Community, we revamped the Drupal.org Roadmap. As you can see, we chose to focus on the few, most important initiatives that we have the capacity to execute on in the near term. We’re also including upcoming initiatives that we will move into as the active work is completed, but not as many as we had previously displayed. An important lesson of the past year is that we have to be Agile on the macro scale as well as on the micro. The needs of the community can change rapidly and we need to be able to respond.

Current

These are the initiatives the Drupal Association technology staff is focused on now.

Next

These are the initiatives the Drupal Association staff will work on or support once the Current initiatives are completed. The order of these initiatives may change.

We’ve also added some new iconography to indicate where some of these initiatives come from.

Initiatives with the tools ( ) icon represent essential support and maintenance work. This can mean paying down technical debt in the Drupal.org codebase, performing server maintenance, or implementing cost saving measures to help fund the rest of our mission driven work.

Initiatives with the community ( ) icon represent initiatives that were directly proposed by members of the community and/or are being supported by volunteer work from the community.

Don’t all the initiatives come from the community?

Yes, all of our priorities come from the needs of the community – but the community is a loose collective of many different groups of people with many different needs and priorities.

The needs of Drupal newcomers are vastly different from those of the Drupal Core Maintainers. The needs of our documentation editors are different from the needs of those providing support on the forums. And all of these needs must cohere with a larger product and design vision for Drupal.org to make this home of the community a cohesive, efficient, and beautiful place to be.

The Drupal Association Engineering Team can be thought of as the maintainers for Drupal.org and the sub-sites. It’s our duty to synthesize these diverse needs and to prioritize the major initiatives that will have the highest impact for the community. It’s also our job to make the architectural decisions for Drupal.org to ensure that every aspect of the site is functional/useable, consistent, and maintainable.

Most of our priorities, therefore, we set ourselves by bringing all of these factors together and doing the best we can to have the biggest impact, not just on the most vocal parts of the community, but also on those parts that are sometimes siloed or overlooked.

All that said, the community is absolutely a vital part of creating our initiatives. The maintainers for any other project on Drupal.org do not act alone – they accept feedback and contributions from other contributors, while at the same time making key architectural decisions, reviewing patches, and ultimately deploying that work in the form of new releases. We do the same with our initiatives.

Community Volunteers and Community Initiatives

There are two ways that members of the community can have a direct influence on the Roadmap for Drupal.org. These methods have existed informally in the past, but in 2016 we’d like to beta test some new ideas to make these processes more formal, consistent, and transparent.

The first way is to volunteer your expertise to help with one of the existing initiatives we already have prioritized, or even to offer your expertise without a particular contribution in mind. There is a strong record of community volunteers helping to improve Drupal.org, just a few examples from the last year include: u/mlhess and u/nnewton helping with infrastructure; to u/michelle helping to clean up spam; to u/dddave and others in the webmasters queue; or u/mshmsh5000 who helped with Drupal Jobs feature development.

If you have expertise (and not just in code!) and are ready for guidance from the Drupal Association engineering team as to how you can help, you can offer your assistance as a volunteer.

Learn about Volunteering

I should also note – we strongly encourage most volunteers to first consider giving back to the Drupal project itself, but we are certainly happy for help with Drupal.org

The second way to influence the Drupal.org roadmap is to develop a community initiative. If you (and perhaps a small team of others in the community) have some expertise in a particular area, and have a particular initiative in mind that you would like to work on, you can propose a community initiative.

View Community Initiatives

Community initiatives come in all shapes in sizes: from documentation audits with the help of u/dead_arm; to adding two factor authentication to Drupal.org with u/coltrane; to a much larger task like building and deploying DrupalCI with the help of u/jthorson, u/nickscuch, u/ricardoamaro, u/bastianwidmer and several others. Some initiatives affect a subset of the community, project maintainers, for example, whereas others may affect almost every user.

Why this new process?

The hard lesson we’ve learned over the course of the past year is that we need to be involved early. Even in cases where the community volunteers driving an initiative forward are experts in their area – if Association staff are not involved early in the architectural and planning decisions then what should be a positive, collaborative effort is often slowed down by architectural refactoring and design decision backtracks. That is not fun for anybody, and our immense respect for our community collaborators requires that we set them up for success by getting involved early.

As such, our new community initiatives process has several steps:

  1. Community members plan their contribution in an issue, and identify who (if anyone) is able to volunteer some time to make the contribution.
  2. The community members propose their initiative to the Association – so that we can evaluate it for inclusion on our roadmap. This may include a call with the community members proposing the initiative to talk it through in greater detail.
  3. Association staff evaluate the initiative: prioritize it into the roadmap, postpone it, or–if necessary– reject initiatives that are not a good fit.
  4. Prioritized community initiatives are rolled into the larger Drupal.org roadmap, and monthly or bi-monthly community initiative meetings are scheduled to ensure the work moves forward.
  5. A liaison from the Association engineering team is assigned, to help coordinate architectural decisions, to provide support and access as needed, and to coordinate with the larger team when it is time for the work to be reviewed.

This process is time intensive – and so in general we expect to be able to run only one or maybe two community initiatives at a time, in parallel with our other work. We realize this may be frustrating, but the last year has shown that our most successful initiatives required this close coordination.

This process is new, and will evolve

Finding a good process for working closely with such a diverse and passionate community is not easy—and we aren’t assuming that this new process will be perfect. We’re going to trial this new community initiative process in 2016 with the goal of increasing the transparency of how we prioritize our work, and how the community can help us build a better Drupal.org. We are committed to making this process better.

2016 Nominations Open for Drupal Association At-Large Director

Overview

It’s a great time to be part of the Drupal Association. We’ve done some amazing work in the last few years, and we’re in a great position to work with the community to continue to improve and grow fully into our mission. As a Drupal Association At-Large Director, you’d be in the center of the action. The At-large Director position is specifically designed to ensure community representation on the Drupal Association board and we strongly encourage anyone with an interest to nominate themselves today.

Nominate Yourself Today

The Board of Directors of the Drupal Association are responsible for financial oversight and setting the strategic direction of the Drupal Association. New board members will contribute to the strategic direction of the Drupal Association. Board members are advised of, but not responsible for matters related to the day to day operations of the Drupal Association, including program execution, staffing, etc. You can learn more about what’s expected of a board member in this post and presentation.

Directors are expected to contribute around five hours per month and attend two in-person meetings per year (financial assistance is available if required). All board members agree to meet the minimum requirements documented in the board member agreement.

Today we are opening the self-nomination form that allows you to throw your hat in the ring. We’re looking to elect one candidate this year to serve a two-year term.

How to Nominate Yourself

To nominate yourself, you should be prepared to answer a few questions:

  • About Me: Tell us about yourself! Your background, how you got into Drupal, etc.
  • Motivation: Why are you applying for a board position? What initiatives do you hope to help drive, or what perspectives are you going to try and represent?
  • Experience: What Drupal community contributions have you taken part in (code, camps, etc.)? Do you have experience in financial oversight, developing business strategies, or organization governance?
  • Availability: I am able to travel to three in-person board meetings per year (either self-funded, or with financial sponsorship)
  • IRC Handle
  • Twitter Handle

We’ve also made a few changes to the process based on community feedback from the 2015 election:

  • We now display your username, not your given name, on your candidate profile to address privacy concerns that had been raised. Nominees should note that given names are required on legal documentation such as our 990 IRS filings, but we will do our best to preserve your privacy where we can. 
  • Updated sidebar block has more information about the elections, making it easier to the information you need. 
  • When you nominate yourself we will ask if you would like to opt-in to share your election results data. Last year was the first time we published full results from the vote data. Candidates that opt-in will have their name displayed next to their vote counts, as in this example from 2015.

We will also need to know that you are available for the next step in the process, meet the candidate sessions. We are hosting 3 sessions: 

Meet the Candidate Web Conferences:

Session One
Tue 23 Feb 2016 at 16:00 UTC

  • 7 AM PST Tue 23 Feb, US and Canada
  • 10 AM EST Tue 23 Feb, US and Canada
  • 1 PM Tue 23 Feb, Sao Paulo Brasil
  • 3 PM Tue 23 Feb, London
  • 11 PM Tue 23 Feb, Beijing

Session Two
Wed 24 Feb 2016 at 21:00 UTC

  • 12 PM PST Wed 24 Feb, US and Canada
  • 3 PM EST Wed 24 Feb, US and Canada
  • 5 PM Wed 24 Feb, Sao Paulo Brasil
  • 8 PM Wed 24 Feb, London
  • 4 AM Thu 26 Feb, Beijing
  • 7 AM Thu 26 Feb, Sydney Australia

Session Three
Thu 25 Feb 2016 at 01:00 UTC

  • 4:00 PM PST Thu 25 Feb, US and Canada
  • 7:00 PM EST Thu 25 Feb, US and Canada
  • 9:00 PM Thu 25 Feb, Sau Paulo Brasil
  • 12:00 AM Fri 26 Feb, London
  • 8:00 AM Fri 26 Feb, Beijing
  • 11:00 AM Fri 26 Feb, Sydney Australia

The nomination form will be open February 1, 2016 through February 20, 2016 at midnight UTC. For a thorough review of the process, please see the elections home page.

If you have any questions, please contact Holly Ross, Drupal Association Executive Director. For the sake of keeping conversational threads in one place, the comments on this news item have been closed. Please comment on the original post on the Drupal Association website.

Flickr photo: Clyde Robinson

Front page news: 

Selecting a client-side framework for Drupal

Republished from buytaert.net

Last month, my blog post about whether a client-side framework is right for Drupal stimulated some excellent insights into how the future of the Drupal front end might look. There was broad agreement that incorporating more JavaScript into Drupal’s administrative interface is important for a future-ready user experience.

I am confident that adopting a client-side framework through progressive decoupling will give us the best of both worlds. Of course, this does not mean I oppose fully decoupling through any other framework; in fact, I believe we should redouble our efforts toward a first-class API-first Drupal. But progressive decoupling means that we will be able to work toward a next-generation user experience without abandoning much of the work we’ve done so far.

With that in mind, I tasked a small team made up of various experts from the Drupal and various JavaScript communities with putting together a list of criteria and a comparison matrix to help us decide on the most appropriate client-side framework for progressive decoupling in Drupal.

JavaScript framework comparison matrix

After a hundred hours of work, we came up with a criteria document and comparison matrix (PDF version):

Special thanks to all of the following experts who provided review and input: Miško Hevery (creator of Angular; Google) and Igor Minar (technical lead for Angular; Google); Ed Faulkner (core maintainer for Ember); Amitai Burstein (Drupal and Elm contributor; Gizra); Sebastian Siemssen (Drupal contributor, Elm and React developer; Zensations); and John Albin Wilkins (Drupal 8 mobile initiative lead), Alex Bronstein (Drupal core maintainer; Acquia), Wim Leers (Drupal core contributor; Acquia), and Preston So (Drupal contributor, Acquia).

Though this is a good starting point that lays the groundwork for a formal adoption process in Drupal core, it is time to open our comparison for review by members of both the Drupal and JavaScript communities. We should also more rigorously evaluate these frameworks’ appropriateness through actual development.

First, have we decided on the right criteria regardless of the frameworks themselves? This is probably the most important at this stage. While many organizations choose to adopt client-side frameworks for fully decoupled implementations, Drupal is the first to consider layering a framework on top to allow both richly dynamic and more traditional modules to coexist gracefully through progressive decoupling. What issues around templates, rendering, and client-side caching should we incorporate into these criteria? Is there anything missing or overemphasized?

Second, have we selected the right frameworks to focus on? Are there other frameworks, libraries, or even compile-to-JavaScript projects (such as Elm) that should be included in the matrix? In my view, it is best for Drupal to adopt a framework with an already large community and ecosystem that would allow us to more quickly bridge the gap and resolve any friction during adoption. To provide a good frame of reference, we’ve also included Backbone, Angular, and Knockout, all three slightly older among client-side frameworks. Others on our shortlist that we didn’t consider due to low levels of adoption and small communities are Mithril, Riot, and Vue. Still other ambitious projects such as the Elm and ClojureScript languages are also candidates, but their adoption will mean more up-front work to support typical features of client-side frameworks, as well as buy-in into an approach where JavaScript is compiled from a different language.

Finally, have we drawn the right conclusions against these criteria? In other words, did we fill out the cells correctly? While they have been reviewed by some of the frameworks’ experts, there might be unexpected gotchas or caveats.

I’m sharing the initial comparison matrix on my blog for maximum reach; I want both the Drupal community and the JavaScript framework communities, as well as the broader front-end community, to take note. After three installments on my blog (“The future of decoupled Drupal”, “Should we decouple Drupal with a client-side framework?”), it’s time to move the technical conversation to drupal.org. There is now an issue in the core issue queue on drupal.org to iterate on the matrix.

Preliminary conclusions

At the moment, the most promising candidates in the comparison matrix appear to be Angular 2, Ember, and React, given their technical robustness, relative suitability for progressively decoupled Drupal, and their strong levels of community support and broader adoption. Given that Backbone is already in core and several modules already rely on it, we have included it too.

What we’ve learned from talking to the different projects is that they are often converging on similar techniques and best practices; they are by and large adding support for Virtual DOM implementations or rehydration (seamless state transfer), and they are all obsessing over small payload size and performance, better testability, etc. Therefore it is important to focus on the fundamental, often philosophical, differences between the projects that will likely be unchanged in time; key architectural differences, their release cadence and stance on backward compatibility, their license, their governance model, their flexibility and learning curve, etc.

From a quick glance at the criteria and our needs, it seems that Ember is currently our best candidate, as it appears to have a slight technical edge overall. Ember 2.0 has an all-new rendering engine named Glimmer, and it has server-side rendering through FastBoot. On the other hand, however, Ember is quite bulky and opinionated (enforcing patterns for code structure) compared to other candidate frameworks. A more fundamental difference is that unlike Angular and React, which have corporate governance and funding, Ember is a community-driven project like Drupal.

While React is lightweight, it needs integration with a variety of other libraries in the React ecosystem to work as a full-fledged implementation, which gives it a steep learning curve from an implementation standpoint. Because React is a relatively young project, best practices are shifting quickly and making it less attractive. The Virtual DOM, among React’s most compelling features, has also seen its core ideas filter into other framework projects. But more importantly, React is licensed with what I believe to be a potentially unacceptable patent clause, which states that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This has already generated some concerted pushback from both WordPress’s Calypso and React contributors.

Angular 2 is a complete rewrite of Angular 1 to address issues with that version of the framework, including performance problems stemming from a large file size. The new version also introduces a new template engine that incorporates both directives familiar to Angular 1 developers and nestable component-based templates. But Angular 2’s Apache 2.0 licensing is incompatible with Drupal’s own GPLv2 license. While Drupal’s PHP code and JavaScript code run in isolated processes, it appears that an Apache 2.0-licensed project can’t be jointly distributed within an umbrella project that uses a GPLv2 license.

In addition to being at a slight technical disadvantage to Ember, the legal concerns with React and Angular make me believe Ember might be our best bet. But I’m not a lawyer nor a JavaScript expert, so I can’t make this decision alone; I’m looking for lots of feedback, particularly from JavaScript experts, to determine the best option for Drupal.

Conclusion

Whatever the result of the debate around which client-side framework to adopt, I believe that Drupal needs to move quickly to embrace a framework that will aid development of a progressively decoupled architecture and corresponding user experience improvements. By providing some baseline criteria and including our accomplished community, I have no doubt we can reach this decision quickly but also intelligently.

Special thanks to Preston So for contributions to this blog post.

Continue the discussion at buytaert.net or at #2645250: [META] Supersede Backbone in core admin UIs with a new client-side framework

Front page news: 
Drupal version: 

2015 Year in Review for Drupal.org

If your 2015 was anything like mine, it passed by extremely quickly. It was marked by periods of frustration (spammers still love Drupal.org) and elation (Drupal 8 launched, woot!).

Below are a few highlights from our 2015 change logs on Drupal.org. For a more detailed look into each monthly update you can read our “What’s New on Drupal.org?” blog posts.

January

February

  • DrupalCon Latin America
  • Launch of Drupal Events (<a href=”https://events.drupal.org>events.drupal.org) with the site for DrupalCon Los Angeles – all new events sites are hosted from the same installation
  • Account creation improvements including a faster 2-step registration that returns users to the site they initiated registration from
  • Support for the 2015 community elections for board member at large
  • Implementation of Server Density for systems monitoring
  • Centralized logging for Druapl.org infrastructure

March

April

May

June

July

  • Interns from Epicodus join the Drupal.org team for 8 weeks
  • New Git servers configured and deployed to production to replace aging hardware
  • Core patch testing enabled for DrupalCI

August

  • Upgrade of Localize.drupal.org to Drupal 7
  • Apache Solr upgrades
  • Updates to make issues in project queues easier to quickly read and digest
  • Performance profiling on a new integration server leads to site speed improvements

September

  • Drupal.org search improvements
  • First content model update with sections and pages deployed
  • Solr server high availability improvements
  • DrupalCon Barcelona
  • Marketplace updates to order organizations by last 90 days of issue credits and supporter status

October

  • Drupal 8 RC1
  • DrupalCI becomes the primary test platform for Drupal 8 Core; legacy testing is disabled
  • Flag module and administrative views are deployed for a new take on spam fighting
  • Drupal 6 & 7 testing are enabled on DrupalCI
  • Kicked off the first Drupal.org membership drive
  • Breadcrumbs for top level sections to make navigation a bit easier

November

December

  • Published plan for Composer support on Drupal.org
  • Old testbots are disabled and all Drupal testing is now run through DrupalCI
  • Homepage changes to support the membership campaign
  • Presented the new community engagement plan to the board and working groups

That was a lot of work in what was a tumultuous year. Between all the DrupalCon websites, and major updates to some of our existing sub-sites, we launched as many sites as some web development shops—at least the smaller ones.

We made several small but high impact usability improvements to Drupal.org, and built better features to highlight the contributions of individuals and organizations on their profiles. We modernized and hardened our infrastructure. We made Drupal.org a little more beautiful to better promote this amazing software and community that we support to people finding us for the first time. Among all of that…

What was the most important work in 2015?

If I had to call out just one thing the Drupal.org team did this year that was essential to the success of Drupal and the community, I would highlight the great work done to launch DrupalCI and make it a production system that could handle our community’s unique testing needs.

DrupalCI (the CI stands for Continuous Integration) started as a community initiative. It had been in progress for years as work to replace our aging testbot infrastructure. The old testbots required a manual spin up of new testing servers that were hosted on VMs in a cluster at the Open Source Labs. They were proprietary and rigid. If a testbot went down, it would require manual intervention to free up the queue and allow tests to begin again.

By working closely with the community throughout Q2 and Q3 of 2015, we were able to launch a testing infrastructure that supports multiple testing environments—a feature which has already helped support other projects, like PHP 7—dynamically scales to the testing load, and which is tightly integrated with the Drupal.org issue queues. Overall the new system is much more configurable and far more scalable than the previous system.

Why is testing so vital to the community? Because Drupal 8 represents a much larger code base than Drupal 7. A huge proportion of those new lines of code are tests. Every time a patch is submitted to Drupal Core, up to 15,000+ tests are run—with over 100,000 assertions. Core maintainers and initiative leads need those tests to help them understand how the new code introduced will affect Drupal. Contrib developers can also use DrupalCI to ensure their modules will work well with Drupal.

Though the work to get DrupalCI into production and optimized, we were able to give core maintainers faster and more reliable information about code submitted for inclusion in Drupal.

I honestly believe that without DrupalCI, we would not have had Drupal 8 in 2015. It sped the release of Drupal, which makes it the most accomplishment for our team in 2015.

Happy but not satisfied

Larry Garfield (Crell) wrote a blog post shortly after the release of Drupal 8 where he talked about how he was happy that Drupal 8 was released—and feels it is a huge leap forward for the project—but he is not satisfied because he sees how much work is left to be done.

That is the nature of software. It can always be a little better—more performant, more usable, more extendable.

Drupal.org improved in 2015, but the team is far from satisfied. There is so much more work to complete.

At DrupalCon Amsterdam, I outlined the top 7 initiatives that the Drupal.org team would focus on. When I look back on the year, we did not hit all of our goals.

In April, one year into my time at the Drupal Association, I could point back to a lot of accomplishments, but for many, the improvements were not fast enough. By DrupalCon Los Angeles, we had achieved one of our initiative goals, and moved forward many more, but we added four more to our list. In agile project management terms, we burned up (added more work) than we burned down (work completed).

While the fact that more work is requested faster than we could complete it is not unusual, it did make us think, and we learned some lessons. We have to focus on fewer, high impact priorities. We need to plan for the unplannable – we know there will be unforeseen needs from the community and new technology to support that may not exist yet, and we must be flexible enough to respond. We need to build more partnerships and find great solutions with technology providers that are experts in their fields.

We are pretty excited that much of the planning and design work put into 2015 should result in a much more rapid pace of change to Drupal.org in 2016.

What’s next for Drupal.org

So, we are celebrating all the good things from 2015—there were a lot—but we are also closing the book on what was a challenging year.

Our focus shifts now to supporting the community as we all work to make Drupal 8 successful. We’ll be keeping the Drupal.org Roadmap up to date and adding in new initiatives.

As we start the new year, we are still committed to the content strategy work that will make the content creation experience on Drupal.org and sub-sites better. This will improve our documentation as well as make it easier to talk about the benefits of Drupal to decision makers that help choose Drupal as the best content management framework for their organization.

Additionally, we are doing some exciting work to better support Composer on Drupal.org to align us with the rest of the PHP community as well as planning some much needed improvements to our Git workflow and developer tools.

Lastly, we are not done improving how we highlight contributions within the Drupal community. As Dries outlined in Amsterdam, Drupal is a public good. We need to highlight the great work that people around the world are doing in building Drupal and the community that supports it.

We can’t wait to get started on 2016!

Front page news: 
Drupal version: 

Drupal 8.0.0 released

Today we released Drupal 8.0.0, the first fully supported release of Drupal 8! This is the biggest update ever to Drupal, our open source content management platform. Here are just a few of the hundreds of improvements in Drupal 8:

  • In-context, what-you-see-is-what-you-get (WYSIWYG) editing and previews
  • Comprehensive content modeling out of the box with entities, fields, and views
  • Customization of content pages and even forms and administrative pages via the administrative interface
  • Full translatability and localization out of the box
  • Reliable configuration management for safe and straightforward deployment of changes between environments
  • Mobile-first, responsive, HTML5 output
  • REST-first native web services
  • Enhanced accessibility and WAI-ARIA compliance
  • Modern PHP standards and practices, with integration of popular libraries such as Composer, Symfony2, Guzzle, and Twig
  • Significantly improved front-end performance out of the box
  • Enhanced caching and best-of-class integration with CDNs and reverse proxies
  • Full compatibility with PHP7, and the PostgreSQL and SQLite databases
  • …And much more!

Screenshot of the Drupal 8 Quick Edit feature
Drupal 8 in action

With key modules like Views and Entity Reference fully included in Drupal 8 core, and many contributed projects already available for Drupal 8, you can start building new Drupal 8 sites right now, today. You can also use the crowd-sourced Drupal 8 Contrib Porting Tracker to get updates on the status of your favorite modules and themes, or read how you can help.

How do I upgrade my current site?

If you have a Drupal 6 or 7 site you want to upgrade, install or update the Upgrade Status module to get a customized, up-to-date report on the status of your modules and themes in Drupal 8. Once you are ready, Drupal 8 core also includes the Migrate module to update existing Drupal 7 and 6 sites to Drupal 8 directly. Migrate is marked “experimental” in Drupal 8.0.0, but will be fully supported in an upcoming release. Read more about how you can migrate from Drupal 6 or 7.


The DrupalCon Asia team cheering with Druplicon
Photo credit: pdjohnson

What about other versions of Drupal?

Drupal 8.0.0 marks several changes for Drupal releases. We will add new features to Drupal 8 every six months in minor releases, with bug fix and security release windows every month. The next bugfix release window is December 2, 2015, and next scheduled minor release (Drupal 8.1.0) is planned for mid-April 2016.

The release of Drupal 8 also means that it’s time to say a fond farewell to Drupal 6 after eight great years. Drupal 6 will reach its end-of-life (EOL) on February 24, 2016, meaning that it will no longer receive official community support and you should plan to update Drupal 6 sites soon. Refer to the Drupal 6 end-of-life announcement for more information.

Drupal 7 is still fully supported and will remain so for several more years. Read more about the Drupal core release cycle.

Found a bug?

With your help, we can find and fix bugs sooner rather than later. If you find a bug in Drupal 8, search for it in the Drupal 8 issue queue, and if you don’t find an existing bug report, file a new one.

Celebrating the release

Help share and celebrate this milestone for the Drupal community! The Drupal 8 media kit includes the official Drupal 8 press release which has already been translated into many languages. Share this press release with your community, or use the #Drupal8 hashtag to talk about Drupal 8 on social media. Then, join one of over 200 Drupal 8 release parties on six continents.

Map of Drupal 8 release parties around the world
Source: drupical.com

Drupal 8 core is the work of more than 3300 contributors in over 16,000 Drupal core commits during nearly five years of development, and it is by far the best release of Drupal yet. There are already more than 50,000 Drupal 8 installations, so start yours today!

Build something amazing, for anyone.

Front page news: 
Drupal version: 

Drupal 8.0.0 will be released on November 19, 2015

Based on our experience with our successful release candidates, we are confident to announce that Drupal 8.0.0 will be released on November 19, 2015! Until then, we will continue publishing Drupal 8 release candidates with the latest fixes. See the first release candidate announcement for more details on the release candidate phase, or download the latest release candidate (RC2) for a preview of the release.


Port your modules/themes and update translations

There is not a lot of time left if you are looking to have your module, theme or translation ready for the big day! Read more about porting your modules and themes and contributing to translations.

Preparing for release promotion

We are working on both the release announcement and the press release in English. However we do need volunteers to help translate it to their language. The final translations will be posted on Drupal.org at time of release.

If you can help promote the release on Twitter on November 19th and 20th in your respective time zones, Paul Johnson is looking for you. When tweeting about Drupal 8, be sure to use the hashtag #drupal8.

Parties around the globe!

We also need you to throw a party! Organize a local meetup on the week (or even better the exact date) with sweets, sessions, shirts, stickers or whatever fits to spice it up. Make sure to let the community know, so it shows up on the world map on Drupical.com We also suggest you follow @celebr8d8 and promote your party and share your party stories with #celebr8d8.

Finally, thanks to the nearly 3,300 people who contributed to the codebase of Drupal 8 as well as hundreds of others who organized events, conducted usability tests, mentored contributors, found sponsors, etc.—in short did all the awesome things that made Drupal 8 happen. Now, let’s go make something amazing, for anyone!

Front page news: 
Drupal version: 

Community Spotlight: Veronica Vedia (veronicanerak)

Veronica Vedia Profile PictureVeronica Vedia (veronicanerak) organized Women in Drupal at DrupalCamp Bolivia in 2014 alongside Karen Da Cruz and several other women. Veronica shared the story of how she went from anonymous Drupaler to community evangelist over email with the Drupal Association. Parts of this Community Spotlight have been transcribed from a medium.com article that Veronica wrote on her experience coordinating Women in Drupal.

I started using Drupal approximately 4 years ago. At the time, I worked in front-end, and I did my work in multiple different languages and frameworks, like PHP, C#, and Microsoft’s .NET. I really enjoyed working in front-end, but wanted to get more specialized. At one point, a coworker told me about Drupal roles, and the idea of becoming a dedicated “themer” caught my attention. I decided to study Drupal on my own so I could leave that company and find another employer where I could work in Drupal as a themer.

I didn’t become very active in my local community until after Drupal Picchu in 2014 in Cusco, Peru. Before that, I had been a relatively passive participant in the Bolivian Drupal community. But when I heard about Drupal Picchu, I knew I had to go. I admit, the chance to travel to Machu Picchu was my main motivation, but I also knew that attending the Drupal workshops and talks would be very valuable.

When I got to Drupal Picchu, I was amazed at how many passionate people were at the event. There were people with so much experience and talent sharing knowledge from basic to advanced. It really caught my attention how so many people were generously sharing knowledge that they put so much effort into learning. It was a really encouraging experience for me.

The event’s keynote was on Women in Drupal, and was led by Karen Da Cruz, Nancy Contreras, Molly Byrnes, and Holly Ross, all of whom are very inspiring women in the industry. I found their stories very motivating, and wound up talking to Karen afterward. I told her, “I want to do the same thing in my country that you have done here.” So I got together with several other women in my local community, and together we made the Women in Drupal group a reality at DrupalCamp Bolivia 2014 several months later.

At DrupalCamp Bolivia, Karen and I gave a “Women in Drupal in Bolivia” workshop where we taught several women Drupal. The goal was to motivate everyone (but especially girls and women) who are learning Drupal. The workshop was a success and it was amazing how enthusiastic all of our attendees are. It wouldn’t have been possible without all the amazing women who came out to help us conduct the workshop and replicate the Drupal Picchu keynote on Women in Drupal. It was really fun to participate in both the workshop and the the keynote, and I had a great time speaking about my own experiences alongside Nancy Contreras (Peru), Karen (Peru), and Mariana Graf (Brazil).

Organizing an activity like Women in Drupal in Bolivia was really intimidating at first. I was worried that there might not be attendees, or that our activities wouldn’t be well received. But everyone was so encouraging and helped me realize that the important thing is the desire to share knowledge — it’s normal to feel fear, and it’s worth overcoming it in the end. Without help from Karen, Freddy Cahuas, and the other DrupalCamp Bolivia organizers, I wouldn’t have succeeded. It also made me realize that one day, you’re new to the community, and the next day, you’re daring to try something new for the community. It becomes a chain where everyone helps each other and the community grows, and I think it’s really powerful how it breaks across the boundaries of languages and cultures and brings us closer to each other.

In the future, I hope to help grow the community and the “Women in Drupal” events. I want to motivate many other girls and women to learn Drupal. It’s a world of endless opportunities and possibilities! To make this happen, I am always looking for help from the community. If anyone has examples of activities that I could share to help boost, improve, and motivate my local community group, I would love to hear from you.

Thank you to everyone who continues to participate and encourage each other to be part of this big family called “Drupal”!

Drupal 7.40 released

Drupal 7.40, a maintenance release with numerous bug fixes (no security fixes) and several new features, is now available for download. See the Drupal 7.40 release notes for a full listing.

Download Drupal 7.40
Upgrading your existing Drupal 7 sites i…

Community Spotlight: Jibran Ijaz (Jibran)

Jibran Ijaz (jibran) is a Drupal developer, and is the only Drupal Core contributor in Pakistan. A member of Drupal.org since he began building websites in 2010, Jibran has become an important member of both his local community and the greater global Drupal community. The Drupal Association spoke with Jibran over email and asked him a few questions. We’re excited to share the conversation with you.

How did you get involved with Drupal and core contribution?

Back in December 2010, I started working as a freelancer on a Drupal 6 site with a friend. It took me a while to understand all the systems like nodes, cck, views, and themes, but I was finally able to find my way. At the time, Drupal 7 RC versions had only just begun being released, so when Drupal 7.0 came out I had to learn a lot of things all over again. For me, the new built-in Entity API and Field API were difficult concepts to understand. It took me a while to understand the changes in theme layer, learn about html.tpl.php, and understand the Render API. These things were so confusing to me that I wound up submitting my first core issue related to documentation.

After going through this learning curve twice, I thought I might as well start learning Drupal 8 now. So I started hanging out in the core issue queue, and began reading a lot of Drupal 8 blog posts on Drupal planet. One day, I read that they were moving all the Drupal Core files to the Core directory and they needed help in re-rolling a lot of trivial patches. I went and found a documentation novice issue in Drupal 8 and helped fix it both for Drupal 8 and for Drupal 7. After that, I was hooked.

What do you do with Drupal these days?

I’m a senior Drupal developer for PreviousNext, where I work remotely from Lahore, Pakistan. I mostly work on large Drupal 7 sites, but lately I have started working on a Drupal 8 site as well. It’s fun to work with such a great team of front-end developers, back-end developers, and project managers at PreviousNext.

In my free time, I contribute to Drupal. I do a lot of code reviews. Specifically, I love working on Views issues in Drupal 8. I have also been actively involved in a lot of contrib projects and have been helping with porting them to Drupal 8. During the weekends, I enjoy working on dynamic_entity_reference.

You’re involved with quite a variety of projects in the Drupal community and in your national Drupal community as well. Can you describe some of the things you do and why you like them?

Ever since my childhood, computers have fascinated me. Even though my bachelor’s degree is in Telecommunication Engineering, I always loved coding. This means my involvement with Drupal is almost always related to coding. I enjoy solving bugs, writing patches, and performing code reviews. I also like to get involved in technical discussions related to Drupal, and really enjoy helping others understand difficult Drupal concepts, so I mentor people as well.

In Pakistan, we have a very enthusiastic Drupal community. The Drupal Association has helped us with organizing numerous camps, workshops and training opportunities in different cities all over the country. I wasn’t actively involved with local community until about a year ago when I talked to Donna Benjamin (kattekrab), who was the director of community engagement at PreviousNext at the time. Donna encouraged me to participate a lot more in my local Drupal community, so I took part in my first Drupal Camp at Lahore on 3 May 2014. I was the only core developer there, and my fellow attendees were very appreciative and welcoming. At the camp, I talked about Drupal 8, and everybody loved it. So I’ve been attending ever the Drupal Camp I can get to ever since. I was even a keynote speaker at Drupal camp Islamabad back in April.

What’s the coolest project you’ve worked on?

I have worked on a lot of Drupal projects with very complex architecture. It’s always fun whenever I get to use a big module like Domain Access, Services, Commerce, Ubercart, Google Maps, or Organic Groups to build features for our clients. It’s also fun when I get to build a complex architecture using Drupal API. I’d prefer not to name a specific project, though. It would feel like I’m pointing at my favorite kid.

What changes are you most looking forward to in Drupal 8?

Oh! The simple answer is everything. The change form Functional Programming to Object Oriented Programming is the most important thing for me. Personally, I also like the built-in plugins system of Drupal 8 because if you’re familiar with the plugin API, you can easily use it in Blocks, Entities, Fields, Menus, and Views. Even Drupal 8 contrib modules like Rules and Page Manager are doing a lot of amazing things with plugins.

What is your favorite thing about the Drupal community?

I love the Drupal community as whole, and am inspired by the fact that we all share the same enthusiasm towards Drupal. It doesn’t matter who you are or what the scope of your technical knowledge is — anyone and everyone can make a difference in the community. I spend a lot of time with Drupal developers on IRC, at local and international Drupal events, and I haven’t found a single person who isn’t kind and helpful. No matter how many times you ask the same question or a stupid question, everyone always responds very kindly. No one has ever treated me differently because of my religion or region. Every person I have met in the Drupal community has inspired me on some level, irrespective of their contribution in Drupal. That is my favorite thing about the Drupal community.

What is your most meaningful Drupal moment?

Drupal has given me a lot of beautiful moments. It’s very hard to pick one, so I’ve listed several below.

1. First time I attended DrupalCon. Picture by @lsheydrupal
DrupalCon Amsterdam entryway

2. First time I met with webchick
Angie and Jibran at DrupalCon

3. First time I got a shout-out from webchick on my Drupal contributions at DrupalSouth
Webchick at DrupalSouth

And there are countless other moments, like my keynote at Drupal Camp Islamabad, hanging out with VDC team at DrupalCon code sprint, meeting with the whole PreviousNext team for the first time, and dynamic_entity_reference hacking with Lee Rowlands after the DrupalSouth code sprint.

Tell us a little about your background or things that interest you outside Drupal.

Before computers, my first love was math. I like to read, but lately I haven’t been able to read many books. I can speak and understand a bit of Arabic, French, and German. I love to learn new stuff and experiences new things in life. I like watching football and Formula1, and I also watch a lot of English TV series and movies. Now I know why I don’t have time to read anymore. 😀

Secure your account: Two Factor authentication on Drupal.org

Drupal.org users* can now use Two factor authentication to increase the security of their accounts. It can be enabled via Security tab of your user profile page. Read the detailed instructions at Enabling TFA on Drupal.org.
This was made available to D…

Drupal.org Git Server Migration (2015-07-09 20:00-22:30 UTC)

On July 9th 8pm UTC, Drupal.org migrated to a redundant cluster of 2 servers. This provides failover in the event one server fails.

After the migration Host keys will change and your client might give an error message when pushing to Git. Consult your OS’s documentation on how to fix this error.

ssh-keygen -R git.drupal.org  && ssh-keygen -R 140.211.10.43

Should fix the warnings.

If you have any questions please raise an issue in the infrastructure issue queue. https://www.drupal.org/project/issues/infrastructure?categories=All

You can follow the progress of the migration at http://twitter.com/drupal_infra

Update: migration was successful

Host keys have changed and your client might give an error message when pushing to Git. Consult your OS’s documentation on how to fix this error.