No sooner had I written a blog post suggesting people could sponsor my work on LocalGov Drupal than Big Blue Door had answered the call.

We did it; we’ve reached the last day of DrupalCon Portland 2024. Today was a specialty content day with something for all conference attendees. Largely it was a day of industry summits and training. 

Industry Summits
DrupalCon industry summits provide an exclusive chance to engage and collaborate with Drupal community members who share your field and/or interests. These summits were comprehensive full-day sessions that allow for time to share case studies, strategies, lessons learned, and best practices. For those interested, the Industry Summit series was available as an add-on to the main ticket for an additional fee, offering a focused, enriching experience adjacent to the broader conference in the industries of government, non-profit, higher education, and healthcare, as well as a Drupal community summit option.

Authored by Nadiia Nykolaichuk and Bryan Sharpe.

Smart approaches and tools are shaping the future of content management and website administration, leaving behind the days of tedious manual work. With a click of a button, you can instantly make consistent changes to multiple pages, almost as if wielding a magical wand.

Our team recently attended (and once again sponsored!) the DrupalCon North America conference in Portland, OR. 

This annual conference brings together the Drupal community, from the agencies who provide Drupal services to the industry clients who rely on it, along with contributors and open-source enthusiasts from around the world.

From my perspective on the exhibitors floor, working the booth, I don’t see as many of the great individual sessions that I have in past years. But I did leave with some important takeaways from this year’s event, especially around some upcoming changes for Drupal. 

One of Drupal’s most important features is its ability to integrate seamlessly with other systems (CRMs, eCommerce Platforms, Event Management Platforms, etc). Drupal can expose data using modules like JSON:API, which are integral parts of Drupal Core. Moreover, it can also consume data and make HTTP requests using standard HTTP methods. This post will focus primarily on the latter—highlighting how a module named APITools simplifies the process for Drupal developers.

Background

In researching the history of HTTP request handling in Drupal, I discovered that drupal_http_request has been around since version 5.x. It was described as:

"A flexible and powerful HTTP client implementation that correctly handles GET, POST, PUT, or any other HTTP requests, including handling redirects."

Throughout Drupal versions 6.x and 7.x, drupal_http_request continued to be a go-to option, seemingly simpler than using PHP's CURL function directly—a tool that many developers find intricate. With the release of Drupal 8, Drupal::httpClient replaced drupal_http_request, granting developers access to Guzzle—the de facto HTTP client in the PHP community.

While httpClient/Guzzle is typically the preferred choice for HTTP requests, it's rare that any request happens without some form of authentication. Although OAuth 2 has emerged as a standard for API authentication, the specifics can vary considerably between different APIs. This variability doesn’t mean the principles of OAuth 2 aren’t followed; rather, the implementations differ just enough that attempts to abstract this functionality into a universal module have faced challenges. As a result, developers frequently find themselves writing slightly different code for each API integration to accommodate these nuances. APITools attempts to be just helpful enough in these sorts of situations without making too many assumptions.

Leveraging APITools for the Drupal Zoom API Module

I personally maintain the Drupal Zoom API module, and over the past year, Zoom has changed their authentication requirements. This challenge prompted me to explore the APITools module, maintained by my friend and colleague Alan Sherry. What attracted me most to APITools was its ability to offer configurable options for storing credentials and an extensible client plugin that routes all API requests through a specified authentication method. By using APITools, I significantly reduced the amount of code in the Zoom API module and quickly released a version 3.x, which is compatible with Zoom’s "Server-to-Server OAuth" authentication method. The configuration form and the majority of the API client are now provided by APITools, reducing the amount of code I’ll need to maintain in the Zoom API module.

If you, like me, maintain an API-focused contrib module or need a reliable HTTP client for one-off tasks, I highly encourage you to explore APITools. With a little setup time, you can configure your ApiToolsClient and start making requests effortlessly.

The fact is, there are numerous API client modules on Drupal.org, each tailored for different services. APITools offers an opportunity for a more consistent and efficient approach. I hope you'll check it out!

Getting Started / Examples

We've written some documentation on Drupal.org for you to reference. For a fairly complete example in the Drupal contrib space, checkout the client plugin that is part of the Zoom API module.

Additional Examples

We’ve created a repository with some various API clients that will hopefully help with getting started.

• Acalog - Simple api key implementation
• Auth0 - Access token request with audience and grant type
• Brandfolder - An example of using an sdk as a base with an apitools client wrapper around it
• Localist - Example of a static access token created by an administrator
• Sharepoint - Access token with audience / grant type, and “ext_expires_in” instead of “expires_in”

If you decide to use APITools, we’d love to hear about your experience in the blog comments below.

Last week, I attended DrupalCon Portland 2024, and, like many others, I was swept up in the excitement of the Starshot announcement. The PreviousNext team is ready to support this initiative, focusing our efforts on the Experience Builder project for maximum impact.

Starshot

Starshot is a new concept that accelerates Drupal innovation by providing recipes or templates of best-practice features and configurations when creating a new Drupal site. It’s a separate product built on top of Drupal Core and has the working title “Drupal CMS”.

For years, we’ve pondered the question, “Is Drupal a product or a framework?” The answer has always been “both.” However, we can now clearly distinguish between the two.

We’re fully committed to the vision of bringing Drupal to new audiences by offering a straightforward way to create new Drupal sites using best-practice contributed modules and configuration. Combining Recipes with Project Browser, Automated Updates, and the new Experience Builder initiative will demonstrate Drupal’s full potential for product evaluators.

Releases for Drupal CMS will not be tied to Drupal Core, allowing it to innovate rapidly and evolve as contributed module updates and new best practices emerge. Drupal Core can simultaneously focus on maintaining quality and stability.

Experience Builder

Experience Builder is an ambitious initiative to reinvent how we build pages (experiences) in Drupal.  Core committer Lauri Eskola undertook an extensive review of our own tools (Layout Builder, Paragraphs) and research into competing products to find a model that would best combine innovative user interface design with Drupal’s strengths in structured data.

Our team is in a strong and unique position to meaningfully contribute to the Experience Builder initiative. We have successfully delivered the Pitchburgh competition winner Decoupled Layout Builder prototype. We also provided numerous contributions to Layout Builder in core and contributed modules.

Experience Builder will become our primary contribution focus for the short and medium term, so watch this space.

We hope you are as excited as we are about the future of Drupal. We’re just getting started!