Drupal Core News: Coding standards proposals for final discussion on 7 November

The Coding Standards Committe is announcing two coding standards changes for final discussion. Feedback will be reviewed at the meeting scheduled for 07 November.

Issues for discussion

The Coding Standards project page outlines the process for changing Drupal coding standards.

Recent changes

Allow constructor methods to omit docblocks

Documentation changes:

  1. Minimum requirements for in-code documentation
  2. Drupal API documentation standards for classes and namespaces

Always add trailing commas, for arrays and annotations

Documentation changes:

  1. Arrays coding standard
  2. @Annotation, @Plugin, etc.: Plugin discovery annotations

Join the team working on Coding Standards

Join #coding-standards in Drupal Slack to meet and work with others on improving the Drupal coding standards. We work on improving our standards as well as implementing them in the core software.

Drupal Core News: New members and process for the Coding Standards Committee

Welcome to new members!

We're thrilled to extend a warm welcome to the latest additions in the coding standards committee. 

Meet our newest team members:

  • Aaron McHale (AaronMcHale) 
  • Björn Brala (bbrala)
  • Derek Wright (dww)
  • Urvashi Vora (urvashi_vora)
     

We believe in the power of diversity and collaboration, and we’re confident that their contributions will add an incredible value to the committee.

Changes to the process for changing coding standards

A priority for the new committee has been to update 'The Process for Changing Coding Standards'. The key change is that coding standards issues now stay in the Coding Standards project. That is, they do not move back and forth between the Coding Standards project queue and the Drupal core queue. Instead of moving an issue that affects Drupal core a committee member will make sure it is on the agenda for the next Core Committer meeting.

You are encouraged to read the complete new process on the Coding Standards project page.

ComputerMinds.co.uk: Irina's experience of Drupalcon Lille

Image removed.

Drupalcon Lille 2023 was my first experience of a large Drupal event. I didn't know what to expect but I was so excited and looking forward to it! I have to say Drupalcon exceeded all of my expectations, in a good way!

In the beginning, I tried to remain humble as I’d never seen so many Drupal villagers before. But it didn’t take me long to start chatting to all the exhibitors, and contributors and connect with the community. It was a great opportunity to learn more about Drupal and be part of interesting sessions and informal conversations. It was a surprise to see community members not just from Europe but from all around the world. 

The biggest challenge was to decide which sessions to go to. The topics for the sessions were so broad; from Drupal basics and best practices to deep technical skills. All of them looked interesting and it was hard to pick because I didn’t want to miss anything. I'm so glad all of the sessions are available on replay on the OnAir platform and I can check them out later. 

Search API Decoupled, CKEditor 5 plugin and Dashboard left lots of thoughts in my mind and I can't wait to try and see how I can apply them to my work with ComputerMinds.

Image removed.

Some sessions were just another perspective of what we at ComputerMinds are already doing.  For example, the performance audit session was a good review of the most common problems I encounter. It was a really helpful, structured way to show how important it is to implement best practice at an early stage.  Such as how often do developers disable cache to “solve” bugs? The quickest fix is not always the best fix and there are ways to avoid problems through good planning. I particularly enjoyed the discussion on the use of views and paragraphs. Views are great and I use them all the time but at the same time, queries can slow things down. Now when I develop views I will think about how I can make best use of queries. 

Drupal is open source and we all download modules, themes and features but I never really thought about how all these features were developed. A case study about building the field UI improvements was a good example. I never thought about all the stages that go into building a feature from identifying the problem to the actual development.  It shows how people all work and focus on building a better Drupal, and it was a good opportunity to ask contributorsImage removed. questions. I felt encouraged to raise issues and also to make a contribution myself in the future. 

Surprisingly, at some point, I developed a competitive spirit and started scanning exhibitors' barcodes so that I collected enough points to enter a raffle. Coffee is the best winner's gift, right? :)

Although we had very busy days at Drupalcon it went so fast and before long it was time to go home! 

I'd like to thank ComputerMinds for organising our trip and all the people involved in the actual event. I really enjoyed it and took on board a lot of useful information.

LN Webworks: How to Achieve Revenue Growth with Drupal’s Roadmap

Image removed.

There is no denying the fact that every business organization is established to make profits. As the total revenue generation determines the overall profitability of an organization, increasing revenue is important to escalate profits. Drupal is a top-notch content management system (CMS) that bestows websites with the capability to achieve organic growth and multiply revenue. This is precisely why most businesses are reaching out to Drupal companies for building sites powered by the phenomenal CMS. This blog will delve into revenue growth with Drupal’s roadmap. 

DrupalEasy: Mentoring a team of new contributors at DrupalCon Lille 2023

Image removed.

One of the signature events of every Drupalcon (IMHO) is contribution day, when community members from around the world gather to work together in the same physical space to advance various aspects of the project - from strategic and community initiatives to contributed modules and themes as well as non-code contributions like Promote Drupal and, of course, core contributions.

As part of this, space is always set aside for new contributors, with community volunteers helping to organize, train, and mentor community members new to project contribution. This space strives to be a welcoming environment to those of all skills and skill levels, and includes a "First time contributor workshop" to introduce new contributors to contribution areas and tools.

tl;dr The team I mentored managed to complete the core issue we selected and get it committed to core by the end of the day - something that hasn't happened at a Drupalcon in several years!

Setting a goal

This year, I volunteered to be a mentor in the Mentored Contribution room. Some mentors are provided with a free ticket to Drupalcon, with the understanding that they will not only volunteer a full-day of their time during contribution day, but will also dedicate several additional hours of their Drupalcon experience to attending a mentor orientation, helping out at the Community Mentoring table (graciously provided by Kuoni in the main expo area,) among other tasks.

I've mentored at community events previously (DrupalEasy also provides mentoring services for hire,) so going into the day, I knew exactly what the goals for my "team" were going to be:

  1. Find a core issue that was clear enough for our team to be able to make a strong attempt to get it to a "Reviewed & tested by the community" (RTBC) status by the end of the day - with a stretch goal of having it committed to core before the end of the day.
  2. Learn to work with Drupal.org issue forks.
  3. Utilize DrupalPod (thank you, Ofer!) for all work on the issue.

It is important to note that not all tasks at Mentored Contribution are code and/or project related. The mentoring team does a great job of mentoring other forms of contributions as well.

Finding the right core issue

Having some previous experience, I knew that the first task would likely be time-consuming, so I took it upon myself to spend a couple of hours prior to contribution day to browse through Drupal core issues tagged "Novice" . Finding the right issue to work on during a contribution day is always tricky. Newer core issues tend to be very dynamic with active contributors working on them. Older core issues tend to be more difficult for various reasons - sometimes consensus isn't reached, other times the issue is too complex to be approached by a group in a single day. Prior to the Mentored Contribution day, organizers perform issue triage to narrow down potential issues.

I eventually settled on an issue from November, 2020 titled Add autocomplete attributes on login form and password reset form. The task involved adding some HTML attributes to a couple of core forms to help password managers more reliably target username and password fields. There was an existing merge request (MR) for the issue, but it was without tests (and about two years old.)

This issue seemed to have the criteria I was looking for - something approachable and a relatively straight-forward end goal, something that would allow us to utilize merge requests, and something that required some, but not too much, coding so we had a chance at finishing before the end of the day.

The team

Generally, mentors declare the types of tasks they'd like to work on, then volunteer greeters welcome folks as they show up for the day and bring them to a table to get to work once the "First time contributor workshop" is complete.

Our team consisted of eager new contributors, including: guzmanb, maxime.rffd, hexaki, samuel_orhan, rauch, guiu.rocafort.ferrer, mullzk, and binnythomas.

Image removed.

Using DrupalPod

The mentoring organizers recommend that we use DrupalPod during contribution day. DrupalPod is a browser extension and a set of scripts that make it super-easy to spin up a core development environment on GitPod. DrupalPod utilizes DDEV (something I know a little bit about) and runs completely in a browser, making it very convenient for contribution events like this.

We took some time to ensure everyone was able to spin up their DrupalPod environment for the existing MR, but quickly faced some challenges, as the DrupalPod environment was not launching cleanly.

We worked together to eventually determine that the main issue was the fact that the issue fork was over 2 years old and didn't have an 11.x branch, so the DrupalPod scripts were unable to properly set up the development environment. This allowed our team to learn about diagnosing and correcting issue fork challenges.

This also allowed our team to learn about (and practice) the necessary configuration and workflow for pushing commits from a Gitpod environment back to drupal.org. This involved setting up a temporary .ssh key set (with assistance from DrupalPod) and using Visual Studio Code's Git UI for making pushes (and not the command line.)

These tasks took several hours to complete - ensuring that all team members were staying engaged. 

The issue code

Once we had the development environment and issue fork configured properly, it was time to discuss our approach to completing the issue. Several of our team members had to leave after lunch, so we were left with a core group of individuals, with new contributor guiu.rocafort.ferrer volunteering to take the lead. We planned out the change (and actually expanded the scope of the issue a tiny bit) and I received some guidance from an experienced core developer on what would be a reasonable PhpUnit test for this issue that I relayed back to the team.

I provided some guidance to the team to figure out where the test code should go (a new test class wasn't necessary; we just had to figure out the best existing test class to add to) and an overview of what the (relatively simple) test should look like.

At that point, I felt the existing team members had things well-in-hand, so I stepped back and let them get to work. 

Getting to RTBC

By now, it was mid-afternoon and I was very hopeful that we'd at least be able to get the issue to "Needs review" with an outside chance of "RTBC." While the team worked on the code, I recruited a couple of experienced code contributors to review the code as soon as it was ready.

The team had some minor questions as they proceeded, but no blockers. They were all experienced PHP developers, so for them, this was the easiest part of the task, I suspect.

When they felt they had completed the task, I did a line-by-line code review with them, suggesting several minor changes, before they committed and pushed to the MR. I then alerted our reviewers (jurgenhass and lostcarpark) and they both agreed that it looked good. While this was going on, I alerted the mentoring organizers that we would potentially have a core issue at RTBC.

Live Drupal core commit

As long as I've been a part of the Drupal community, during Drupalcon contribution days, "live core commits" have always been a thing. From what I've been told, there hasn't been one for "several years" for various reasons, so I was quite proud of our team when nod_ showed up to congratulate our team and commit their changes to Drupal core on the big screen at the front of the mentored contribution room

Retrospective

Looking back at the event, the only thing I would have changed is something that was completely out of my control - the fact that over half of our team wasn't able to stay for the full day and get the sense of pride that the rest of the team clearly had watching a Drupal core committer accept their contribution.

Personally, core mentoring is incredibly rewarding, and I always get more out of it than I expect. Along the way, I learned some additional details about DrupalPod as well as the pitfalls (and solutions) when working with old issue forks.

If you're an experienced Drupal developer, I encourage you to make a commitment to dedicate your time to helping to grow the next wave of contributors. If you're interested, say hello in the #mentoring-team channel of the Drupal Slack workspace.

Photos courtesy of Andy Blum

Tag1 Consulting: Scary Drupal Migrations - with Benji Fisher

--- In this Halloween-themed episode of Tag1 TeamTalks, Benji Fisher, a top contributor to Drupal, shares two chilling platform migration stories. In the first tale, set in 2019, Benji tackled a government website project with a tight deadline. The initial plan to use the unstable feeds module for Drupal 8 was alarming, given the project's complexity. Benji opted for the more reliable Migrate API to handle the intricate XML data structure, a decision that ultimately paid off. The second hair-raising story occurred in 2013-2014 during the implementation of HTTPS on a Learning Management System (LMS). Benji had to persuade the client that HTTPS wouldn't harm performance and deal with hardcoded HTTP URLs in JavaScript activities. He devised a clever shell script to convert and edit the URLs, swiftly resolving the issue. Both stories exemplify the unpredictability and challenges of platform and data migration. They underscore the importance of selecting the right tools and techniques. These experiences, though harrowing at the time, now serve as reminders of successful problem-solving and resilience in the tech world. Please let us know if you have specific migration-related topics you'd like to see us cover. Or, reach out and let us know if we can...

Read more michaelemeyers Wed, 10/25/2023 - 06:00