Drupal Feeds

To err is human, and coders too, like us are humans and are bound to make mistakes while coding, especially if the needs of the project are complex and if they adhere to the true meaning of agile.

Palantir.net's Guide to Digital Governance: Private Websites, Intranets and Portals Palantir.net's Guide to Digital Governance brandt Mon, 12/05/2016 - 17:56 Scott DiPerna Dec 5, 2016

This is the eleventh installment of Palantir.net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.

In this post we will cover...
  • Questions you should consider specifically related to private websites
  • Why you should think about whether your private site should be a part of your public site
  • Why it's important to serve the needs of site users

We want to make your project a success.

Let's Chat.

Most organizations these days have some form of private area for only staff, group members, constituents, partners, vendors, etc. These sites are sometimes guarded behind a firewall and a user authentication system, sometimes just user authentication, and sometimes simply hidden by obscurity. Most often, though, you can identify one of these types of sites because it requires a login and password and is not generally accessible by the public.


Most of the previous questions, regarding content, organization and design are relevant to internal Web properties as well, but here are a few questions you may want to ask yourself specifically with regard to private websites, intranets, and internal-facing portals:

  • Who owns each one? If they are shared responsibilities, what are the parts and who owns each part?
  • How are accounts distributed and access granted?
  • Who determines access and account creation?
  • What is the process for account creation?
  • What is the criteria for gaining access via an account?
  • Do user accounts have different roles with different permissions?
  • Who are the content editors and creators within the site?
  • How is the site edited and maintained?
  • Are there any workflows or approval processes for content?
  • What distinguishes content that is appropriate for external channels from content that is only appropriate for internal channels?
  • Who will be responsible for determining what is appropriate? And how will they enforce those rules?

Public vs Private

Another important consideration for private websites and intranets, especially if you are planning to build one or redevelop your public website, is whether or not an intranet (or a private website) should be a part of your public website. In other words, should the same system for administering and maintaining your public website be the same system as your intranet or private website?


On the surface, the simple answer may appear to be, “Of course! Wouldn’t that be the most simple and streamlined approach?” Once you dig into the requirements of what you need for your private site, and compare that with the purpose of your public site, you may determine otherwise.


Why?


The most common purpose for a public website is to communicate information about your organization to a range of audiences, many of whom are not currently part of your organization. In fact, the primary purpose of your public website, specifically, may be to attract those who are not part of your organization in order to convince them to become part of it. In short, your public website’s primary purpose is likely to be a marketing tool for expanding your message and growing your constituency (membership, clientele, user-base, however you think of them). There is not typically a lot of functional interaction that happens between user and website at this stage, aside from asking visitors to contact you, sign-up up for something, attend an event, purchase a product, or some other interaction that is typically managed by a relatively basic form.


In other words, the necessary functionality for a public, marketing website tends to be fairly light in terms of the weight of its programming logic and requirements.


Intranets and private websites tend to be a different animal. Being private, by definition, means they need to support accounts for users. Having a lot of users logging into a system presents a number of challenges and requirements that can become quite complex. A heavier set of tools are often required, adding more software to the system.


Given that users and authentication credentials are involved, often integrations with user databases or user management systems may be involved, and almost certainly, a higher level of security and encryption becomes necessary.


Usually, when you have a private site or intranet, the needs of users become more transactional than consumption marketing information. Once a user is a member, they no longer need to be sold on the organization; they need to “do” things through the website – use tools, access account information, transmit or receive private data, etc. All of these things require deeper levels of programming, security, and the infrastructure to support it – a lot more heft and complexity than what you need for your marketing website, which probably benefits most from being nimble and quick to deliver relevant content.


Perhaps most important, though, is the organization of information – and this is where many projects that aim to combine a public website with a private intranet get bogged down. Since the two sites address the needs of largely different audiences, the menuing and navigation in sites that aim to serve both public and private needs are often in conflict with themselves. 


Rarely do you want to show navigation, menuing, or content to the public which is meant only for private users. However, how do you then present the private content and way-finding to authenticated users without breaking a design that, in theory, looks appropriate for only the public content and navigation?


As you get into the details of accommodating both public and private needs on a website, what you often find is that you make odd compromises to things you ordinarily wouldn’t (like usability of the site), in order to make the two work together. In truth, given that the audiences for the two sites may have very different needs, and the websites need to serve very different purposes, it is often wise to separate the two, even if that means support of two separate systems. In the end, it is better to serve the needs of the users, such that they can be successful using your websites.
 

 

This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:

  1. Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
  2. Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
  3. Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
  4. Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
  5. Roles and Permissions – Define who should be able to do what in each system.
  6. Content – Understand how ownership and permissions should apply to content.
  7. Organization – Establish how the content in your digital properties should be organized and structured.
  8. URL Naming Conventions – Define how URL patterns should be structured in your websites.
  9. Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
  10. Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
  11. Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
  12. Web-Based Applications – Consider use and ownership of web-based tools and applications.
  13. E-Commerce – Determine the role of e-commerce in your website.
  14. Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
  15. Social Media – Set standards for the establishment and use of social media tools within the organization.
  16. Digital Communications Governance – Keep the guidelines you create updated and relevant.
Switching from custom installation profile to lightning on existing drupal sites

In one of my recent client project, we had the requirement to move to lightning profile from custom installation profile, so that they would be able to use the lightning features OOTB. During the POC we found different approaches of using/consuming the lightning features, but we planned to use the lightning extend approach.

In Drupal7, there was pretty easy way to do was to update the install_profile variable

$ drush vset --exact -y install_profile standard

There is an alternate way of doing this is directly is updating the variable name directly in the schema.

In Drupal8, there was not any module that allows to switch the profile like in Drupal 7 there's the profile_switcher module. 

In Drupal 8, the installation profile information has been moved from config to key value store.

drush sqlq "DELETE FROM key_value WHERE collection='system.schema' and name='lightning'" drush sqlq "INSERT INTO key_value (collection, name, value) VALUES ('system.schema','lightning','s:4:"8004";');"

Here are the list of things that should be taken care before switching the profile on existing Drupal site :

  • All the enabled modules should be present in the new installation profile, if the modules would not be there then there would be issues come up
  • Do the clear the cache

Next article:  Switching to Features from Configuration Management

naveenvalecha Tue, 12/06/2016 - 18:08
Drupal Modules: The One Percent — Masonry Views (video tutorial) NonProfit Tue, 12/06/2016 - 06:43 Episode 10

Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Masonry Views, a module which will help cleanup the display of our Views grids.

The TWG coding standards committee is announcing three coding standards changes for final discussion. These appear to have reached a point close enough to consensus for final completion. The process for proposing and ratifying changes is documented on the coding standards project page. A change to this process is being proposed to streamline the interaction between the coding standards body, Drupal Core, and the Coder project, please provide any feedback on that issue.

Announced for final discussion: Official coding standards updates now ratified: Formerly announced issues that need an issue summary update

These issues have a lot of support but need an update to formalize the proposal so that they can be ratified and applied.

- [Agree on a property naming pattern](https://www.drupal.org/node/1233394) - [Coding standards for breaking function calls, function declarations, and language constructs across lines](https://www.drupal.org/node/1539712) - [Add type hinting to function declaration coding standards](https://www.drupal.org/node/1158720)

These proposals will be re-evaluated during the next coding standards meeting currently scheduled for December 20th. At that point the discussion may be extended, or if clear consensus has been reached one or more policies may be dismissed or ratified and moved to the next step in the process.

Do you still operate a Drupal 6 website? Are you getting questions from your management team, technical teams or even board of directors on pending upgrades? Are they afraid of the Drupal 6 "End of Life"? What should you do? What should you tell them? Read more to hear some brief thoughts on the big decision!

It’s one of the hottest tools in the Drupal 8 toolkit: the Migrate API, now part of Drupal 8 Core.

If you know how to use it, you can dramatically improve how quickly and efficiently you can upgrade a site to Drupal 8. In addition, you can use it to build regular, repeatable migrations in Drupal 8 that can pull in data from a variety of sources.

That’s why you should tune into this Tech Talk by Adam Jensen, Technical Account Manager at Acquia: (Don’t Hate) Migrate in Drupal 8.

Tags: acquia drupal planet

The Drupal Association and the volunteers that contribute to DrupalCon strive to make our conference an inclusive and welcoming environment for all who come. We're actively seeking to increase the diversity of our speakers, attendees, and sponsors at DrupalCon Baltimore.

Like so many of you, both here in the United States and elsewhere, I am deeply troubled by the incidents of hateful harassment and the threats to democracy that have spiked since November 8. My thoughts have been routinely consumed with the task of analyzing my work and motivations, trying to detect any positive impact that my contributions have on the world. Because of my involvement in the Drupal community, my thoughts are as much about Drupal as they are about me. I am a proud member of our community and I cannot help but reflect on how the organization of our community brings people together, discourages hate, and promotes democracy.

What it would mean to "make the world better" is up for debate. We cannot be experts in all subjects, and a group of Drupal developers might not fully understand, for example, the policies that allow tax havens, the economic implications of a $15 minimum wage, how to combat predatory lending, or the solutions to climate change. Perhaps we have strong opinions on these topics, but many of us would begrudgingly admit that we know more about dependency injection, re-rolling patches, or even the hook system. That is, we know how to build Drupal websites. More importantly, to succeed in the Drupal community we are required to be considerate, respectful, and collaborative. We, as a community, vigorously reject bigotry, racism, sexism, homophobia, and xenophobia. This, in my view, makes the world better.

What is more, I would argue that Drupal blurs traditional boundaries. While certainly there are market forces that determine how Drupal is constructed, powerful legal and cultural nonmarket forces push back. Some Drupal agencies exist to turn a profit, but do so working primarily with public sector or non-profit organizations. Drupal agencies can be seen as capitalist in the sense that they accumulate surplus value by "exploiting the working class," but socialist in the sense that they produce goods that are owned collectively. Some have stated goals to invest value back into the community and others are "benefit corporations," required to make the world a better place. While I am tempted to place new labels on the Drupal community, such as "post-capitalist," I find such terms to be of limited use, and I am far more interested in finding common ground that unites our community.

Drupal code has only limited value without the community, and our community stands for values that transcend our code. I participate in the Drupal community because I believe it represents ideals that are consistent with my own. One of the beliefs that we hold in high regard is "doing good." It would be difficult to convince me that people, such as George DeMet and Tiffany Farriss, Todd Ross Nienkerk, or Lev Tsypin, have anything but the best intentions in the way they run their businesses. More importantly, these individuals, like so many others in our community, actually do make the world a better place through their work, compassion, and advocacy.

In some respects, the well-intentioned subset of our community exemplifies what Luc Boltanski and Eve Chiapello describe as "the new spirit of capitalism." In their study of management textbooks, they find this "new spirit" is characterized by, among other things, a "high moral tone" (58), a belief that workers should "control themselves" (80), structures where managers are essentially replaced with customers (82), and where bureaucracy represents a kind of "totalitarianism and arbitrariness" that should be avoided (85). While Boltanski and Chiapello find many faults with this "new spirit," generally, I would suggest that is has become more important than ever to acknowledge the many benefits that the people and organizations in our community have for the world. While critique and criticism will surely be needed, we should also continue to celebrate the impact that our software and colleagues plays in efforts towards ending poverty, empowering independent journalists, defending the free and open Internet, and educating people. Even though Drupal has been used for nefarious purposes, and there are many reasons to critique the Drupal community, I feel emboldened knowing that when people came together to build websites for DeanSpace, the United Nations, Amnesty International, Greenpeace, Oxfam, the ACLU, the Electronic Frontier Foundation, National Public Radio, Free Press, and the White House, they choose Drupal.

More than just software, part of the reason we "stay for the community" is because we place such a high premium on human interaction. Drupal contributors create public goods (free software) that can be used by one person without reducing the availability to others. If the public relations departments of mega-corporations extol the value of business and markets, while criticizing government and fair labor, the Drupal community takes an alternative approach that values solidarity. In this sense, our democratic practices threaten unjust power. Throughout history people in power have pushed back against the democratizing effects of solidarity to defend their positions of power. In his 1776 magnum opus on political economy, Wealth of Nations, Adam Smith famously observed, "All for ourselves and nothing for other people, seems, in every age of the world, to have been the vile maxim of the masters of mankind." With every Drupal Camp, DrupalCon, code sprint, community summit, and user group meeting we gather together in solidarity. Let us not forget all we do to encourage hope and camaraderie.

If you are discouraged by a world that turns workers against each other and treats citizens as consumers, pushing them to the malls rather than the public library, remember that we as a Drupal community are pushing back against the "masters of mankind." In the 1970s, Buckley v. Valeo may have determined that money is a form of speech, but because we work together, Drupal becomes another kind of speech. Most of us (the working class) must sell our labor in return for a wage or salary. So what I am arguing is not for our community to become noncommercial or anti-commercial, but instead that we consider expanding our horizon of expectations to allow for a conception of Drupal as a political act. I want us to celebrate our community and stand up against hate, inequality, corruption, and depoliticization. If that idea makes you uncomfortable, then perhaps consider the words of the historian Howard Zinn and his suggestion that what matters are "the countless deeds of unknown people who lay the basis for the events of human history." I hope that we can find common ground, build on what we have accomplished, and organize against the forces that seek to divide us against ourselves.

Manage drupal 8 site configuration with features

There are several ways to manage the drupal site configuration in Drupal 8 either by keeping it in the database or managing it at from the file system or managing with features.

I have launched couple of sites with the combination of the following best practices with managing features and configuration in file system

User Roles and Permissions are being managed by the Configuration Management because features does not export the permissions with the Roles
Using features for managing the other entities and rest of the stuff.

Below the screenshot of attached site structure of one my project

 

naveenvalecha Thu, 12/08/2016 - 00:04

Upgrading websites off of legacy platforms and onto Drupal is a pretty common request. One of the most helpful contributor developed modules, Migrate, is now in Drupal 8 core, which really solidifies Drupal as a great choice when having to make the decision of which CMS to go with when upgrading.  

As Drupal, the Project, keeps growing and changing, so does DrupalCon. As the Events Team at the Drupal Association, we are continually working to improve the event - to strengthen the programming and to better fit the needs of attendees. Over the past year, we've heard through both formal and informal conversations that DrupalCon sprints are ready for a change.


A consistent topic in those conversations was that Extended Sprints, held on weekends before and after DrupalCon, may be too much. While 9 days of sprinting at previous DrupalCons evolved informally, they were a key part of the hard push that got Drupal 8 out the door. Concerns were raised that it is not healthy for contributors to continue at this pace. Contributors said that they were a little burnt out and didn't need as many days of sprinting.


A few weeks ago, we met with some of the sprint leads to discuss DrupalCon sprints to really hear what the Project needs at this point in its life-cycle. What we heard was: "Shorter sprints, with greater support." Based on this conversation with sprint leads, informal conversations from community members, and some feedback from the attendee survey, DrupalCon staff will no longer be organizing weekend Extended Sprints at DrupalCon going forward.


We will continue to support full day sprints from Monday through Friday. There is a dedicated sprint room throughout the week at the convention center, open Monday through Friday, as well as a designated location at the host hotel for 24 hour sprinting sessions. Sprint mentors are available at the DA sponsored mentor table in the exhibit hall throughout the conference to answer any questions about the contribution process, help new contributors pick which sprint best fits them, encourage new mentors to join Friday, and help both new contributors and new mentors know what to do to prepare for the sprints on Friday. We will concentrate our support on providing sufficient quality sprint space, and lunch and coffee, sprint room signage, supplies, special t-shirts for mentors, etc. - things that will help everyone have a quality productive sprint experience.


With these changes, our main objectives for DrupalCon sprints are to support current contributors, bring in new contributors, and nurture those who've dabbled, but not fully jumped in. We believe this is an imperative for the health of Drupal.


If you've attended a sprint at DrupalCon in the past, we certainly hope you will join us again in Baltimore. Our full conference website launched this week - be sure to check out the call for papers, buy a ticket, or apply for a scholarship.

Personal blog tags: drupalcon
D8 autocomplete search items in custom module JK Thu, 12/08/2016 - 10:37 This script will help display the results of a search by keyword instantly via an ajax call in a custom module. It can be applied to various search types. From user point of view it creates a good user experience and efficient working flow.
We recently decided that at the beginning of every month we will look at the topics we covered in our blog posts in the previous month. So, we began last week with our first overview. But we were not satisfied only with that. Therefore, we decided to also look around and gather for you the best Drupal blogs that other authors have written over the past month. Here's our first selection, which includes blogs, which were written in November. We'll start with the most obvious one. It's the one from the founder Dries Buytaert, who dedicated his post to the first anniversary of Drupal 8. He… READ MORE
Diversity Matters

This blog post was intended to be a recap of DrupalCamp Munich. It was a very well organized conference but the event was overshadowed by an intense discussion about diversity. This is why I want to focus this blog post on the learnings and takeaways from Munich regarding diversity at Drupal community events.

Josef Dabernig Thu, 12/08/2016 - 10:41

Setting the scene

On the day before DrupalCamp Munich, a discussion about diversity came up on Twitter and at the sprints venue where organizers were working hard on preparing for the conference. There were two related sources leading to the discussion. First of all, as Ekes pointed out via Twitter - out of 47 speakers there was only 1 woman on the agenda (2%). This is already saddening but the big attention came to happen when Twitter found out that copies of a men's lifestyle and entertainment magazine were about to be handed out to participants as part of the goodie bags.

The initial responses by the organization team were defensive rather than acknowledging the problem, basically stating that the event team can’t fix the problem of there not being enough female speakers at the conference. After a while penyaskito cancelled his session: he wouldn’t because of the two issues but mainly the lack of action and communication around them. By the end of the day, the DrupalCamp team published an official statement of apology.

I cancelled my session at #dcmuc16. Hoping you learnt from to community's feedback for next events. Thanks @Lingotek for supporting me pic.twitter.com/IwXGkADTIE

— penyaskito (@penyaskito) December 2, 2016

Thinking about the facts

I’m glad to see that the issues have been taken seriously. Obviously there was a different perception of the severity of the problem. From my personal experience, bringing in diversity into tech events is a challenge, especially when they are organized by teams that aren’t diverse in the first place.

But if we look at the data, we can see that DrupalCon New Orleans (19% female and 81% male), DrupalCon Dublin: (17% female, 82% male) had quite similar ratios. Even though they still have a long way to go to improve this, they’re better than what we accomplished for DrupalCamp Vienna (13.6% female and 86.4% male). With DrupalCamp Munich only achieving 2% female speakers, I think this is a very alarming sign that we have to react upon and therefore support the call for action very much.

Everything back to normal?

The discussions were quite heated, especially on Twitter. Special thanks to Jeffrey “jam” McGuire for following up with a blog post on “Empathy, diversity, and open source”. Aside from agreeing on the problem, Jam acknowledged the hard work and best intentions of the local team to host a good conference. I think it is important to see & hear both sides of the conversation and from there continue the discussion.

And this happened through lots of talks - both online and onsite at the camp. On Saturday evening, we had a big “Diversity Matters” BoF. 7 women and 48 men discussed the issues with live notes taken.

Some of the important takeaways from the discussion for me where:

  • Diversity needs to be looked at on all levels.
  • Providing safe spaces is needed to support minorities in joining a community.
  • A code of conduct is a good foundation but needs to be lived.
  • We need to listen to the views of others before defending our own viewpoints.

Where can I get more help with this?

We are not alone in this. To figure out how to get better diversity at Drupal events in Europe, we can look at role models and the support they provide by leading by example.

JSConf for example, has documented how they reached 25% women speakers already in 2012. Their call for speakers highlights how they offer support to attendees to become confident about their wish to speak. They also embrace an anonymous submission process. If you want to find out more, you can check out “We Are All Awesome” for some great materials for both speakers and curators.

In Drupal, Ashe Dryden’s session from DrupalCon Portland provides a good overview of why diversity matters. If you want to help or join the discussion: Drupal Diversity is a working group discussing diversity & inclusion in Drupal and web development. They have extensive resources on why we should care and what we can do to improve diversity. On the Drupal slack, find us in the #diversity-inclusion channel with more than 100 members already. Also the Drupal Community Working Group is working on a response to the happenings. You can also follow them via Twitter.

What did I learn?

Since I joined the Drupal community, diversity has been important to me. One of the reasons why I joined Amazee was that I was looking for a more diverse team to work with. Working with a diverse team is still a privilege in our industry and I would like to see a bigger movement towards getting better diversity across the whole industry.

The recent incidents have made it clear to me that this needs to go further though. It’s not enough to simply say “we want more diversity”. We need to look at diversity as a common goal and everyone of us need to make more effort in order to achieve it.

The DrupalCon Baltimore call for sessions just started and shows a clear effort to inclusivity. Optionally, speakers can identify with underrepresented communities to help the session selection team ensure better diversity in the program. Also read their blog post about setting diversity as a DrupalCon goal.

As part of the Drupal Mountain Camp team, this discussion has inspired us to focus more on diversity. We agreed to think about it on all levels:

  • Promote diversity and the code of conduct on all levels of the event.
  • Set and communicate diversity as a goal for the session selection process.
  • Actively encourage diverse speakers to attend.
  • Offer support to speakers via coaching & mentoring.
  • Provide a safe and healthy environment for all attendees.
  • Educate ourselves as event organizers by reading materials stated above.

I’m looking forward to strive towards this goal for more diversity in Drupal.

We have been extremely hard at work this year with the Workflow Initiative bringing some quite big...

With Acquia Lightning, site-builders or developers can build an authoring experience from the ground up in only a few hours.

Think of Acquia Lightning as “Drupal Core with afterburners.”

Development tasks that used to take days or weeks are condensed to a matter of minutes.

Tags: acquia drupal planet
Switching from file system configuration management to features on existing drupal site

In my last blog post, I outlined the best practices to manage the configuration management for the site. If you have read the previous post and wanted to follow the same on your site, this post will show you how to do Switching from file system configuration management to features on existing drupal site easily.

There's not any hard and fast way to change the configuration management for an existing Drupal site. Here are the steps in brief involved in to do the following:

  • Delete all of the old configuration except user roles and permissions
  • Export all configuration using features
  • Add update hooks to start using features

Delete all of the old configuration: Delete all the configuration which is present in your $config['sync'] directory except the user roles configuration.

Export all configuration using features: Export your configuration with features and make sure to leave the user roles and permissions and manage your user roles and permissions configuration via the Filesystem.

Add update hooks to start using features: Add update hooks to enable the new features.See the same hook_update_n below.

/** * Install features based config. */ function xyz_core_update_8017() { $features = [ 'xyz_f_alert', 'xyz_f_appointment_request', 'xyz_f_page', 'xyz_f_blog', 'xyz_f_career_area', 'xyz_f_careers_landing_page', 'xyz_f_common_formats', 'xyz_f_doctor', 'xyz_f_education_research', 'xyz_f_event', 'xyz_f_foundation', 'xyz_f_job', 'xyz_f_location', 'xyz_f_news', 'xyz_f_paragraphs', 'xyz_f_person', 'xyz_f_procedure', 'xyz_f_related', 'xyz_f_search', 'xyz_f_site', 'xyz_f_testimonial', 'xyz_f_user', ]; \Drupal::service('module_installer')->install(['features', 'config_update']); \Drupal::service('module_installer')->install(['xyz_bundle']); \Drupal::service('module_installer')->install($features); }

 

naveenvalecha Thu, 12/08/2016 - 22:45

Read our Roadmap to understand how this work falls into priorities set by the Drupal Association with direction and collaboration from the Board and community.

The engineering team at the Drupal Association had much to be thankful for in November. With the support of the wonderful volunteers in our community and the contributions of our Supporting Partners we were able to deliver some great tools for the project. Let's dive and see what's new.

Drupal.org updates Promoting Drupal by Industry

In November we finished the technical scaffolding for the upcoming industry pages, and began working with the wider Association team on content development for these pages. Because we were ahead of our internal targets for this page and we felt it would add significant value, we've also added the ability to geotarget content on these industry pages.

This is the first instance of geo-targeting on Drupal.org, and we'll be using it to help connect Drupal evaluators with regionally appropriate content and partners on these pages. Work on the industry pages is ongoing, but we're excited to bring them to you soon.

Developer Tools Evaluation

During November the engineering team also had a two day retreat here in Portland, OR with webchick - one of the members of the Technical Advisory Committee. We used this retreat to do a deep dive into the current state of developer tools on Drupal.org, and to evaluate our options to continue evolving the tools we offer to the community.

We gave a summary of our exploration along with some next steps to the Drupal Association Board on November 22nd. You can find the minutes and a recording here.

Core release packaged with --no-dev composer dependencies

Starting with the Drupal 8.2.3 release, we are now packaging full releases of Drupal core with --no-dev composer dependencies. This means that packages downloaded will not include extraneous developer extras that should not be used in production sites, and that the release packages will be smaller. We will continue to package dev releases with the dev dependencies.

Feature branch testing support

Drupal.org allows maintainers to create feature branches for issues by using the name format [issue#]-[short-description]. Any commits made to a branch in this format will appear in the sidebar of the associated issue. To improve the utility of these feature branches, DrupalCI patch file tests now also run on push to these branches.

To add tests, users can simply click on the 'add test' link beneath the git branch in the issue sidebar, or click on the existing test result bubble to re-test or add a new test. Since this feature was introduced we've run over 200 issue branch tests.

Project maintainers can add Documentation Guides


We're continuing to support the migration of documentation to the new documentation system, and we've now enabled Project Maintainers to add related documentation guides to their projects. Once added, the related projects will appear on the documentation guides, in the sidebar.

Documentation Maintainers can find their Guides

Many community volunteers have stepped up to become maintainers of the new documentation guides. We want to make sure we're giving them the tools they need to do the work of maintaining those guides and the pages within them.

We've added a 'Your Guides' section to the user profile which will list all of the guides that a user maintains, as well as the pages within those guides. This should allow maintainers to see when pages have been recently changed or added, and to easily keep their guide content curated and up to date.

Infrastructure Virtualization and Improved Config Management

In November, we completed the majority of two major infrastructure projects. Firstly, we've virtualized the majority of the infrastructure and standardized on Debian 8 images. Secondly we've updated our configuration and user management from Puppet 3 + LDAP to Puppet 4 + Hiera. This is a significant milestone for our infrastructure, and gives us a more portable and maintainable infrastructure to manage moving forwards.

Community Initiatives

Community initiatives are a collaboration; with dedicated community volunteers building improvements to Drupal.org with the architectural guidance and oversight of the Drupal Association engineering team.

Drupal 8 User Guide Launched!

We're very happy to say that the Drupal 8 User Guide is now live on Drupal.org! This documentation guide is carefully curated to provide all the information a new user needs to become skilled at managing a Drupal 8 site. We want to give a special thanks to jhodgdon for all her work on the User Guide project.

Initiatives need your help

Are you a Drupal.org power user who relies on Dreditor? Markcarver, who is currently leading the charge to port Dreditor features to Drupal.org, has invited anyone interested in contributing to join him in #dreditor on freenode IRC or the Dreditor GitHub.

Is the written word your domain? Consider putting your skills to use by becoming a maintainer of Drupal documentation. If you are a developer interested in contributing code to the new documentation system, please contact tvn.

———

As always, we’d like to say thanks to all the volunteers who work with us, and to the Drupal Association Supporters, who made it possible for us to work on these projects.

If you would like to support our work as an individual or an organization, consider becoming a member of the Drupal Association.

Follow us on Twitter for regular updates: @drupal_org, @drupal_infra

Pages