Sometimes, testing can seem complicated, like too much effort or a waste of time. It doesn’t have to be that way! In this video, I show you how to reduce that friction and get the most out of Drupal Test Traits.

Drupal Test Traits is a composer package that allows you to run tests against an existing Drupal site with user content in place. This approach differs from traditional PHPUnit tests that require you to mock up an environment to test individual functionality.

In the video, I take you through the following ways to reduce the friction commonly experienced with traditional testing processes:

• Getting started with Drupal Test Traits
• Writing your first test
• Building a library of project-specific traits
• Maximising your test suite’s performance and reliability
• Fostering a test culture in your development team

Watch the video

Questions? Let’s chat!

Drupal Slack: @mstrelan

Drupal.org: mstrelan

We talk with Matt Glaman about PhpStan and they whys and hows of using it in your day-to-day Drupal development. We also touch on his Drupal 7 compatibility layer experiment and his current writing project(s).

URLs mentioned

• Drupal 7 compatibility layer for Drupal 10 🤯
• Matt's blog 
• PhpStan 
• PhpStan Drupal extension 
• drupal/core-dev 
• PhpStan origin story 
• Usage on Drupal.org for Drupal core (and contributed modules) 
• PhpStan baseline functionality 
• PhpStan strict rules 
• PhpStan deprecation rules 
• Get started with PhpStan 

DrupalEasy News

• Professional module development - 15 weeks, 90 hours, live, online course.  
• Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course.

Audio transcript

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe

Subscribe to our podcast on iTunes, Google Play, iHeart, or Spotify. 

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.
 

Drupal's Webform module is great. It allows users to create forms with all sorts of field types through a UI that's easy to use. It's a great friend to marketers. We use it to power our contact form, collect webinar registrations, and as a lead capture for ebooks.

But data trapped in Drupal doesn't do much good. Data needs to move and flow. It needs to be exported and imported and analyzed and followed up with. It needs to be used.

This is going to be the first of what I hope many more updates regarding the Pitchburgh initiative and the projects involved. Some months, and depending on interest, I’ll be talking about innovation in Drupal as well, and I’d love to see this as a space for dialog and discussion. If this feels like something you are interested in, keep reading and watch this space.

Just as a recap, the innovation initiative, Pitch-burgh was held last month in DrupalCon Pittsburgh, and we can confirm it was a success. We received 35 submissions, which ideas and videos the judges reviewed and voted on. This resulted in 7 finalists.

We even got last-minute funding during the Driesnote itself, Lee Walker at Code Journeymen, and Jonathan at Daggerhart Lab, who offered to fund AmyJune Hineline‘s project, 'Contributing and Mentoring the Mentor'.

But the biggest surprise to me was still to come after DrupalCon dust settled. Matt Mullenweg, (Co-Founder of WordPress) contacted Dries, excited about the initiative and about the fact that we are funding Gutenberg, a project born and linked to the WordPress community. In response, Matt committed to funding the full 20,000 dollars requested by the initiative. I can’t imagine a better example of the spirit of Open Source. What in the paper are competing projects, Drupal and WordPress, in practice open source has made them partners, sharing resources towards a common better goal. And the one who benefits more here is, guess who? The final user. Thanks, Matt! This is a great example of what open source needs to be.

Coming back to the goal of this post, providing Pitch-burgh updates, it was noted by the judges and the Drupal Association leadership (as well as the conversations I could hear in Pittsburgh), that two of the projects are following the same goal, modernizing and improving Drupal’s editorial experience. However, they do it in different ways, be it architecture, data model, user experience, etc. I am talking about the 'Gutenberg in Drupal', and the 'Decoupled Layout Builder initiatives'. There is hence an interest, from the stakeholders in this initiative, but from the community as well, for both projects to align.

This has been received pretty well and agreed upon the project leads, and we just started holding regular meetings between both projects, with the idea to share updates, align goals and look for synergies. I hope to provide more updates on this in my next pitch-burgh update.

In the meantime, you can vote or send me your thoughts on this topic.

Talking about Mentor the Mentor, AmyJune is starting a new role, for which we are excited and we wish her much success. Unfortunately, that means as well that she will be potentially stepping back from her countless contributions to the Drupal community. Said that, this is actually good timing, because her work on this project (Mentor the Mentor) is geared towards giving other mentors the tools to continue her work. I have to say that from the DA we have been impressed with her dedication and commitment from the very beginning of the project and the quality of what she's doing.

As it’s as well the quality of what Brian Perry is doing, with incredibly detailed scope and deliverables on his project: 'Drupal API Client'.

The two last projects worth mentioning are 'JSON data and schemas', and 'Policy-based access in core'. Because both of them are requesting merge requests to happen in Drupal core in the scope of their Statements of Work, we are going to need to align with the core team, pretty much from the start. This could potentially prove a challenge, as some MR against core can sometimes take lots of conversations with months or even years involved, which could be completely misaligned with the project goals and timelines. For this, I am grateful to count on Lauri Eskola’s generosity in his new role as Core Product Manager. We are going to need a good flow of communication between the core team and those initiatives where a merge in core is needed, and Laurii is already providing so much value and help on this.

All in all, all projects are progressing well and as expected. To sum up, during the current phase all projects are aligning on goals, timelines, and deliverables with the Drupal Association. This will result in an agreement between both parties, the DA and the awardees, and it will be reflected in a contract between said parties. The final goal is to make sure the interests of the DA and those of the Drupal community are well represented. We would like to have this phase done and dusted, at some point between July and August (and having into consideration that we're entering the holiday season).

Good news as well! If you want to follow on a weekly or even daily basis what’s happening in Pitch-burgh, all the projects decided unanimously that all conversations and documentation should be happening or published in public slack channels and public Drupal.org issues. You are more than welcome to join and follow the conversations, or just wait for my next update where I’ll share all my highlights.

I don’t want to finish this week's updates without mentioning some great catch-ups and conversations that I’ve had with people like Anoop John and Javier Prada from the association “Drupalera” in Spanish. They are all aligned on teaching and or promoting Drupal. What makes me realize as well that those initiatives and the Promote Drupal one are incredibly aligned with AmyJune's Mentor the Mentor. It would be great to find potential synergies and collaboration opportunities. Projects grow old, and contributors get busy with other things, so sometimes it’s good to get help from new contributors with fresh new ideas, if anything at least to keep the original ideas up and running, and stronger than ever, but hopefully to bring as well new ones, and inject new enthusiasm and speed to the original projects and initiatives.

All in all, a very busy start to the Pitch-burgh initiative, everyone feels excited, very committed, and eager to start, and we can’t wait to see what they are all going to achieve for Drupal.

Beginning today, Drupal core issues reported to the Security Team with risk levels that are "Not Critical", "Less Critical", or "Moderately Critical" may be treated as bugs in the public issue queue, not as private security issues requiring a security advisory and CVE.

Policy Change

The Security Team will use its discretion to handle some issues in public depending on the risk score, the severity of the impact, the difficulty to exploit, and any other mitigating factors.

We still encourage all security researchers to start by filing a private issue that can then be moved public later. Members of the Security Team also will sometimes unpublish a public issue and move it private as needed.

Drupal core issues with risk levels of "Critical" or "Highly Critical" will continue to be private security issues. Some issues with lower risk scores will also be handled privately at Security Team discretion, depending on their impact.

What are some examples?

Exactly which issues are moved into the public queue will be at the discretion of the Security Team members triaging the issue. Some examples of common categories follow.

Information disclosure

Information disclosure is when information that should be private can be seen outside of the intended private context.

A key difference between this and other kinds of security issues is that the circumstances in which it is a security risk often greatly reduce the risk of information being disclosed publicly.

Sometimes, the information being disclosed is already public on the internet without any explicit action from users. For example, if unpublished article teasers accidentally show in a listing accessible to anonymous users, these will be visible to anyone visiting the page including search engines and other crawlers. Keeping the information disclosure bug private does not keep the information itself private in these cases; it is already public.

Other times, metadata about an article like its title or URL is leaked only to users who already have content editing or similar permissions on a site, and via their normal workflows. The potential audience for the leaked information is very small, they may already be seeing it, the impact of learning that secret is likely low.

These issues often require significant active effort against an individual site to exploit. The amount of effort and individual-site nature make them less likely to be exploited.

Scenarios that would make the issue a security vulnerability are extremely uncommon. For example, a vulnerability might expose the content of a field under very specific circumstances. The contents of that field might only be considered important in rare circumstances. In those situations we would tend toward fixing the bug in public.

In scenarios when the information disclosure would represent a great risk to many sites we will not disclose publicly. For example, if you could get access to the passwords of users, or secret keys as an anonymous user, those issues would be handled privately with a security advisory.

Content injection

Content injection vulnerabilities exist when information from a URL ends up reflected in the HTML page, which can result in unwanted content being accessible from a domain. While these bugs are embarrassing, they do not allow other kinds of access unless paired with a cross-site scripting (XSS) or similar vulnerability.

Denial of service

Denial of service is an attack intended to render a site unusable, usually by saturating it with traffic. Certain categories of bugs sometimes make these attacks easier (for example, triggering code that takes a long time to run). However, they are often symptoms of scalability issues or type checking errors, which are routinely fixed in public.

What if sites I manage are concerned about these kinds of issues?

You should monitor the Drupal core issue queue for the 'Security' and 'Security improvements' tags and dedicate resources to helping fix those issues.

What should I do if I find a security issue that might fall under the above?

You should still report the issue privately to the Security Team so that they can verify it is not a symptom of a different security issue (such as access bypass or privilege escalation) and that it meets the guidelines above that allow it to be handled in public. The Security Team may then have you open a public issue and close the private report.

What will happen to issues meeting these criteria that are already open in the private issue tracker?

These will be transferred to the public issue queues for their respective projects over time.

The following people contributed to this public service announcement.

• xjm of the Drupal Security Team
• Michael Hess of the Drupal Security Team
• Nathaniel Catchpole of the Drupal Security Team
• Greg Knaddison of the Drupal Security Team
• Lee Rowlands of the Drupal Security Team
• cilefen of the Drupal Security Team
• Cathy Theys of the Drupal Security Team

Automation has simplified almost everything today and Drupal development is no exception. Drupal developers can now leverage the power of automation to create websites effortlessly and take Drupal development services to a whole new sphere. With automation, it is possible to perform a majority of operations such as managing modules, users, and generating code with a single command. Imagine the extent of productivity boost you’ll accomplish as a Drupal developer if you automate some processes. Besides, companies now prefer to hire Drupal developers with the power of automation in their arsenal.

Given that, if you aspire to get hired by a top-notch Drupal development company, you should begin experimenting with the following tools.

Today, Drupal follows a rapid upgrade process. There was just a two and a half years gap between the release of Drupal 10 in December 2022 and Drupal 9 in June 2020. Whereas, past Drupal versions were released with a gap of around four to five years between them. The need for frequent Drupal migration has left a majority of users grumbling and asking why the CMS releases new versions so rapidly. After all, the migration process is usually complicated, and availing of Drupal migration services involves the expenditure of money and time. 

If you are also tormented by the same question, this blog will act as a beacon and help you get acquainted with the answer. 

In the world of content management systems (CMS), Drupal has long been recognized as a powerful and flexible platform for building websites. Drupal 7, released in 2011, has been a popular choice for many businesses due to its robust features and extensive community support.