Drupal Planet

Subscribe to Drupal Planet feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 3 hours 50 min ago

Hook 42: Field Notes: UI Patterns Module

December 27, 2017 - 10:44am

When it comes to Atomic Design systems in Drupal 8, there’s hardly a shortage of solutions to choose from. Pattern Lab and KSS Node are certainly among the most popular and the recently released Mannequin looks incredibly exciting. However, in all these aforementioned solutions, exposing that component data to Drupal has never been particularly straightforward.

Here at Hook 42, we’ve just finished developing a brand-new Drupal 8 site for a client that utilizes UI Patterns, Paragraphs, and Display Suite to allow content users to construct complex but consistent user interfaces. What follows is our “field notes” from implementing UI Patterns in a production site.

Categories: Blogs

Tandem's Drupal Blog: How To Stop An Intelligent Spambot

December 26, 2017 - 8:00pm
December 27, 2017 Most sites are susceptible to spam bot attacks regardless of what you may have installed. This little trick will aid in preventing bots from swarming your site. This article focuses primarily on stopping spammers via PHP and Drupal. However, the same principle can be applied to any language and CMS. What are Bots Spambots are...
Categories: Blogs

WeKnow: A first taste of Drupal theming using Pattern Lab

December 26, 2017 - 6:37pm
A first taste of Drupal theming using Pattern Lab

A few months ago I had the pleasure of starting a new journey in my professional career, joining the weKnow family. This was a natural step after collaborating in the last couple of years with Jesús and Enzo in open source projects like DrupalConsole. Right from the start, working to reach our projects’ milestones has been a really fun adventure, with lots of new knowledge and lessons learned along the way.

One of my first projects was leading the effort to rebuild weKnow’s new site. Most of you can probably relate to the fact that 'you are your toughest client', which is why we needed to strategize intensely before deciding on what approach to use, we treated this project as a functional prototype for the implementation of our new workflows in future projects with our clients and partners.

omers Tue, 12/26/2017 - 22:37
Categories: Blogs

DrupalEasy: Drupal Career Online, Fall 2017 Graduates!

December 26, 2017 - 11:39am

We'd like to introduce the Fall, 2107 graduates of Drupal Career Online (DCO), DrupalEasy's exclusive 12-week, live online Drupal training program. This is our 11th graduating class and the first of our recently updated all Drupal 8 curriculum.

Class members include (from top, left):

  • Michael Anello (instructor)
  • Adrian Nolt
  • Lisa Streeter
  • Jared Nolt
  • John MacDonald
  • Steve Versteeg
  • Alona Kotliar
  • Evrim Campbell
  • Donald Sangster
  • Madeeha Kahn (not pictured)

While many of this semester's graduates have pre-existing full-time jobs, several are aspiring Drupal contractors and consultants, so if you're looking for a junior level Drupal developer or intern, don't hesitate to let us know

This semester's class included Drupal 7 site builders looking to learn Drupal 8 workflows and module development, a WordPress developer and a self-taught Drupal 8 developer looking to learn best practices, as well as several Drupal hobbyists looking to learn professional development techniques.

Our always-being-updated curriculum dropped support for Drupal 7 with this most recent class. The curriculum now teaches Drupal 8 best practices around using Composer to manage site codebases, Drupal Console for module development, and proper use of Drupal's settings.php and settings.local.php files. 

The next semester of Drupal Career Online begins March 26 - learn more about it.  

We're also offering our Mastering Professional Drupal Developer Workflows with Pantheon class starting February 27. This 6-week, 3 half-day per week, live online class is for those with previous Drupal development experience who are looking to learn professional Drupal 8 workflows focusing on Composer and Pantheon. In addition, there are dedicated lessons about Drupal information architecture, using Search API and Solr, and utilizing advanced Pantheon hosting features. 
 

Categories: Blogs

Acro Media: How To: Add a Solr Datasource Field for Product Searching in Drupal Commerce 2

December 26, 2017 - 11:00am

Apache Solr is a powerful search engine used by many of the largest websites on the planet. It's highly customizable, alowing you to configure content catalogs and search results by any content datasource (such as title, brand, colour, price, keyword, taxonomy, etc.). You can also assign priority levels to each datasource so that your users are more likely to find the content that they're looking for right away.

Our Urban Hipster Drupal Commerce 2 demo site uses Solr for product catalog functionality and as a product search. In this Acro Media Tech Talk video, we'll show you how you can make a new datasources searchable to your users. 

We've built this demo site to show the adaptability of the Drupal Commerce platform. Most of what you see is out-of-the-box functionality combined with expert configuratoin and theming.

Urban Hipster Commerce 2 Demo site

This video was created using the Urban Hipster Commerce 2 demo site. We've built this site to show the adaptability of the Drupal 8, Commerce 2 platform. Most of what you see is out-of-the-box functionality combined with expert configuratoin and theming.

More from Acro Media Drupal modules used in this video Additional resources

Categories: Blogs

DrupalBASE: Communicate with your audience, make your content visual and interactive

December 25, 2017 - 6:29pm

For content managers as well as developers Drupal provides a lot of tools and approaches to create content of different types and flavours, from simple text to structured layouts with much of graphics and media. Though still there is enough uncertainty and complexities with authoring experience. Some tasks are even hardly accomplishable without coding or require a sensible effort to. Here to the rescue comes VisualN. The VisualN module brings a generic approach to carry out many of those "painful" and daunting tasks with ease and fun. What is important, it hides the complexities from user to make interaction intuitive and joyful.

The drawing above as any other drawing in the article is fully created and configured via UI with no single line of code or extra modules. To embed drawings into content VisualN provides a rich set of approaches and their combinations so that user wouldn't be limited in his content structuring strategies and could stick to the preferred ones. For the examples in the article we've chosen to use visualn token functionality to embed drawings via simple tokens of [visualn:embed:drawing:id] format. Though you can choose to use Paragraphs or even embed drawings via iframes (which generally is more suitable to embed drawings into third-party sites content).

So what is a drawing and how it works

There is practically no limit on what a drawing can be. For purposes of the article though we can say that a drawing is basically a piece of content or markup with styles, scripts and settings attached generated by a drawer plugin or fetched by a fetcher plugin (which commonly relies on a drawer). Drawer may also need some data to generate drawings, e.g. maps need a list of points with geodata, charts may need some kind of statistics in which case data can be provided for it. Data can be provided as files or retrieved from many other types of sources, even generated on the fly - VisualN provides all required tooling and infrastructure.

Categories: Blogs

erdfisch: Drupalcon mentored core sprint - get that Friday feeling!

December 25, 2017 - 2:00pm
Drupalcon mentored core sprint - get that Friday feeling! 25.12.2017 Michael Lenahan Body:  Drupalcon mentored core sprint - get that Friday feeling!

This is the first in a series of blog posts on a subject I'm very passionate about. So much so, that it's actually quite hard to put down in words the way I feel about it. That subject is the Friday Mentored Core Sprint at Drupalcon.

Call to action: If you are planning to go to Drupalcon Nashville, please be sure to extend your stay to cover the Sprint Day on Friday, April 13. You will not regret it!

TL;DR: participating at a large-scale mentoring event like this is an incredible experience. In fact, it is one of the most valuable learning opportunities you will have in your career.

Take advantage of this opportunity. Come along, first as a participant - and then, in future, once you have seen how it works, you can join this team of mentors:

The Drupalcon mentored core sprint is not just for developers.

I think that is worth repeating:

The Drupalcon mentored core sprint is not just for developers. It's for sales people, project managers, freelancers, site builders - in fact anybody in the Drupal world who wants to learn about contributing.

If you are a sales person or a project manager or a site builder - the Friday at Drupalcon is meant exactly for you, and you are welcome to come along and join in. Whatever your skill set is, Drupal needs you!

The Friday sprint at Drupalcon is brought to you by an amazing team of volunteers. Everything they do is centered around creating a friendly, non-intimidating atmosphere, so that everyone feels welcomed and productive.

So here it is. Your chance to make your first contribution to Drupal.

And - if that's not enough - you will simply meet great people, make new friends, and work together on Drupal Core with them. Friendships are made on this day which last for years.

So, what actually happens on Friday at Drupalcon?

I've been lucky enough in the past few years to have been supported by employer erdfisch so that I could go to Drupalcon.

If I didn't have a ticket for Drupalcon, I would travel there anyway, just to take part on the Friday, because it is the highlight of my professional year.

Three quick notes here:

  • You do not need a Drupalcon ticket to go to the Friday mentored core sprints.
  • If you are reading this and planning to be at Drupal Nashville then make sure you stay for the Friday!
  • Drupalcon Europe will, we hope, be replaced by a Drupal Europe event in 2018. We are certainly hoping that this will include a core mentored sprint as well.

So, what makes this day so special?

Well, here's what the Mentored Core Sprint Room looks like at 08:30 in the morning. If you look very closely you can see Sutharsan setting up his table.

After an hour or two, that very same room looks like this:

These photos make me feel hopeful and proud. They sum up for me what the Drupal community is about: people working together and helping each other to be successful.

I'd like you to take a moment and really look at these pictures for a while. The people you see in these photos have had a very long week, they are sleep deprived and very, very tired. (Last night was Trivia Night).

So what's going on? What's making them so engaged?

This is my favourite photo, because it describes perfectly the beautiful chaos of the sprint room on Friday.

Here's another thing: most of the people sitting next to each other did not even know each other a few hours before. That is beautiful. In my humble opinion, if you come to Drupalcon and miss out on this, you're missing out on something important, something potentially life-changing.

What are these people working on? How is this whole thing organized?

I'm glad you asked, because those will be the topics of the follow-up blog posts!

A final word in memory of J-P Stacey

While preparing this post, I saw this tweet.

Last year at Drupalcon Dublin, I asked J-P to be my "mentor mentor" because
I was so impressed by his gentle and unruffled style. He organized the team
at his table with exemplary grace and good humour. I was particularly struck
by how quickly he gathered a group of enthusiastic people around him. Bye J-P,
it was a true honour to have known you, if only once a year, in this particular
context.

Credit to Amazee Labs and Roy Segall for use of photos from the Drupalcon Vienna flickr stream, made available under the CC BY-NC-SA 2.0 licence.

Schlagworte/Tags:  planet drupal-planet drupalcon mentoring code sprint Ihr Name Kommentar/Comment Kommentar hinzufügen/Add comment Leave this field blank
Categories: Blogs

Gizra.com: Selling an Item for $1.6M with Elm and Headless Drupal

December 24, 2017 - 6:00pm

If you happen to know Brice - my colleague and Gizra’s CEO - you probably have picked up that he doesn’t get rattled too easily. While I find myself developing extremely annoying ticks during stressful situations, Brice is a role model for stoicism.

Combine that with the fact that he knows I dislike speaking on the phone, let alone at 6:53pm, almost two hours after my work day is over, you’d probably understand why I was surprised to get a call from him. “Surprised” as in, immediately getting a stomach ache.

The day I got that call from him was a Sale day. You see, we have this product we’ve developed called ״Circuit Auction״, which allows auction houses to manage their catalog and run live, real-time, auction sales - the “Going once, Going twice” type.

- “Listen Bruce,” (that’s how I call him) “I’m on my way to working out. Did something crash?” I don’t always think that the worst has happened, but you did just read the background.
- “No.”

I was expecting a long pause. In a way, I think he kind of enjoys those moments, where he knows I don’t know if it’s good or bad news. In a way, I think I actually do somehow enjoy them myself. But instead he said, “Are you next to a computer?”

- “No. I’m in the car. Should I turn back? What happened?”

I really hate to do this, but in order for his next sentence to make sense I have to go back exactly 95 years, to 1922 Tokyo, Japan.

Continue reading…

Categories: Blogs

Agaric Collective: PHP and Symfony tracks merged for DrupalCon Nashville 2018

December 23, 2017 - 4:51pm

The program for DrupalCon is evolving constantly. Among the changes for Nashville 2018 new tracks have been added and some have been merged. That is the case for the Symfony and PHP tracks.

Many topics clearly belong to a single track, but others could fit in more than one. When we had a dedicated Symfony track a session about Twig could be submitted to the Symfony or front end tracks. A session about Drupal Console could be submitted to the Symfony, the PHP, or back end tracks. In an effort to reduce confusion in the call for proposal process, the track team has agreed on the following:

  • The back end development track is for sessions focused on Drupal coding and development practices.
  • The PHP track is for sessions that cover the broader PHP ecosystem. These sessions can be related to Drupal, but focused on an external project/library like composer, or PHPUnit, Symfony components.
  • The Symfony track merged with the PHP track.

Undoubtedly Symfony plays a key role in Drupal. Symfony 4 has just been released and it would be great to learn about what the future looks like. We want to learn about what is new in the latest version and what benefits adopting it would bring. We are also interested in sessions that would allow developers to learn from each other. What does a Symfony developer need to know to write Drupal code? What does a Drupal developer needs to know about Symfony to become a better developer? In other words - how to make proper use of Symfony components and related best practices.

Other session ideas include best practices on using Composer, PHPUnit, and third party libraries; new features in PHP 7; functional, asynchronous, and reactive programming; machine learning; micro services; etc.

If you want to attend DrupalCon Nashville, but the cost of attending is too high there are some ways to reduce the expenses:

  • Getting a session selected gives you a DrupalCon ticket.
  • You can get a $350 stipend to help cover expenses if your session is selected and you identify yourself within at least one of the "Big Eight" Social Identifiers. This is part of an effort to increase diversity at DrupalCon.
  • If you volunteer as a mentor, you can get a free ticket. No need to be a speaker for this one.
  • There are grants and scholarships that can provide a ticket and/or money to cover expenses. No need to be a speaker for this one.

The track team for DrupalCon Nashville 2018 is here to help you during the session submission process. We can help review proposals, suggest topics, and clear any doubt you might have. For the PHP track, Chad Hester, Tim Millwood, and myself are ready to help.

For people who have not presented before and for those of underrepresented groups, the Drupal Diversity and Inclusion Initiative has created a channel in Slack to help them with the proposal project. Mentoring is available at drupal.org/slack? in the #ddi-session-help channel.

The call for proposals closes in less than a month on January 17. Do no leave things until the last minute. We look forward to your session submissions!

Categories: Blogs

MidCamp - Midwest Drupal Camp: Buy a ticket, submit a session and sponsor MidCamp 2018!

December 23, 2017 - 1:45pm
Buy a ticket, submit a session and sponsor MidCamp 2018! Session Submissions are now open

MidCamp is looking for folks just like you to speak to our Drupal audience! Experienced speakers are always welcome, but our camp is also a great place to start for first-time speakers.

MidCamp is soliciting sessions geared toward beginner through advanced Drupal users. Know someone who might be a new voice, but has something to say? Please suggest they submit a session.

Find out more at: Buy a Ticket

Tickets and Individual Sponsorships are available on the site for MidCamp 2018. Click here to get yours!

Schedule of Events
  • Thursday, March 8th, 2018 - Training and Sprints
  • Friday, March 9th, 2018 - Sessions and Social
  • Saturday, March 10th, 2018 - Sessions and Social
  • Sunday, March 11th, 2018 - Sprints
Sponsor MidCamp 2018!

Are you or your company interested in becoming a sponsor for the 2018 event? Sponsoring MidCamp is a great way to promote your company, organization, or product and to show your support for Drupal and the Midwest Drupal community. It also is a great opportunity to connect with potential customers and recruit talent.

Find out more at:

Thanks for reading this far!  We hope to see you at the camp!

Categories: Blogs

mark.ie: Integrating a Simple Drupal Text Paragraph Bundle with Patternlab

December 21, 2017 - 3:49pm
Integrating a Simple Drupal Text Paragraph Bundle with Patternlab

This is the first post in a series about how to integrate Drupal with PatternLab. In this first blog post, we'll look at a simple text paragraph bundle, which just has one field: text (formatted, long).

markconroy Thu, 12/21/2017 - 19:49

I see a lot of blog posts and talks around about the benefits of using component-based design, about how we should use design in the browser principles to present designs to our clients, about how styleguides are the best way to have sustainable frontends. I've even written some and given many presentations about it myself. What I don't see a lot of is blog posts about how to actually do it.

So, here's how to (or at least how I) integrate my PatternLab theme (it's based on the Phase 2 PatternLab Drupal theme) with a simple paragraph type.

PatternLab

Create a pattern - you can put it wherever your setup says it should go. Paragraph bundles are probably molecules, but I'm not sure how you set up yours. In my case, I have hacked PatternLab and created a folder called "Building Blocks" - this is where all my paragraph bundles go (and then I also have a "Building Blocks" field in each content type - more about my set up in another blog post.

Call the pattern something meaningful - in this case, I call mine "Text". Next, we write the Twig for the text pattern. This can be as simple as this:

{%
set classes = [
  "text"
]
%}


    {{ content }}

Then in my corresponding text.yml or text.json file, I put in some sample content, like so (I like yml):

content: 'This is a Level 2 Heading

This is a paragraph of text followed by a list. Sed posuere consectetur est at lobortis. This is strong while this is emphasised Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Aenean lacinia bibendum nulla sed consectetur. Curabitur blandit tempus porttitor. Integer posuere erat a ante venenatis dapibus posuere velit aliquet. Vestibulum id ligula porta felis euismod semper.

  • A text item in a list
  • Another text item
    • A sub-item
    • Another sub-item
  • A third item in a list
This is a Level 3 Heading

Followed by some more text. This is a link sed posuere consectetur est at lobortis. Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Aenean lacinia bibendum nulla sed consectetur. Curabitur blandit tempus porttitor. Integer posuere erat a ante venenatis dapibus posuere velit aliquet. Vestibulum id ligula porta felis euismod semper.

'

Drupal

Finally, in my Drupal paragraph--text.html.twig file, I extend the above PatternLab file, like so:

{% extends "@building-blocks/text/text.twig" %}

Yes, there is only one line of code in that file.

Some Explanation

Why do I call my variable {{ content }}? Simple, I know that the default variable in Drupal's paragraph module to print the contents of the paragraph is {{ content }}, so if I give my pattern in PatternLab the same variable name, I won't have to worry about matching any variables. I do not need to do something like this:

{% include '@building-blocks/text/text.twig' with {
  content: text
  }
%}

This will become much clearer when we work with more complex paragraph types in later blog posts.

You can see an example of this pattern in PatternLab here, and the text you are currently reading is an example of it in use in a Drupal template. Simple, eh?

Categories: Blogs

Zivtech: 5 Drupal Modules for Content Editors

December 21, 2017 - 2:01pm

As a content management system, Drupal is designed to simplify the process for adding, modifying, and removing content, even for users without much technical expertise. 

Beyond its core functionality, Drupal has a number of modules that make life even easier for content writers and editors. Some of these modules, like Views and CKEditor, were added to core when Drupal 8 was released. 

These are some of our other favorite modules that can further simplify workflows for content editors. 

Real-time SEO for Drupal

Content writers always need to strike the right balance between user friendliness and search engine optimization in their work. Content should incorporate SEO strategies in order to appear in relevant searches while also remaining relevant and appealing to site users. 

Real-time SEO for Drupal promises to help “optimize content around keywords in a fast, natural, non-spam way.” The module analyzes elements of your content like page length, meta descriptions, keywords, and subheadings. This helps boost SEO without sacrificing readability, striking that careful balance. This module also requires the metatag module.

Pathauto

Drupal identifies every piece of content with a node ID, which is displayed in the URL. The Pathauto module uses tokens to automatically create URL aliases based on a specific patterned system that you establish. 

Read more
Categories: Blogs

Chromatic: Principles of Test-Driven Development

December 21, 2017 - 10:00am

Summary: Test-driven development (TDD) keeps you focused, encourages critical thinking, and improves code confidence. Here are some basic principles that have helped me write effective tests and which have proven useful when introducing other developers to the practice.

Categories: Blogs

DrupalEasy: DrupalEasy Podcast 201 - Jacob Rockowitz - Webform

December 21, 2017 - 8:39am

Direct .mp3 file download.

Jacob Rockowitz (jrockowitz), lead maintainer of the Webform module and builder and maintainer of the Memorial Sloan Kettering Cancer Center site joins Ted Bowman and Mike Anello to talk about the current state of the Drupal 8 Webform module and its path to Drupal 8 and beyond.

Interview DrupalEasy News Sponsors Upcoming Events Follow us on Twitter Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Categories: Blogs

Dries Buytaert: Evolving Acquia.com

December 21, 2017 - 8:21am

At Acquia, our mission is to deliver "the universal platform for the greatest digital experiences" and we want to lead by example. This year, Acquia's marketing team has been working hard to redesign Acquia.com. We launched the new Acquia.com last week. The new site is not only intuitive and engaging, but "practices what we preach", so to speak.

Over the course of our first decade, Acquia's website has seen a few iterations:

The new site places a greater emphasis on taking advantage of our own products. We wanted to show (not tell) the power of the Acquia Platform. For example, Acquia Lift delivers visitors personalized content throughout the site. It was also important to take advantage of Acquia's own resources and partner ecosystem. We worked in partnership with digital agency, HUGE, to create the new design and navigation.

In the spirit of sharing, the marketing team documented their challenges and insights along the way, and reported on everything from content migration to agile development.

The new site represents a bolder and more innovative Acquia, aligned with the evolution of our product strategy. The launch of our new site is a great way to round out a busy and transformative 2017. I'm also very happy to finally see Acquia.com on Drupal 8! Congratulations to every Acquian who helped make this project a success. Check out it out at https://www.acquia.com!

Categories: Blogs

Freelock : Another Wednesday, another round of security updates

December 20, 2017 - 8:10pm
back_door.jpeg

Drupal security updates generally come out on Wednesdays, to try to streamline everybody's time. WordPress security notices come out... well, whenever whichever feed you subscribe to bothers to announce something.

Today's notices showed some striking differences between the two communities.

maintenanceSecurityWordPressDrupalDrupal Planet
Categories: Blogs

myDropWizard.com: Drupal 6 version of 'me aliases' module not affected by SA-CONTRIB-2017-097

December 20, 2017 - 3:31pm

Today, there was a Highly Critical security advisory for a Remote Code Execution (RCE) vulnerability in the me aliases module for Drupal 7:

me aliases - Highly critical - Arbitrary code execution - SA-CONTRIB-2017-097

This module provides shortcut paths to current user's pages, eg user/me, blog/me, user/me/edit, tracker/me etc.

It was incorrectly handling URL arguments that could allow an attacker to execute arbitrary PHP code.

However, the way the Drupal 6 version of the module handles URL arguments isn't vulnerable in the same way. So, Drupal 6 users can rest easy - your site isn't affected by this issue.

But if you do use it on Drupal 7, given the criticality of this issue, please update right away!

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Categories: Blogs

Drupal.org blog: Developer Tools Initiative - Part 4: What's next?

December 20, 2017 - 1:39pm

This is the fourth post in our series about integrating Drupal.org with a 3rd party developer tooling provider:

With our plan to create modular integration points for our tooling options, we have a few clear steps for moving forward:

Phase 1: Prep work
  • Deprecation of password authentication for Git, since many external tooling services no longer support it.
  • Working with core to provide compatibility for semver versioning for contrib, both because this is needed for Composer, and because all of the third party developer toolsets we are considering have begun to standardize on semver.
Phase 2: Initial implementation, replacing current features
  • Replacement of custom, bespoke Twisted Git daemon with standard BitBucket repositories.
  • Replacement of unmaintained CGit with supported BitBucket code viewing.
Phase 3: New features
  • Integration of merge request 'hook' into issue queues, to allow contributors to use a pull request workflow instead of patches.
    • Modular - to be used with BitBucket for now, but potentially another solution when more mature.
  • Integration of code review 'hook' into issue queues, to give us powerful inline code commenting tools.
    • Modular - to be used with BitBucket for now, but potentially another solution when more mature.
Phase 4: Implement Hybrid Integrations for other toolsets
  • Updating project page integrations such that those projects which are already hosted on third party tools such as GitHub or GitLab (for example, Drush) can easily login with SSO, synchronize their repositories, and choose the canonical home of their issues.
On-going: Evaluation
  • Re-evaluate other tooling solutions as blocking issues are resolved and their feature-sets evolve.
So that's the update!

In short: after more than a year's evaluation of the current leaders in open source tooling solutions, including direct collaboration with several of those teams, we are going to focus on making Drupal.org modular to integrate with the best tooling solution as it develops. For now, we will be implementing key improvements for Drupal developers using BitBucket for our repository hosting, code viewing/review, inline editing, and merge requests - integrated with the existing project pages and issue queues.

We'd like to thank the following people for their involvement in this initiative at various times through the process:

Drupal Association Staff

The Technical Advisory Committee (TAC)

Members of the community

Categories: Blogs

Drupal.org blog: Developer Tools Initiative - Part 3: Illustrating modular integration for Developer Tooling on Drupal.org

December 20, 2017 - 1:37pm

This is the third post in our series about integrating Drupal.org with a 3rd party developer tooling provider:

Below are some rough mockups of what a modular integration between Drupal.org's issue queues and a third party toolset could look like. For the sake of this example, I've used BitBucket as the tooling provider, as that is likely to be our interim toolset for the reasons outlined above. However, one can easily imagine these functions being substituted for their equivalents in other toolsets.

The following is only an early concept. These are by no means final designs for each of these integration points, but they will help to visualize how these tools will be integrated with Drupal.org.

Mockup: Workspaces in the issue summary

The biggest change for contributors would be the addition of a new place in the issue summary to contain these workspaces. For most issues we anticipate a single workspace, as most issues are resolved via collaboration on a single code path, however we would be able to generate multiple workspaces per issue for multiple solutions being proposed in parallel:

The key functions of the Proposed code workspace are: the ability to make a new workspace, the ability to clone an existing workspace, the ability to create/view/edit a workspace merge request. The latest test result and ad-hoc testing options for each workspace would be provided here as well.

Mockup: Propose new Code

The "Propose new code" button is very simply a way to automatically generate a new workspace. This would only be used when a contributor wants to propose an alternate solution to whatever is currently under development. When pressed, we would generate a new workspace with the back-end tooling provider (whether as a fork, branch, or Git namespace) and add it to the table to be cloned, viewed for comments/inline editing, or ultimately to create a new merge request.

The new workspace will be generated with a name based on the issue id, and will present its own test result, clone, and merge request features.

If a user wants to collaborate on an existing solution instead, they can simply clone that workspace locally, or view it to make inline edits. Because some issues can languish for months, or even years, we also want to automate the process of rebasing these workspaces from their parents.

Mockup: Automatic comments as workspaces are updated

Whenever a change is made within the third party toolset, we would use the API to call back to Drupal.org and leave a system message describing the change, as well as linking to the relevant part of the third party toolset UI.

This is what an automated issue comment for code review might look like:

This is what a comment for recently pushed changes would look like:

And this is what a comment for inline edits could look like:

Mockup: Clone

The clone button would simply provide a basic modal pop-up with instructions for collaborators to clone the workspace locally with Git. This is not the final url pattern (one of our goals is to avoid changes in canonical git urls where possible) but it could look something like this:

$ git clone ssh://git@bb.drupalcode.org/is/drupal.git

Mockup: Create Merge Request (in BitBucket)

Merge requests allow contributors to propose changes to projects they don't maintain, and provide maintainers an easy way to view proposed changes.

The create merge request button would allow the user to view the current workspace and request that it be merged into the canonical parent. Only a project maintainer would have the permissions to complete the merge.

Code in a workspace with an open pull request can continue to be iterated on by the contributors. Code comments, diffs, and reviews are summarized on the request.

Mockup: View Merge Request (in BitBucket)

View merge request, like 'create merge request' would allow any collaborator to view the current workspace. This could also be used to initiate inline code edits, or leave code comments.

Mockup: Inline editing

Inline editing allows a quick and easy way for people to propose "standalone" changes to e.g. documentation, markup, etc. without having to have an entire development stack.

We would rely on the third party tooling provider's inline editing functionality. In the example below, we can see how an inline edit is made using BitBucket:

Mockup: Code review

As with inline editing, we would rely on the third-party tooling provider's tools for code review. In the example below you can see the code review options provided by BitBucket:

As indicated above, these mockups are simply an illustration of what this integration could look like, not final designs. However, this has hopefully shown how we can introduce a hybrid model to integrate the best features of a third party tooling provider (pull requests, code review, inline editing), while retaining the essential nature of the drupal-flow.

In our next post:

We outline our roadmap for this initiative.

Categories: Blogs

Drupal.org blog: Developer Tools Initiative - Part 2: Comparing our options

December 20, 2017 - 1:33pm

This is the second post in our series about integrating Drupal.org with a 3rd party developer tooling provider:

In this update we'll talk about the specific options we've been evaluating to improve the tools for developers on Drupal.org. For each of these options we've built prototype workflows, stood up test integrations, and opened a dialogue with the creators of these toolsets about any gaps we identified. You'll see a summary of how each tooling option does or does not live up to the criteria we outlined in our last post.

Issue Workspaces

At DrupalCon Los Angeles in 2015, Mixologic from the DA Engineering team proposed the concept of Issue Workspaces. While we've historically talked about this idea as a single concept, it actually breaks down into two key components:

  1. The definition of a modern, idealized workflow for the Drupal project.
  2. A technical implementation using a bespoke tooling solution built on Git Namespaces to implement this workflow.

Criteria (for a bespoke implementation):

  • Familiar workflow.
    • ❌/ While an implementation of workspaces based on a bespoke git-namespaces implementation has several technical advantages, it will not appear nearly as familiar to outside developers as a more standard 'pull request' implementation. (Though it would be functionally very similar).
  • Preserve the most valuable parts of Drupal's workflow.
    • By implementing a bespoke solution we could exactly tailor the solution to the needs of the Drupal community.
    • ❌ However, the needs of that community are great, and our capacity to build a 100% bespoke solution that meets all the community's needs is not clear.
  • Leverage a partner who will keep evolving their code collaboration featureset.
    • ❌ Building issue workspaces using a bespoke git namespaces implementation would require us to continuously compete on features with major third party tooling providers that have much greater resources.

A purely bespoke implementation misses the mark on two of our three primary criteria. Fortunately, however, two years after the original proposal, it is no longer necessary to build a bespoke solution in order to implement an idealized workflow for the Drupal project. It is something that can be done by integrating the existing Drupal.org project pages and issue queues with third-party tooling solutions. Leveraging third party solutions provides several advantages including: familiarity to a wider audience of developers, a continually evolving featureset, and mitigation of the risks of maintaining a bespoke solution with a small team of engineers.

Here is the idealized 'Drupal-flow' visualized:

  • Every issue should be associated with one or more canonical workspaces (git repos+merge requests) which can be collaborated on by any contributor, and merged into the canonical parent by a project maintainer.
  • Contributors should be able to modify the code in these workspaces by:
    • Checking out the code and committing/pushing changes to the workspace.
    • Inline editing files within a workspace.
    • Legacy: uploading a patch.
    • Any contribution method should trigger the appropriate tests.
  • Workspaces should be rebased (manually or automatically) on any changes to the canonical parent.

This workflow is not dissimilar to the default GitHub flow, GitLab flow, or even the suggested BitBucket flow. These are all variations of the generic concept of 'Git flow' created by Vincent Driessen. However, the important difference comes in how each of these solutions tries to integrate a gitflow model into their issue/pull-request model.

The dominant model of these large third party tooling providers is not particularly collaborative. It encourages forks-of-forks, separates conversation about potential solutions onto multiple branch comments or merge requests threads, and generally caters to single developers working on individual proposed solutions, with one ultimately selected by the maintainer and the rest thrown away.

This is a key area in which the 'Drupal-flow' differs from the standard workflow that is implicitly enforced by these toolsets. Our ethos encourages collaboration of many developers on a single solution, and a single threaded conversation.

The gitflow behind the scenes may be identical, but the user experience wrapped around that flow makes very different assumptions about how people will collaborate.

GitHub

GitHub is of course the dominant player in the open-source tooling space. For many years though, their toolset was very much targeted at smaller open-source projects, and their default workflow highly encourages a many-to-many, forks-of-forks workflow, rather than the many-to-one single-threaded collaboration that is part of the Drupal community's ethos. More recently, GitHub has been improving their featureset, providing better issue management tools, more control over organization-level namespaces, and a new app marketplace that allows developers to extend GitHub's core featureset.

We reached out to GitHub and spoke with members of the technical and partnership teams, and while they were excited by the idea of bringing a project like Drupal to GitHub, we did run into some unresolvable blockers - most critically, by policy GitHub does not allow users of GitHub Enterprise to run their own public instances. This means we would have to migrate Drupal projects to GitHub.com, rather than self-hosting our instance.

Criteria:

  • Familiar workflow
    • ✔ GitHub is unquestionably the dominant platform for code collaboration on the web today.
  • Preserve the most valuable parts of Drupal's unique workflow
    • ❌ No way to enforce Drupal.org as the home of projects. While we can still keep project pages on Drupal.org there is nothing to encourage visitors who find the project on GitHub to treat the Drupal.org project page as canonical.
    • ❌ ;No way to enforce our workflow - forks of forks of forks of Drupal core into personal namespaces would be one click away.
    • ❌ Issue management tools are not setup for large, crowd-sourced teams.
      • Even for large community projects, it's more typical for only one or two developers to work on a single github issue at a time. Collaboration tends to be divided across issues, rather than within them.
    • Hard blocker Changing issue metadata requires maintainer permissions. (i.e: No way for non-maintainer collaborators to set an issue to RTBC)
    • ❌ Limited ability to manage project maintainers, especially in the case of abandoned or insecure projects.
  • Leverage a partner who will keep evolving their code collaboration featureset.

Other issues:

  • License/Source availability
    • ❌ GitHub is closed-source.
  • API availability
  • Hybrid integration
    • ✔ A hybrid integration between Drupal.org and GitHub is possible with SSO, automatic repository syncing, and a choice of using our issue queue or theirs.
    • ❌ However, there would be no portability of issues across a project that uses GitHub to one that does not.
    • ❌ Projects choosing to use the GitHub issues would not have access to DrupalCI
    • ⸗/❌ Projects using GitHub issues would not have access to contribution credit (though it may be possible to develop an app).
  • Data portability/vendor lock-in

    • ⸗/❌ GitHub's data migration feature is only available as part of GitHub enterprise.
    • ❌ GitHub policy will not allow us to self-host, which would allow us to work around some of the issues of preserving our Drupal-flow.
  • Developer support
    • ⸗ GitHub is well-funded and has a large team of developers improving the product. However, it is not open source, and so there is no capacity for the community to fill in the gaps on anything GitHub fails to provide.
    • ✔ GitHub has recently added a new 'apps' architecture, enabling deeper integration.
  • Maintainability for an engineering team of limited resources
    • ✔ Repositories hosted on GitHub would be easy to maintain, but we would have little access or control in the event of issues, and little ability to customize the workflow for the community's needs.
  • Cost
    • ✔ The GitHub team would be willing to provide the Drupal project an enterprise account.
  • Unintended consequences
    • ⸗/❌ Moving most of our developer traffic to hosted GitHub could have a significant impact on Drupal.org traffic, affecting everything from our search presence to revenue programs.

GitHub is a no-go.

GitLab

GitLab is the up-and-comer, and is becoming exceptionally popular in the open-source space - even beginning to be adopted by larger open source projects such as GNOME and Debian.

We've worked closely with the GitLab team as well. In contrast to GitHub, GitLab's terms would allow us to run our own instance of the service. GitLab's fundamental workflow is very much like GitHub's - a one-to-many model of forks of forks. After discussing our workflow with their engineers GitLab has begun implementing their new 'fork network' feature, allowing merge requests across forks. However, this doesn't quite achieve the goal of allowing our many-to-one collaboration model just yet.

GitLab is very close to being a good solution for an Open Source project of Drupal's scale, and the rate at which they are improving the service is impressive. GitLab is also already a favorite of many in our community for personal or professional projects. Given some more time, it may ultimately be able to tick all the boxes.

Criteria:

  • Familiar workflow
    • ✔ GitLab's workflow is very similar to GitHub's and it is the second most widely used code collaboration toolset.
  • Preserve the most valuable parts of Drupal's unique workflow
    • Hard Blocker - Maintainers cannot yet collaborate on downstream merge requests
    • ❌ Monolithic toolset - GitLab's featureset is designed to be used in an all or nothing way. There is no provision for using specific elements while disabling others.
      • For example, there is no way to disable GitLab project pages in order to keep the canonical project pages on Drupal.org.
    • No plugin architecture - changes must be accepted as merge requests upstream in GitLab, or re-rolled as patches with each release (aka, "hacking core").
      • No easy way to turn on or off elements of the GitLab UI.
      • No way to extend the GitLab featureset.
      • Very limited issue management states, and no ability to customize them.
  • Leverage a partner who will keep evolving their code collaboration featureset.
    • ✔GitLab's roll-out of new features is the fastest paced of the tooling providers that exist today.

Other issues:

  • License/Source availability
    • ⸗ / ✔GitLab Community Edition is open source, but GitLab Enterprise Edition (which we would need for a project of our scale and with our workflow needs) is not open source, only source-available.
  • API availability
    • ⸗ GitLab has a fairly robust api, but in our evaluation we found that many api features were undocumented, and others were deprecated without notification between minor versions.
  • Hybrid integration
    • ✔A hybrid integration between Drupal.org and GitLab is possible with SSO, automatic repository syncing, and a choice of using our issue queue or theirs.
    • ❌ However, there would be no portability of issues across a project that uses GitLab to one that does not.
    • ❌ Projects choosing to use the GitLab issues would not have DrupalCI integration, or issue credits.
  • Data portability/vendor lock-in
    • ⸗ GitLab's API and documented data model should make it possible to migrate our data to another system should it become necessary.
  • Developer support
    • ✔ As an open-source project, GitLab has a growing community of contributors, as well as the support of a venture funded mothership organization.
  • Maintainability for an engineering team of limited resources
    • Hard Blocker - GitLab's current file-handling makes full copies of a repository for every fork. Taking the number of open core issues as a representative example, Drupal.org would need a new 200 TB+ redundant storage apparatus, just to accommodate Core. GitLab needs to transition to a shared git-object model, or an alternative like git namespaces.
  • Cost
    • ✔ The GitLab team is willing to provide the Enterprise Edition to the Drupal community for free.
  • Unintended consequences
    • n/a

GitLab: not-yet.

BitBucket

BitBucket was the dark horse candidate. Atlassian products are well known in software development circles, but they are often more tolerated than beloved. However, when we sat down at Midwest Drupal Summit in August and looked at the options we explored so far and found them to be not quite baked - BitBucket began to show some advantages as a solution.

For one thing, BitBucket has recently put a heavy focus on user experience and collaboration features. It also has the most flexible permissions model for control over branch permissions, forking, and automatic rebasing of any of the toolsets we evaluated. Finally, it can be implemented modularly - allowing us to use the components that serve our workflow and disable the ones that don't.

Criteria:

  • ✔/⸗ Familiar workflow
    • BitBucket implements a very standard pull request workflow. It is not as widely popular as GitHub or GitLab, but should be easily learned by developers familiar with either of those systems.
  • ✔ Preserve the most valuable parts of Drupal's unique workflow
    • Of all the options we prototyped, BitBucket is the only one which provides the flexibility needed to preserve key elements of our workflow - in particular the ability to cleanly use only the parts of BitBucket that we need (specifically, merge requests, inline editing, and code commenting) without having to use issues or project pages that are less sophisticated than our existing solutions.
  • ✔ Leverage a partner who will keep evolving their code collaboration featureset.
    • Though it's flown under the radar, Atlassian has been making some significant improvements to BitBucket from a feature and user experience point of view over the course of the past year.

Other issues:

  • License/Source availability
    • ⸗/❌ Bitbucket is not open-source, only source-available, though they have an open source licensing program.
  • API availability
  • Hybrid integration
    • ✔BitBucket is much more flexible in terms of choosing which features to use, and which to disable- allowing a fairly tight hybrid integration.
  • Data portability/vendor lock-in
    • ✔/ ⸗ BitBucket stores repositories as standard git objects on the file system, making it relatively straightforward in case of a future migration to another system.
  • Developer support
    • ⸗ BitBucket has the professional support of Atlassian, but does not have a robust open source community driving feature development.
  • Maintainability for an engineering team of limited resources
    • ✔ BitBucket is implemented with an api-first methodology, and is well documented, making it straightforward for a relatively small team to support a selective integration such as what we propose here.
  • Cost
  • Unintended consequences
    • n/a

BitBucket: the best tool in the current landscape given our community's needs.

To sum up, each of the toolsets we evaluated have advantages and disadvantages. However, if we want to move forward with making improvements for our developers TODAY, we have determined that the best way to do that is to create modular integration points, and use the toolset that currently meets our criteria: BitBucket. As these toolsets continue their rapid development, we will continue to periodically re-evaluate them.

In our next post:

An illustration of what the future of Drupal.org's developer tools could look like.

Categories: Blogs

Pages