Specbee: Cooking up irresistible Drupal websites with Recipes

Drupal's ongoing evolution has seen many innovations, with the latest being the introduction of Recipes with the “Recipes Initiative” in Drupal 10.3. Recipes, now part of the core of Drupal, represent a significant shift in how developers can automate the setup and configuration of Drupal sites. A Recipe explores the idea of “composibility” which will enable people to compose a Drupal website as per the need or at least a solid foundation. In this article, we’ll discuss Recipes in detail - what they are, why they’re fantastic, and how you can use them to create a perfectly crafted site. Get ready to cook up a storm with a foolproof recipe for Drupal success! But we already have Distributions! The concept of pre-configured packages is not new to Drupal. It was first introduced in Drupal 5 as Drupal distributions that include the Drupal core, along with additional modules, themes, and configurations aimed at serving a specific use case or industry. This concept made it easier for developers to quickly set up Drupal for specific applications like intranets, e-commerce sites, or government portals without starting from scratch. However, Drupal distributions offer a convenient way to get started with pre-configured setups, but they come with some drawbacks: Limited Flexibility: Predefined features and tightly integrated modules make customization difficult. Maintenance Complexity: Updating distributions can be challenging due to custom configurations, leading to potential compatibility issues. Dependency on Maintainers: Some distributions may be poorly maintained or abandoned, causing risks to security and updates. Performance Overhead: Unnecessary bundled modules can slow down the site and introduce vulnerabilities. Niche Focus: Distributions are often tailored to specific use cases, making it difficult to adapt if your needs change. Drupal Recipes solves problems with distributions by offering more modularity. Instead of coupling everything together, Recipes let you add only the specific features you need, avoiding the bloat of unnecessary modules. A Recipe in action To illustrate, imagine I need to set up an Event feature. For this, I will apply (Recipes are not installed but rather applied) an “Events Content-Type” Recipe which will set an Event content type with necessary attributes & fields, and configure views, metatags & paths for the Event contents. This will give me a solid foundational starting point to implement the feature where 70-80% of the basic setup and configurations are done by Recipes and on top of it I can make customizations to configure other settings as per my requirements. However, once applied, I am no longer dependent on the Recipe package anymore and it can be safely removed from my project keeping all the configured setup intact. Benefits of Drupal Recipes Modular Setup: Recipes allow for specific features or configurations to be added individually at any point in a project timeline.  Combine Multiple Recipes: Recipes can be easily combined or modified to fit specific use cases. This allows for a more customizable site-building experience, making it easier to adapt to changing requirements. No Lock-in: Unlike distributions, which are often tightly integrated, recipes give you more freedom to swap out or upgrade parts of your setup without being tied to a rigid structure. Composable: As mentioned above you can combine multiple recipes which means you can also compose Recipes with other recipes easily. If you want Event registration but also Commerce capabilities, you can easily create a new recipe that will apply the Event and Commerce recipes to be set up. What Recipes can do Install Modules and Themes: Recipes can automatically install necessary modules and themes. Apply Configurations: Recipes can apply both default and selective configurations provided by modules. Update Configurations: Recipes can update module configurations to fit your site's needs through' config actions'. Composable and Reusable: Recipes can be composed of other Recipes, making them highly modular and reusable across different projects. What Recipes cannot do Custom Code or Hooks: Recipes do not include custom PHP code, hooks, or API integrations. Module-Like Functionality: Unlike modules, Recipes cannot contain custom plugins, forms, or other typical Drupal module structures. Persistent Locking: Recipes do not persist after application; they set up the initial state and can be safely removed. Want to take full advantage of Drupal Recipes? Schedule a consultation with our experts and discover how our Drupal development services can help boost your site's growth! How to create and use a Recipe To get started, it is recommended that a new custom repository is created for the recipe. This will ensure that the recipe is version-controlled & managed efficiently to be used on other projects.  At the bare minimum, a recipe will require a “recipe.yml” file as the required file which will define the meta information like name, and description along with installations of modules/themes & configuration installations/updates. Apart from the “recipe.yml” a Recipe can also have the below optional items. The “config” directory holds the configuration entity yml files which will be installed when the Recipe is applied. The “content” directory holds the content entity yml files which will be created after the Recipe is applied. A “composer.json” file that allows the discoverability of Recipes via Composer. It will define any dependencies the Recipe might have on other modules or themes. A “README.md” can also be included to give a brief description of the Recipe which will allow users to better evaluate. So, the folder structure of a Recipe can look like this: recipe_name       ◦ recipe.yml       ◦ config           ▪ node.type.event.yml       ◦ content           ▪ node               • 43940d31-0106-46b4-ba32-39e511eb1f4a.yml       ◦ composer.json       ◦ README.md Dissecting the recipe.yml file A “recipe.yml” at minimal consists of “name” & “description” keys. Apart from that, it can include three different keys: Install packages with the “install” key which will specify the modules and/or themes to be installed when the Recipe is applied. If not already installed, Drupal will proceed to install each of the modules & themes specified in the list. install:   - address   - datetime_range   - media   - media_library   - geolocation_address   - geolocation_leaflet   - layout_builder   - metatag   - pathauto   - paragraphs   - smart_date Configuration related task under “config” key. This allows you to “import” configurations from a module in two ways     • Import all the configurations from a module with the “*” wildcard. This will import all the base configurations & optional configurations from a module.    • Import selective configuration from a module by specifying the list of configurations to be imported. config:   import:     media: "*"     node:       - views.view.contentWhen you want to update any active configuration which is being imported or any existing once, “action” comes into play which will allow you to update those configurations config:   actions:     metatag.settings:       simple_config_update:         entity_type_groups.node.event:           - basic           - advanced     workflows.workflow.editorial:       addNodeTypes:         - event Dependency on other recipes can be included under the “recipes” key which specifies the list of Recipes to be applied prior applying the current Recipe. recipes:   - core/recipes/image_media_type   - core/recipes/editorial_workflowApplying a Recipe Until reaching Phase 2 and a user interface (UI) for easier application, recipes are currently applied using Drupal core's PHP script. It can be executed with the following command in the CLI Drupal root: php core/scripts/drupal recipe recipes/recipe_nameAfter applying the recipe, it's also necessary to clear the caches to ensure the changes take effect. Applying a hosted Recipe If you Recipe has a “composer.json” file then it can be hosted on Packagist.org to make it discoverable and included in any project. However, to download the recipe in a “recipes” directory there are few changes which are required to be made in the project’s “composer.json” file composer require oomphinc/composer-installers-extender:2.0.1Update “installer-types” & “installer-paths” keys in the “composer.json” "installer-types": ["drupal-recipe"], "installer-paths": {   "web/recipes/{$name}": [ "type:drupal-recipe" ] }When you request Composer for a recipe, it will automatically place it in your project's “recipes” directory, similar to how it handles modules or themes. Once this is setup, you then you can use composer to require the package as usual.For this example, I am using a sample recipe which set ups an Event content type along with other configurations updates.  https://github.com/malabya/event_content_type/ composer require imalabya/event_content_type Once downloaded this can be applied with the Drupal core scripts php core/scripts/drupal recipe recipes/event_content_type Once the recipe is applied this will create an Event content type and enable Editirial workflow for the Event content type with default core configurations. This will also create 2 default contents for the Event content type to get started. Unpacking Recipes Even though Recipes do not lock in your site and can be safely replaced or removed once applied, you would want to maintain the dependencies in your project. When you request a Recipe, it will download all the dependencies mentioned in the Recipe’s “composer.json” file, but these dependencies are not copied/unpacked over into the project’s “composer.json” which will make it difficult to maintain or upgrade those dependencies. For this, use the composer plugin Drupal Recipe Unpack Composer Plugin to your project’s “composer.json” which allows the extraction of a packages dependencies into the project root composer and lock files for the sole purpose of implementation within Drupal recipes. Once the plugin is installed you can run the below command to unpack the dependencies composer unpack [organization/package-name]Final thoughts Recipes in Drupal 11 represent a powerful new tool for site builders and developers. They offer flexibility, modularity, and ease of maintenance that surpass traditional installation profiles and distributions. When it comes to creating a new Drupal site or adding new features, Recipes provides a streamlined, efficient way of managing the configuration. As Recipes continues to evolve, they promise to make Drupal site development more agile and responsive to changing needs, ultimately making Drupal a more accessible and powerful platform for all users. So do you want to cook from scratch or use Drupal Recipes? Your choice! Want to know how Drupal Recipes can enhance your project? Reach out to us to learn more about our Drupal development services and get started on your next big idea!

drunomics: Why we don't use GraphQL

Why we don't use GraphQL wolfgang.ziegler Mon, 09/16/2024 - 21:38 Exploring drawbacks of GraphQL in decoupled Drupal, including complexity, loose contracts, performance issues, and security concerns. RESTful alternatives are discussed. Body

At drunomics we are building decoupled Drupal sites for more than five years. During this time, GraphQL has always been a popular choice for decoupled Drupal sites among professional or enterprise projects, thanks to the well maintained GraphQL contrib module. Still, I've vetted against using GraphQL for various enterprise projects, even though sometimes it was appealing to customers. In this blog post, I'd like to summarize why we don't use GraphQL:

General complexity

GraphQL is not only a new query language to learn for both frontenders and backenders, moreover the backend has to support any kind of queries the frontenders make. On the frontend side of things, additional libraries and tooling is needed to handle the protocol.

Loose contracts

GraphQL gives a lot of power to frontend developers, but that comes with a huge price: No defined or a very loosely defined contract, i.e. the data model or more specifically the GraphQL schema layered on top. Based upon this loose contract the frontend may compose any kind of queries, which the backend has to support. What leads to the next point:

Complex queries

When the backend is exposing the Drupal data schema directly, potentiallly a lot of things become leaked unwanted and changing things might became hard, because: Who knows what data properties the frontend uses and queries for? It's quite hard to optimize for every use-case.

However, the backend may compose it's own GraphQL schema and provide exactly the data model as needed by the client, the frontend. That's indeed, a great option to have, but it requires additional work and code to translate between the schema and the real data model behind. It makes it possible to change the underlying data model and schema mapping, while staying with the same or compatible GraphQL output and schema. But is that code performing the mapping performant enough? Does it work correctly? That's quite hard to tell without knowing exactly the queries one has to optimize and test for. So things are or become complex.

Performance

First of all, GraphQL is bad for caching since it makes use of POST requests. The typical work-around is to use shortened, hashed queries and to access them via GET requests, what can help to mitigate the issue. But this comes at the cost of tying the deployed frontend and backend versions, thus increasing overall system and deployment complexity. That way, the main GraphQL advantage - flexibility at the frontend - gets lost. So not an easy or great compromise to make.

Client driven data fetching

With GraphQL, the web browser (or generally the client) sends a query to the server, specifying the exact data it needs. While this can help to reduce payload size, it puts the client in the "driving seat". That often leads to additional round trips being required: Based upon the first request, often additional data is required for rendering it. This additional data often has to be fetched in additional requests, thus requiring another or multiple round-trips to the server and thus increasing latency.

In contrast, when the server is in the "driving seat", it may efficiently do all queries and resolve additional data, and then send the resulting data over the slower network once.

Security

GraphQL queries can expose sensitive data if not properly secured. This can be mitigated by implementing proper authentication and authorization mechanisms. However, this can get very complex easily: Since the server does not know the queries needed by the client, it needs to handle every possible combination a client may request. Unfortunately, it's commonly rather easy for hackers to purposely write computationally very expensive (GraphQL) queries and to send them to the server, thus opening the door for DDOS or even DOS attacks.

Besides that, due to the complexity of the backend having to cover all possible combinations, the danger for data leaking accidentially becomes rather high.

The conclusion

GraphQL comes with a couple of issues, which are - as usual - solvable. That's a price one might want to pay in certain situations, if the benefits are worth it. Thus, is using GraphQL a good idea? As so often, it depends. But in my experience, it's more often not, than it is.

Alternatives are RESTful

The typical alternative to GraphQL is a RESTful API. As usual, with Drupal there are a couple of good options:

  • Drupal comes with the JSON-API out-of-the box, which is a great feature to have. While it's good fit in certain situations, it also faces some of the issues mentioned above, most notable "Client driven data fetching" and "Loose contracts".
  • Developers may use Drupal's API to provide custom-coded RESTful endpoints for the client. That addresses all mentioned concerns, but requires backend development time for every feature and most notable careful planing. This comes with the downside of frontend developers loosing the flexibility. (By the way, this is what GraphQL is loved for!)
  • Configurable RESTful endpoints. In order to improve the development process and gain flexibility in the frontend, we developed a solution for providing custom RESTful endpoints that are configurable via Drupal, by frontend developers. For that, we improved the Custom Elements module, which is part of Lupus Decoupled Drupal, such that it integrates with Drupal's configuration sytem and provides an UI for customizing output by entity view-mode. That way, in many situations, we can tick all the boxes, while enabling the frontend developer to work efficiently. I'll share more details about the new Custom Elements UI in a dedicated blog post later this week.

Nonprofit Drupal posts: September Drupal for Nonprofits Chat

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

We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits.  Got something specific you want to talk about? 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.

Talking Drupal: Talking Drupal #467 - Config Actions System

Today we are talking about The Config Actions System, What it does, and how it helps with Drupal Recipes with guests Alex Pott and Adam Globus-Hoenich. We’ll also cover the Events recipe as our module of the week.

For show notes visit: www.talkingDrupal.com/467

Topics
  • Explain Config Actions
  • Is this related to the Actions UI
  • How are config actions used in Drupal
  • How will the average user interact with Config Actions
  • What does non-desctructive mean
  • Where did the Config Action system come from
  • Future of the Config Action system
  • How can people help out
  • How does the Config Action system help with Drupal CMS
Resources Guests

Alex Pott - alexpott Adam Globus-Hoenich - phenaproxima

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Nate Dentzau - dentzau.com nathandentzau

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

  • Brief description:
    • Have you ever wanted to set up and configure a robust events system in your Drupal website, in just a few seconds? There’s a recipe for that.
  • Module name/project name:
  • Brief history
    • How old: originally created in Mar 2013 as a distribution, but reborn as a recipe in July 2024
    • Versions available: 1.0.0-alpha3, compatible with Drupal 10.3 and 11
  • Maintainership
    • Actively maintained
    • Security coverage? - no stable release
    • Documentation in the works
    • Number of open issues: 1 open issue, which is a bug
  • Usage stats: not tracked for recipes
  • Maintainer(s): mandclu
  • Module features and usage
    • Listeners probably won’t be surprised to hear that Smart Date is at the heart of what you’ll get when you apply the Events recipe
    • You will have an Event content type, and a view to list upcoming and past events
    • The recipe will also set up add-to-calendar links on your event page, making it easy for your site visitors to be reminded of when your event will take place
    • There are companion recipes to add a calendar view, to be able to associate locations (with maps), and to add event registration
    • A modified version of the Events recipe has already been integrated into Drupal CMS, so it will be even easier to apply for a site based on that
    • Internally it makes use of the createIfNotExists and setComponents config actions, which is why I thought it would be relevant to today’s discussion

The Drop Times: QED42's Journey in Shaping Digital Experiences: Insights from Piyuesh Kumar

Discover how QED42 is shaping the future of digital experiences! In this exclusive interview, Piyuesh Kumar, Director of Technology at QED42, shares insights on their journey with Drupal, their groundbreaking contributions, and the role of AI in transforming content management systems. Get a sneak peek into the upcoming advancements in Drupal and what to expect at DrupalCon Barcelona 2024. Don't miss this deep dive into QED42's vision and impact!

ThinkDrop Consulting: Reflections on OpenDevShop and the hidden costs of open source maintainership.

Reflections on OpenDevShop and the hidden costs of open source maintainership. Jon Pugh Mon, 09/16/2024 - 09:34

#OpenDevShop failed because it tried to solve too many problems at the same time.

This directed the energy away from designing for the future. When the future arrived, it was wholly unprepared.

I saw the potential to make #Aegir an all-in-one management console for all your web tech, so I created server management things, and local CLI things, and other silly, not so useful things.

DevShop became a huge burden. Unmaintainable. Un-upgradable. Working untold unpaid hours, self-funded travel and speaking took a major toll on my life, financially and personally.

#! code: Drupal 11: Using The Finished State In Batch Processing

This is the third article in a series of articles about the Batch API in Drupal. The Batch API is a system in Drupal that allows data to be processed in small chunks in order to prevent timeout errors or memory problems.

So far in this series we have looked at creating a batch process using a form and then creating a batch class so that batches can be run through Drush. Both of these examples used the Batch API to run a set number of items through a set number of process function callbacks. When setting up the batch run we created a list of items that we wanted to process and then split this list up into chunks, each chunk being sent to a batch process callback.

There is another way to set up the Batch API that will run the same number of operations without defining how many times we want to run them first. This is possible by using the "finished" setting in the batch context.

Let's create a batch process that we can run and control using the finished setting.

Setting Up

First we need to create a batch process that will accept the array we want to process. This is the same array as we have processed in the last two articles, but in this case we are passing the entire array to a single callback via the addOperation() method of the BatchBuilder class.

Read more

Wim Leers: XB week 16: better UX thanks to ghosts & Redux

A new record week: 26 MRs merged! :D Too much to cover, so going forward, I will only write about the most notable changes.

The simplified zoom interface landed thanks to Jesse “jessebaker” Baker and Gaurav “gauravvvv” — with not only better controls, but also a much smoother UX:

Image removed. Smooth zoom with pinch and using the slider!
Issue #3464025, image by Jesse.

Bálint “balintbrews” Kléri, Jesse and Ben “bnjmnm” Mullins integrated the existing “undo” functionality with the component props form, resulting in the UX you’d hope:

Your browser does not support playing videos. You can download it instead.

When undoing, the component props form on the right-hand side updates and the preview updates in real-time.
Issue #3463618, video by Bálint.

Now that many fundamental pieces exist, it’s time to build upon the foundations that we have. Five weeks ago, Ben added Redux integration to the component props form, resulting in live updates. That started out with a limited set of form elements supported. Harumi “hooroomoo” Jang added support for one more this week: <select>.

Image removed. SDC prop shapes using enum now work thanks to expanded Redux integration. For example, you can now change the column width.
Issue #3471083, image by Harumi.

(By the way: Bálint’s epic video showing undo/redo above? That’s also powered by the Redux integration!)

Bálint and Gaurav improved the UX by removing six lines of CSS: instead of an abstract placeholder being dragged and visualized in the currently hovered drop target, now a ghost of the component being moved is visible:

Image removed. Ghost of the component at the drop target: better visualization of what is about to happen.
Issue #3469895, image by me.

Two weeks ago, we gained support for actual trees. This revealed a number of bugs in the UI that had up until that time, been ahead of the back end. Another one of those was squashed this week by Bálint, Ted and I: you can now actually drag components into empty slots :D

Missed a prior week? See all posts tagged Experience Builder.

Goal: make it possible to follow high-level progress by reading ~5 minutes/week. I hope this empowers more people to contribute when their unique skills can best be put to use!

For more detail, join the #experience-builder Slack channel. Check out the pinned items at the top!

Empowering SDC developers

Less visible, but equally important because it boosts the productivity of the fine folks working on the Starshot Demo Design System by making XB be more explicit about what Single-Directory Components (SDCs) prop shapes it provides a complete UX for. Since last week, a sibling Component config entity is auto-generated for every SDC meeting the minimum criteria. This week, Feliksas “f.mazeikis” Mazeikis expanded the list of criteria:

  1. Since #3469461, any SDCs that we know for sure won’t work well in XB (yet!) no longer show up in the XB UI. (In more detail: when we have no way to store a particular prop shape yet: XB does not yet support type: array prop shapes yet, for example.)
  2. Since #3470424, SDCs marked as obsolete won’t get a Component config entity auto-created. But if it already exists (and hence may be in use), the config entity is not deleted, just disabled.

Evidently that could lead to surprising situations, especially while developing SDCs. So, he’ll be adding a UI that lists the reason for an SDC not being available in XB next.

In the background, back end folks empowering the front end

Ted “tedbow” Bowman helped the back end race ahead of the front end: while we don’t have designs for it yet (nor capacity to build it before DrupalCon if they would suddenly exist), there now is an HTTP API to get a list of viable candidate field properties that are able to correctly populate a particular component prop. These are what in the current XB terminology are called dynamic prop sources 1 2.

Travis “traviscarden” Carden and I made XB’s use of OpenAPI go much further than it did when it landed 3 weeks ago): rather than only validating API response bodies, it now also validates request bodies — hence catching an entire category of bugs on the client-side automatically. Clearer errors = faster iteration!

Week 16 was August 26–September 1, 2024.

  1. Dynamic Prop Sources are similar to Drupal’s tokens, but are more precise, and support more than only strings, because SDC props often require more complex shapes than just strings. ↩︎

  2. This is the shape matching from ~3 months ago made available to the client side. ↩︎