Community Working Group posts: Announcing the 2020 series of Drupal Event Code of Conduct Training

The Drupal Community Working Group is happy to announce that we are once again teaming up with Otter Tech to offer live, monthly, online Code of Conduct enforcement training for Drupal Event organizers and volunteers in 2020.

During the second half of 2019, 17 Drupal community members completed the training (see full list), helping to ensure Drupal events world-wide have qualified Code of Conduct contacts. We are excited to be able to provide support for the training in 2020.

The training is designed to provide “first responder” skills to Drupal community members who take reports of potential Code of Conduct issues at Drupal events, including meetups, camps, conventions, and other gatherings. The workshops will be attended by Code of Conduct enforcement teams from other open source events, which will allow cross-pollination of knowledge with the Drupal community.

Each monthly online workshop is the same; community members only have to attend one monthly workshop of their choice to complete the training.  We strongly encourage all Drupal event organizers to consider sponsoring one or two persons’ attendance at this workshop.

The monthly online workshops will be presented by Sage Sharp, Otter Tech’s CEO and a diversity and inclusion leader in the open source community. From the official description of the workshop, it will include:

  • Practice taking a report of a potential Code of Conduct violation (an incident report)

  • Practice following up with the reported person

  • Instructor modeling on how to take a report and follow up on a report

  • One practice scenario for a report given at an event

  • One practice scenario for a report given in an online community

  • Discussion on bias, microaggressions, personal conflicts, and false reporting

  • Frameworks for evaluating a response to a report

  • 40 minutes total of Q&A time

In addition, we have received a Drupal Community Cultivation Grant to help defray the cost of the workshop for those that need assistance. The standard cost of the workshop is $350, Otter Tech has worked with us to allow us to provide the workshop for $300. To register for the workshop, first let us know that you’re interested by completing this sign-up form – everyone who completes the form will receive a coupon code for $50 off the regular price of the workshop.

For those that require additional assistance, we have a limited number of $100 subsidies available, bringing the workshop price down to $200. Subsidies will be provided based on reported need as well as our goal to make this training opportunity available to all corners of our community. To apply for the subsidy, complete the relevant section on the sign-up form. The deadline for applying for the subsidy is end-of-business on Wednesday, July 1, 2020 – those selected for the subsidy will be notified after this date (in time for the July 8, 2020 workshop).

The workshops will be held on:

Those that successfully complete the training will be (at their discretion) listed on Drupal.org (in the Drupal Community Workgroup section) as a means to prove that they have completed the training. We feel that moving forward, the Drupal community now has the opportunity to have professionally trained Code of Conduct contacts at the vast majority of our events, once again, leading the way in the open source community.

We are fully aware that the fact that the workshops will be presented in English limit who will be able to attend. We are more than interested in finding additional professional Code of Conduct workshops in other languages. Please contact us if you can assist.

Mobomo: Drupal 9: What’s New, What to Expect

Drupal 9 is scheduled for release on June 3, 2020. And as with any highly anticipated release, questions abound: “What will change from Drupal 8 to Drupal 9?” “What do I need to do to prepare before upgrading?” And top-of-mind is the big question: “What will Drupal 9 be like to work with?”

Read on as we share what you’ll need to know … and what might surprise you.

Anybody who’s upgraded from Drupal 7 to Drupal 8 recalls the giant chasm between the two systems. Almost 200 new features were launched including an entirely new page editor, a new theme engine, a new text editor, and new field types, to name but a few.

This gap doesn’t exist between Drupal 8 and Drupal 9. In fact, on the surface, there IS no difference: Drupal 9 has the same code, functions, and feature set as Drupal 8.9.

So why release it then? As it turns out, there are differences — they’re just not front-and-center on the interface.

Time to Clean House

Throughout its development cycle, Drupal 8 has wound up with a lot of code debt: functions that were created programmatically and used for some time but have been rendered redundant by more efficient functions.

These bits of code clutter up Drupal 8 like your old CDs and DVDs clutter up your bookshelf: There’s nothing wrong with them, but you probably don’t need them anymore now that you have something more efficient.

The result of all this extra code is that programmatically, there might be 10 different ways to do one single thing.

What Drupal has done is marked all of those code items in the backend code base as being “deprecated”. When Drupal 9 comes out, the plan is to remove all the deprecated code on this list, leaving only the latest version of whatever that code’s API is. They’ll also be updating third-party dependencies, such as Symfony and Twig. From Drupal’s site:

“Drupal 9 will be a cleaned-up version of Drupal 8. It will be the same as the last Drupal 8 minor version with our own deprecated code removed and third-party dependencies updated. We are building Drupal 9 in Drupal 8.”

Will Drupal 9 Be Better?

Yes, but not without some minor risks.

Jettisoning all this deprecated code will result in a much faster, cleaner, and better-operating version of Drupal. However, if you have legacy programs whose modules use some of that deprecated code, you could find yourself with some broken processes.

How to Prepare for Drupal 9

In general, upgrading to Drupal 9 is not an onerous process – it can literally be done via a single command. What will take more time is monitoring and auditing code bases to ensure that none of your functionality is dependent upon deprecated code.

Fortunately, Drupal is well prepared for this, and has indicated that the Drupal 8 branch of the Upgrade Status module can be used  to identify and report on any deprecated code:

“This module scans the code of the contributed and custom projects you have installed, and reports on any deprecated code that must be replaced before the next major version. Available project updates are also suggested to keep your site up to date as project will resolve deprecation errors over time.”

In addition, we anticipate that when downloading or updating modules, Drupal will likely advise whether there are compatibility issues due to bad functions. However, that notification system isn’t currently in place (if it indeed happens at all), so your best bet is to work with your development partner, who can audit your code to identify any trouble spots.

Marie Kondo-ing Your Infrastructure

Drupal 9 will be a much faster and more streamlined platform, but it doesn’t exist in a vacuum. If the rest of your operational architecture is similarly full of code debt and redundant processes, updating Drupal 9 will be akin to sending a Lamborghini down a pothole-rutted road: That powerful engine is wasted if the route is slowing it down.

So, going to Drupal 9 is an excellent opportunity to look at your legacy systems, audit them as well, and make sure your entire infrastructure is clean, fast, and free of roadblocks.

The Bottom Line

In general, upgrading to Drupal 9 should not be a complex or lengthy process. By cleaning out the clutter and performing some common dependencies, Drupal is practicing good development hygiene and providing its customers with a more streamlined system that will be faster … but still familiar.

Want to know more? Contact us today!

 

The post Drupal 9: What’s New, What to Expect appeared first on .

Gábor Hojtsy: Drupal 9 release scenarios, the first beta deadline in 6 weeks and how you can help!

As Dries Buytaert explained in his Plan for Drupal 9 post at the end of 2018 (emphasis mine):

Drupal 8’s biggest dependency is Symfony 3, which has an end-of-life date in November 2021. This means that after November 2021, security bugs in Symfony 3 will not get fixed. Therefore, we have to end-of-life Drupal 8 no later than November 2021. Or put differently, by November 2021, everyone should be on Drupal 9.

Working backwards from November 2021, we’d like to give site owners at least one year to upgrade from Drupal 8 to Drupal 9. While we could release Drupal 9 in December 2020, we decided it was better to try to release Drupal 9 on June 3, 2020. This gives site owners 18 months to upgrade. Plus, it also gives the Drupal core contributors an extra buffer in case we can’t finish Drupal 9 in time for a summer release.

Here we are 14 months later and while most people took the June 3 release date and took it for granted, it is still not guaranteed! However you can help in various ways to make it much more likely!

Late last fall, we focused on defining what it means if we cannot make the June 3, 2020 release despite our best efforts and what is an early indicator that tells us we are going to miss it. First of all, that meant defining requirements for the first alpha release and requirements for the first beta (API complete) release. Also we needed to set some expectations as to when do we want to see the API-complete beta release to give enough time for the ecosystem to test it and find important problems in time. Based on how soon the beta requirements are met, there are three release scenarios and the best case ending in the June 3, 2020 release date for Drupal 9 has a beta deadline in 6 weeks! Yes, 42 days!

Alpha requirements simplified

The key requirements for the first alpha release are simple. We wanted to update the key dependencies: Symfony to version 4.4 and Twig to version 2, as well as remove frontend polyfills that were not needed and remove most of jQuery UI (which were already deprecated in Drupal 8). This gets our most important dependencies up to shape to what will be in Drupal 9. We also made it possible for contributed projects to depend on Drupal 8 and 9 at the same time, so they will not need to branch for Drupal 9 support.

There are two outstanding things for the Drupal 9 alpha:

  1. Drupal.org does not yet have an automated packaging pipeline that conforms to all the recent composer related improvements and therefore making core releases is error prone. I don’t believe you can help with this at this time, the Drupal Association is hard at work on this.
  2. Drupal core should use a major version agnostic update feed for projects which is already being provided by Drupal.org but the core code to consume it is still in the works. While this is actively being worked on, reviews are always helpful. This will make sure Drupal 9’s Update Status gets only contributed projects that are actually Drupal 9 compatible, while contributed modules will not need to establish a Drupal 9 branch.

Beta requirements simplified

The beta requirements are a bit more complicated and longer of course because we are looking at being API complete here. Once again, for the June 3, 2020 release date, we need these done in 6 weeks! The issue lists must haves and should haves, however the should have issues should be considered must-have for the June 3, 2020 release date and would only be reconsidered later if that date cannot be met. Here is a simplified rundown of the beta requirements:

  1. We want to keep dependencies up to date. There is no concrete pressing issue here at the moment that I know, but this really depends on how our dependencies evolve.
  2. We’d like to remove all the deprecated APIs themselves. Last year I built a graph to track this, and it shows nicely that we are down to half of them remaining (yay!), but still quite enough to deal with. There are various outstanding issues you can help with here.
  3. We want to make sure people can update to Drupal 9 from Drupal 8 by resolving critical upgrade path bugs. If you cannot update to a later version of Drupal 8 due to some critical bug, then you will be stuck on your version of Drupal 8. Not good. These include views, layout_discovery, taxonomy, menu_content, etc. related issues. All of them need help. If you are on an older version and can reproduce the problems, that is useful. If you have experience in these areas, your input would be useful.
  4. It will only be possible to update to Drupal 9 from Drupal 8.8 or 8.9, so all older update paths and their tests should be removed. Older versions of Drupal 8 will themselves be unsupported already at the time of Drupal 9’s release. This issue is getting close but needs reviews.
  5. No new security or data integrity issues should be in Drupal 9. If there are any, they should be resolved. I don’t know of any issues at the moment here.
  6. The API should be complete. There are no critical API additions or changes that I know of at the moment in this general category.
  7. We want to make sure people can migrate from Drupal 6/7 to Drupal 9. This needs the remaining multilingual migration paths to go stable. This is an area where we posted several call to actions, but still need your help. There are proposed migration paths for node translations and entity translations that respect revisions but they need at least code reviews to make sure they are good. Otherwise if you had content translations with revisions, the migration will not be correct. Without that, multilingual migrations will not go stable.
  8. PHP requirements should be finalised. It is likely at this time that Drupal 9 will require PHP 7.3 that is being worked on currently and could use a review.
  9. Database requirements should be finalised in terms of MySQL/MariaDB/Percona and PostgreSQL. Both issues need data as to which distributions and hosts support certain versions.
  10. The right security update information should be provided for users taking the one year support cycle and long term support of the last Drupal 8 release. This could also use reviews.
  11. We should put Drupal’s base theme on a track so that it can evolve in Drupal 9 finally. This involves creating a new stable9 theme and decoupling the core themes from Classy. Various issues to help with here.
  12. Drupal.org should support multi-core compatibility eg. on project pages, localize.drupal.org, etc. This work is currently deprioritised by the Drupal Association due to the focus on the packaging pipeline blocker that I listed first. Once this gets attention, it will likely uncover core issues to resolve as well.

The two areas that receive the least attention at the moment are upgrade path blockers and the stability of the multilingual migration path, so those two are the most pressing where we need your help!

While the above is a complete rundown of the current beta requirements, it may change later on, so refer to the beta requirements issue later on for up to date information.

What happens if all the above are not done by end of February (in six weeks)

If all goes well, with your help, we’ll be done with all the above in six weeks. If that does not work out, we have a plan B and a plan C. Here is how those options unfold. If beta requirements are only done two months later by end of April, then Drupal 9’s first beta will be released on the first week of May and Drupal 9 is to be released on August 5, 2020. If the beta requirements are only done by end of August (four more months later), than the first beta will be released than with a Drupal 9 release date of December 2, 2020. In this case a Drupal 8.10 may also be released if needed. These dates are spelled out well in the Drupal core release cycle overview. I created this visual to help understand the alternate timelines:

Drupal 9 release scenarios visualised

While I think it is reassuring that we have plans for what happens if our initial date targets don’t work out, unfortunately the end of life date at the end of next year for Drupal 8 is not movable because it is based off of Symfony 3’s end of life. So the sooner we can make Drupal 9 happen (while meeting the upgrade and stability requirements) the better. What are you going to work on to help?

Helping with contributed projects

Based on the PHP deprecations our tools can identify, 43% of contributed projects would only need info.yml file updates to be Drupal 9 compatible. An additional 41% of the remaining projects have only issues that are resolvable now (even while keeping support for Drupal 8.7). Solving those anytime between now and Drupal 9’s release (whenever it is) would put us to almost six thousand contributed projects compatible with Drupal 9 on day one! While that is a very idealistic number, helping with contributed projects is nonetheless a great avenue to contribute to Drupal 9 readiness. Help at the Drupal Global Contribution Weekend at end of next week or anytime before and after! I prepared a quickstart guide for this occasion.

Amazee Labs: Contributing 12 Drupal Patches in 12 Months

Last year I embarked on a personal open source challenge, focused on Drupal. Very easy to say: “12 months 12 patches”. Some months my work lent itself naturally to contributions, but when it didn’t, I got creative. Here’s how I made it happen, and inspired others on my team to follow suit. 

Tag1 Consulting: Drush 10- Tag1 Team Talk #006

Description With the release of Drupal 8.8, Drush is also due for an upgrade — to Drush 10. For this venerable command-line interface that many Drupal developers know intimately well, what does the present and future look like? What considerations should we keep in mind when selecting Drupal Console or Drush? What new features are available in Drush 10 that characterize the new CI/CD approaches we see expanding in the Drupal community? In this Tag1 Team Talk, join the creator and maintainer of Drush Moshe Weitzman (Senior Technical Architect at Tag1), Fabian Franz (Senior Technical Architect and Performance Lead at Tag1), Preston So (Editor in Chief at Tag1), and Michael Meyers (Managing Director at Tag1) for a journey through Drush’s history and promising future. We take a deep look at what made Drush what it is today, the most compelling features in Drush 10, and how a hypothetical Drush in core could look.

jgilbert
Fri, 01/17/2020 – 07:00

Specbee: Are you prepared for a better tomorrow? – The Drupal 9 Checklist and What’s New

Are you prepared for a better tomorrow? – The Drupal 9 Checklist and What’s New
Shefali Shetty
16 Jan, 2020

Drupal 9 is just around the corner. Do you have a plan to upgrade to Drupal 9? Are you still in the “Why should I upgrade to Drupal 9 after all” phase? Wondering what your next steps should be for Drupal 9 readiness? We have answers to all your questions and a quick Drupal 9 checklist on how to prepare for Drupal 9.

The best way to prepare yourself for tomorrow is to give your best today. And very apparently, the Drupal community has done just that. I know, migrating to Drupal 8 from previous versions was hard. It meant a complete rebuild of the code and a lot of learning. But once you are fully onboard Drupal 8, life gets easier. Think of it as a hard climb for a gorgeous view from the mountaintop. Truly worth all the effort, isn’t it?
 

The Much-Talked-About Drupal 9 Release Date

One of the most frequently asked Drupal questions lately has been about the Drupal 9 release date. Drupal 9 is currently scheduled to release on June 3rd, 2020. The Drupal community has been successfully releasing minor versions every six months since the adoption of semantic versioning in Drupal 8. Every minor version came with several valuable new features. 

Drupal 8 extensively depends on third-party libraries like Symfony, Twig, Guzzle, CKEditor and must keep up pace with their updates as well. For example, Symfony 3 (Drupal 8’s biggest dependency) will reach EOL (end of life) by November 2021. The same time as Drupal 8 reaches end of life as well. Drupal 9 will be released with the latest Symfony 4.4 support and will not be backwards compatible with Symfony 3. 

Drupal 9
The Drupal 9 Readiness Roadmap (Image Credits – Drupal.org)

What’s New in Drupal 9 (Drupal 8 vs Drupal 9)

Drupal 9 is already being built within Drupal 8. Drupal 8.9 will release along with Drupal 9.0 in June 2020. This is because Drupal 9 is going to be the same as Drupal 8.9, except that it will be a cleaned-up version that is updated with support for its third-party dependencies. And hence one of the outstanding Drupal 9 features is that it is so easy to upgrade!

Every new minor version of Drupal 8 saw many new features but it also contained a lot of old code so it could be backwards compatible. This “old code” is also famously known as “deprecated code”. Because of the dependencies on third parties like Symfony, Twig, etc., Drupal 9 will incorporate updates to these dependencies. Drupal contributors and module developers are collectively making the road to Drupal 9 easier by eliminating “bad smelling code” (as Jacob Rockowitz calls it in his blog about deprecating code for his Webform module) from various Drupal 8 modules.

Drupal 9
What’s new in Drupal 9.0 (Image Credits – Drupal.org)

From Drupal 9.1 onwards, the same story continues. New Drupal 9 features will continue to be added every six months (Drupal 9.1..Drupal 9.2..Drupal 9.3…and so on) which will be backwards compatible with Drupal 9.

“If Drupal 9 is the same as Drupal 8.9, why should I even upgrade?”. Because Drupal 8 reaches end of life on November 2021 and will stop receiving any security fixes or updates from then on. So once Drupal 9 is released, there is an 18-month window to upgrade to Drupal 9. Sure, long-term support will be offered by Drupal vendors, but do we really want to miss out on all the new Drupal 9 features and enhancements that it will offer?

Drupal 9 Checklist

Regardless whether you’re upgrading from Drupal 7 to Drupal 9 or Drupal 8 to Drupal 9, you will need to start planning for Drupal 9. The scheduled release is soon approaching and now is a good time to get prepared for Drupal 9. 

  • Drupal 7 to Drupal 9
    If you are still on Drupal 7 and looking forward to getting onboard Drupal 9, it isn’t too late. Ideally, it is recommended you upgrade to Drupal 8 now and stay updated with the latest core releases. Migrate content and code to Drupal 8, Check for availability of modules in Drupal 8 using the Upgrade Status Drupal module, upgrade your Drupal 7 modules to Drupal 8 with the help of modules such as Drupal Module Upgrader, remove any deprecated code, upgrade to Drupal 9. And as already discussed, upgrading from Drupal 8’s latest version to Drupal 9 is easy as pie. Upgrading from Drupal 7 to Drupal 9 will take as much resource time (and resource budget) as a Drupal 7 to Drupal 8 to Drupal 9 upgrade. Drupal 7 will reach end-of-life by November 2021 and will continue to receive community support until then. 
  • Stay Up to date with Drupal 8
    With every new minor version release of Drupal 8, the benefits are not only restricted to access to new features and enhancements. It also takes you one step closer to Drupal 9. Since Drupal 8.8 is the last minor release before the Drupal 8.9 release (which also happens at the same time as Drupal 9!), it is the last Drupal 8 version to contain significant feature additions. Drupal 8.9 releases on June 3rd, 2020 and will include more stable modules (that were previously experimental) and a few UX and API enhancements. So, the best thing to do now is to keep Drupal core updated and update your website to Drupal 8.8. 
  • Weed out the Deprecated code
    Make way for new and improved features by removing old and deprecated code from your Drupal 8 codebase. When you keep Drupal core and contributed modules up to date, you are also embracing cleaner code. Updated versions remove usage of deprecated code and API. There are various methods to check for deprecated code. 

    • Sometimes functions are marked with @deprecated annotations that warn the developer that the following code is deprecated and what they should be using instead. 
    • Use a command-line tool like Drupal Check (by Matt Glaman from Centarro) to help check for deprecated code and other bugs. It can also be integrated in continuous integration environments.
    • Leverage the Drupal 8 Upgrade Status module on top of Drupal-Check for a more UI based solution. It can scan your entire Drupal project and generates a report that illustrates any compatibility issues and Drupal 9 readiness. 
    • Drupal.org also offers support to check for Drupal 9 readiness and deprecation within its testing system. Like enabling static analysis with phpStan or by setting a trigger_error() when a deprecated level is reached.

      Once identified, it is time for some manual work to remove the deprecated code and refine existing codebase. Use automated tools like Drupal 8 rector to resolve some code issues, although it does need some manual intervention.

Shefali ShettyApr 05, 2017

 

Yuriy Gerasimov: Build a CLI tool to automate your workflows

CLI tools is a great way to automate certain tasks for your CI needs. For example you re-use same shell scripts project to project. Or maybe you are integrating with some third-party service. Abstracting these tasks into your own CLI tool could be a great way to go.

You can think about some examples from Drupal world — each hosting provider has some sort of CLI tool. European Commission has one to automate certain DevOps tasks (https://github.com/openeuropa/task-runner).

In my case I was building one for interacting with Diffy — visual testing platform. Repository of the CLI tool is https://github.com/DiffyWebsite/diffy-cli

First, when I initially thought about idea of building a CLI tool I thought about the tools I used myself. Among them there were Drush and Terminus (Pantheon’s CLI tool). They both use https://robo.li/ so my choice was obviously to use this framework as well.

Getting started

One of the best parts of Robo is that they is a Starter project (https://github.com/g1a/starter) that will create a code for you and also push it to your github.

Once you’ve done that you can start creating your commands right away.

Command syntax

And that is simply creating classes that extend RoboTasks class.

For example here is a command that saves a configuration variable:

You can definitively recognize annotations if you have build custom Drush commands in the past.

Configuration

As for configuration Robo already promotes having a config file in your home folder as a YAML file. So for Diffy we store it in ~/.diffy-cli/diffy-cli.yml file.

There is a component https://github.com/consolidation/config/ that is used in Terminus and Drush. It is really great. Allows merging configs (imagine providing defaults and allowing override them) and also getting nested properties (get(‘foo.bar.baz’) type syntax).

But for my case I just needed to save an API key. So I went with a custom Config that simply saved or loaded parsed YAML file https://github.com/DiffyWebsite/diffy-cli/blob/master/src/Config.php.

Distribution as a PHAR file, self:update

Best part of the starter project is an example how you can pack the tool into single PHAR file.

Main idea is to use Travis to build and publish your PHAR file. Main idea is that you will need to use Travis CLI tool and run “travis setup releases”. Make sure to deploy released for tags only.

I have found more detailed instructions here and here.

Because of the starter project sets the setSelfUpdateRepository() for the runner whenever in the future next release will be available — you can simply run yourcommand self:update to self update the tool.

Tags: