LN Webworks: How to Combine React with Drupal

Image removed.

For the uninitiated, React.js, or simply React is an open-source JavaScript library used for creating user interfaces. Over time, it has gained massive popularity due to its incredible performance and efficiency. Interestingly, Facebook is behind the development and management of React. Coming to Drupal, it is a cutting-edge content management system (CMS) that is widely used for website and application development. It is also open-source and is world-renowned for its remarkable flexibility, scalability, and customization capabilities. Due to the massive appeal of the CMS, there are a lot of Drupal development companies today. 

At times, developers just want to bring the two marvelous technologies together to render a quick and smooth frontend based on React.js and a sophisticated backend based on Drupal. This blog talks in detail about various methods for bringing React with Drupal. First, let’s explore headless Drupal against embedded React.

Matt Glaman: A playground to test Drupal code with phpstan-drupal is coming soon!

I'm excited to announce a new feature coming to phpstan-drupal that already exists for PHPStan. PHPStan has an online playground to run and test analysis results. Soon, we will have one for phpstan-drupal! The online playground is an extremely useful tool when reporting bugs to PHPStan and will make it easier to report bugs for phpstan-drupal. 

I had thought about building this previously but was concerned about possible costs. After all, phpstan-drupal is a personal open-source project. It was brought up again in the #phpstan channel in Drupal Slack by Dezső Biczó (mxr576.) In great timing, OPTASY recently signed up as an organization sponsor through GitHub Sponsors. I will use these funds to pay for the playground's operating costs. 

Nonprofit Drupal posts: November Drupal for Nonprofits Chat

Join us on Thursday, November 16 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)

No pre-defined topics on the agenda this month, so join us for an informal chat about anything and everything at the intersection of Drupal and nonprofits.  Got something specific on your mind? Feel free to share ahead of time in our collaborative Google doc: https://nten.org/drupal/notes!

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

This free call is sponsored by NTEN.org and open to everyone. 

  • Join the call: https://us02web.zoom.us/j/81817469653

    • Meeting ID: 818 1746 9653
      Passcode: 551681

    • One tap mobile:
      +16699006833,,81817469653# US (San Jose)
      +13462487799,,81817469653# US (Houston)

    • Dial by your location:
      +1 669 900 6833 US (San Jose)
      +1 346 248 7799 US (Houston)
      +1 253 215 8782 US (Tacoma)
      +1 929 205 6099 US (New York)
      +1 301 715 8592 US (Washington DC)
      +1 312 626 6799 US (Chicago)

    • Find your local number: https://us02web.zoom.us/u/kpV1o65N

  • Follow along on Google Docs: https://nten.org/drupal/notes

View notes of previous months' calls.

Palantir: Beyond Code: Drupal’s Community, Impact, and Possibilities

Image removed.

Drupal isn’t just about code. It’s about community. And the two are intimately connected.

Drupal’s code is itself an expression of the community’s open source values. The code is there for anyone to use, free of charge, and is always evolving as a result of community contributions. That’s substantially different from proprietary software and demonstrates a commitment to collaboration and transparency.

Similarly, Drupal’s evolution is not solely about refining its API or enhancing user interface design – it’s intrinsically linked to shared experiences and mutual learning within the community. DrupalCon allows developers and users from various backgrounds to come together not only to share knowledge about the platform but also to shape the future direction of the software based on collective feedback and diverse needs.

This all means that the story of how Drupal has changed isn’t just about software. It’s also about how we, the community of people who make Drupal possible, understand ourselves.

In this article, we’ll take a look back at the history of Drupal, focusing on the narratives that have shaped the community. In doing so, we hope to provide an insight into the forces that have powered Drupal’s growth and resilience. Furthermore, analyzing the ongoing evolution of these narratives helps illuminate what future shifts may be on the horizon for the Drupal ecosystem.

Looking to the future, we’ll also consider how the community will continue to develop, and why the Open Web Manifesto encapsulates the aspirations this community has expressed for over 20 years. While Drupal itself has kept evolving, what has remained constant is our shared commitment to an open, inclusive, and equitable web.

Sailing on the ship of Theseus

Palantir began using and contributing to Drupal in 2006. Since then, I’ve also served on the Board of Directors of the Drupal Association and helped organize several camps and events. This long perspective has given me some fascinating insights into how Drupal — and its community — have evolved.

When we talk about Drupal, it’s tempting to think about it as the product – as the code itself. But the code that was written in 2001 is not what is running today.

Drupal is like the Ship of Theseus, the subject of a famous thought experiment first written about by ancient Greek philosopher and historian Plutarch. The Athenians wanted to preserve Theseus’s ship, so over many years, they replaced its parts as they wore out, plank by plank. 

The question is: Once all the planks have been replaced, is it still the Ship of Theseus? If it’s not, at what point does it stop being the original ship, and become a replacement? After one plank? After twenty? Or is there a sense of identity the ship possesses that is independent of its parts, related instead to the way people talk about and use it?

For many people, the idea that identity isn’t just about constituent parts helps clarify the paradox. And it also helps shed some light on Drupal. Even if none of the original Drupal code is being used today, a Drupal identity has persisted. This identity doesn’t just stem from one person (not even from Dries!). Rather, Drupal’s special factor has always been its community – all the people who build Drupal and make it work.

It’s the culture -- the values, the assumptions and the beliefs-- of the people sailing on the Ship of Theseus that determine why it’s still the same ship, for all the changes it’s seen.

Drupal is an ecosystem, built by contributors of code and of non-code, backed by an infrastructure hosted by the Drupal Association, supported by businesses, and used by people and organizations to power more than 2% of the top million sites on the web. All of these people coming together make up different parts of the Drupal community – and it’s all of us who really determine what Drupal is, not any specific line of code.

The stories we tell ourselves

The stories we tell ourselves have been a major driver of Drupal’s ability to achieve ongoing success and remain resilient as a decentralized, global and volunteer-based open-source project. They are narratives that tie together the hundreds of thousands of contributors over Drupal’s history.

These shared stories reflect Drupal’s culture. And what they show is that our culture has been substantially shaped by non-code contributions from businesses and individuals — more so than by the code itself.

Let’s consider three key narratives that have shifted over time to gain an insight into the forces that have powered Drupal’s growth and resilience.

Eat your own dog food? No, get off the Drupal island!

“Dogfooding” is a term used for the practice in which tech workers use their own product consistently to see how well it works and where improvements can be made.

In the early days of Drupal, there was a strong ethos of “eating your own dog food” — building tools for the community’s needs using Drupal itself. With Drupal as their hammer, contributors approached many tasks as nails that could be driven home by extending Drupal.

Much of this was born of necessity in the absence of alternatives. Drupal provided the Groups module for community interaction before social media existed. The Project module enabled collaboration before Git. Local Drupal camps relied on homegrown event management systems like COD. The Drupal Association itself was formed partly to provide infrastructure after early infrastructure failures.

Over time, however, the Drupal community embraced integrating with external tools better suited for certain tasks. Infrastructure moved to Git and Slack. Camps adopted specialized event registration systems. Core adopted the Symfony framework.

While retaining its innovative spirit, Drupal evolved to focus on its strengths, looking to other technologies to inspire and augment its capabilities. The narrative shifted from an insular “eat your own dogfood” to a more outward-looking “get off Drupal island.” The big tent expanded to include complementary tools, acknowledging that Drupal need not solve every problem alone.

This evolution demonstrates the community’s pragmatism and maturity. By recognizing external solutions, contributors avoid reinventing the wheel. The new narrative reflects a holistic understanding of how Drupal fits into the broader technology landscape.

Talk is silver, code is gold? No! Come for the code, stay for the community.

In the early days of Drupal, the dominant narrative was “talk is silver, code is gold” — only contributions to the codebase mattered. However, over time the community realized the interplay between community-focused activities and code contributions provided mutual benefit. Research shows community participation expands social ties, shapes strategy, and focuses innovation, even without directly affecting code productivity.

Drupal’s evolution reflects the growing appreciation of community-oriented work. Adoption of a Code of Conduct for events marked increased investment in healthy interactions. The creation of the Community Working Group demonstrated the importance of conflict resolution. Rewriting the Code of Conduct in plain language and forming a Community Health Team required tremendous time and emotional labor — but is strong evidence of the value now placed on community. Local Drupal communities now actively collaborate. Shared playbooks spread knowledge and regions like Europe brought back DrupalCon.

The narrative has now shifted from “talk is silver, code is gold” to “come for the code, stay for the community”. This underlines how vital non-coding work is in enabling Drupal’s success.

Scratch your own itch? No, if you want to go far, go together!

Early Drupal embodied the “scratch your own itch” ethos — solve your own problems and build what you need. Drupal was likened to a box of Legos: you could find many disparate pieces, and sometimes there were instructions on how to build with them. But if you couldn’t find what you wanted, you’d have to come up with your own design.

This attitude combined with what we might call a “benevolent dictator for life” model, whereby community members felt they needed permission from Dries before undertaking anything major. Indeed, many sought intervention from Dries across code, governance, and conflict resolution, developing unhealthy hierarchical expectations. Disagreements often devolved into “epic bikeshedding”, resulting in exhausting debates where the most stubborn prevailed unless a particular argument caught Dries’s attention.

As the community grew, this proved unsustainable. While some called for more hierarchy, Drupal resisted a full leadership structure. Code may have correct answers, but people and social issues are messy. Extending hierarchical expectations to non-code contributions risked grinding everything to a halt, replicating the “bikeshedding” debates.

Instead, Drupal evolved from “scratch your own itch” individualism towards “if you want to go far, go together” collaboration. This new era saw greater coordination through strategic initiatives and working groups. These collective efforts enabled tackling challenges at scale rather than relying solely on individual contributors. Work could be distributed across many hands to achieve impact not possible alone.

Another major non-code innovation was the contribution credit system. Traditional open source celebrated individual contributors and their achievements. But Drupal needed to accommodate organizations like governments wanting collective credit.

Rather than giving organizations direct commit access, Drupal pioneered contributors claiming credit for their organizations. This preserved individual recognition while tracking organizational impact. Crucially, the system included non-code work from the start.

Though imperfect, contribution credits surface essential non-coding activities like documentation, mentoring, and event organizing. Granting visibility makes the work more valued. It says all contributions, not just code, are worthy of recognition.

Businesses have also collaborated to provide infrastructure, funding, and other resources for collective benefit. 

Future projections: Networked, regenerative, listening

As Drupal continues to evolve, three potential paths forward emerge from these past narratives. These point to a future in which Drupal will become more networked, more regenerative, and will invite even more community listening.

  • Networked
    Past centralized coordination efforts brought much-needed structure but also new complexities. Consensus and decision-making become challenging at scale.

    In the future, a compromise solution will exist in the form of networking — decentralized creative partnerships and empowered teams tailored to specific needs. Breaking down work into smaller scopes makes problems more tractable, shifting the mindset from scarcity and exclusivity to abundance and inclusion. Creative partnerships facilitated through the Drupal Association can promote consent-based and “safe to fail” decision-making, while flexible contribution models will allow individuals and businesses to smooth resource constraints.
     
  • Regenerative
    Drupal creates tremendous value but cannot fully capture or distribute it equitably. Anti-patterns of exploitation and burnout persist, disproportionately affecting core contributors.

    To sustain success, Drupal must encourage, enable, and recognize pro-community actions. It must also differentiate which parts of the ecosystem are public goods that anyone should be able to use for free, and which are more akin to commons — that is, to areas that require a degree of care and input from those using them. Not all of Drupal’s major cost centers are public goods.

    Strengthening organizational protocols, growing leadership pipelines, planning for transitions, and sharing knowledge will make the ecosystem more sustainable and resilient without being exclusive. Regenerative practices that distribute effort and reward more equitably will reduce burnout. The result is a system built to thrive through ongoing renewal of its most vital asset — engaged contributors.
     
  • Listening
    Getting off the island helped make us aware of the bigger picture. We need to think globally before we act locally.

    This means tending to the Drupal ecosystem by structuring for flexibility. Accommodating different contributor types enables pioneers, maintainers, and coordinators to play their roles. The Drupal Association ought to act as a kind of town planner.

    At the same time, we must also shape the external landscape by collaborating with other open source communities. Providing feedback on policies like the EU Cyber Resilience Act makes the terrain more hospitable for open source as a whole. Listening through participation in the open web movement will help contextualize Drupal’s place and influence. It allows acting both locally and globally — solving immediate needs while advancing the broader open technology ecosystem.

The Open Web Manifesto

Like any living system, Drupal must continuously adapt while remaining true to its core values. The Open Web Manifesto articulates Drupal’s commitment to an open, decentralized, inclusive web built on freedom and participation.

The manifesto declares the Open Web a cause driven by principles, not just technology. It must be permissionless, letting anyone contribute. No single entity controls it. The Open Web welcomes all as users, creators, architects, and innovators regardless of identity or status. Sustaining it requires deliberate, collaborative effort.

Drupal sustains the Open Web through its creativity, diversity, and integrity. Its global community puts open source collaboration into practice, introducing participatory digital experiences. This empowers Drupal's partners, contributors, and users alike.

By remaining true to its ethos while adapting to a changing world, Drupal can keep shaping an equitable digital landscape. The narratives that brought Drupal this far — from independence to interdependence, visibility to value, and co-opetition — point towards an even more vibrant, resilient and regenerative future. 

If Drupal continues listening to its community’s needs while engaging with the global ecosystem, it can flourish for decades to come as a thriving open source leader empowering people to build a better web.

Cropped version of Drupalcon 2009 - Paris - 17 by Chris Heuer licensed under CC BY-NC-SA 2.0 DEED.

Community Culture Drupal Open Source

The Drop Times: Exploring the Drupal Universe: A Conversation with Oskar Calvo

Discover the vibrant world of Drupal through the eyes of Oskar Calvo, a passionate Software Architect at Hiberus Tecnología. Delve into Oskar's journey in the Drupal ecosystem, his recent workshop at DrupalCamp Spain, and the driving force behind his dedication to this open-source platform. Uncover insights from Oskar's workshops, his role at Hiberus Tecnología, and his perspectives on the evolving landscape of web development and content management systems. Join us for an in-depth conversation that unveils the story of Oskar Calvo and his remarkable exploration of Drupal.

TEN7: Adding Bundle Subclasses to Drupal Core 9.3.0 (Part 3)

In Part 1 of this blog series, we explored the concepts of entities, bundles, entity classes, and the new feature of bundle subclasses now available in Drupal Core 9.3.x. In Part 2, we looked at some specific code samples to see some of the ways to use this feature to make your life better. Now we turn to the story of what it took to get this feature included in Drupal Core: using a Gitlab merge request (MR) instead of patches, what it takes to get something like this committed, how and why to contribute “upstream,” and more.