Category: Open Source

Jill Scott has been back in her home city to officially open her sister’s new shop, Dolly Dancewear.

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!

Some Software Engineers mention “not being interested” as an excuse not to help someone with something that could benefit customers or the Software Engineering community at large (including the Ruby community) when the real reason is in fact covert discrimination against that person and lack of effort to treat them as an equal and equally respected member of their community. Know that Software Engineers have to abide by the Software Engineering Code of Ethics. And, it includes the statements: “Software engineers shall act consistently with the public interest” and “Software engineers shall be fair to and supportive of their colleagues”.

Release Information page.

AWS transfers OpenSearch to the Linux Foundation to support a vendor-neutral community for search, analytics, observability, and vector database software. Read more at linuxfoundation.org

The post Linux Foundation Announces OpenSearch Software Foundation to Foster Open Collaboration in Search and Analytics appeared first on Linux.com.

Stay updated on what’s happening in the forums!

Last week, Julio Merino published an article I wish someone had written ages ago: a fair, unbiased look at the differences between Windows NT in its original form and UNIX roughly at the time of the initial releases of Windows NT. Merino, who has a long career in tech and has made contributions to several operating systems, does a great job cutting through the fanboyism and decades’ worth of conventional wisdom, arriving at the following conclusion that I think many of us here will share even without diving into the great depth of his article. NT was groundbreaking technology when it launched. As I presented above, many of the features we take for granted today in systems design were present in NT since its inception, whereas almost all other Unix systems had to gain those features slowly over time. As a result, such features don’t always integrate seamlessly with Unix philosophies. Today, however, it’s not clear to me that NT is truly “more advanced” than, say, Linux or FreeBSD. It is true that NT had more solid design principles at the onset and more features that its contemporary operating systems, but nowadays… the differences are blurry. Yes, NT is advanced, but not significantly more so than modern Unixes. What I find disappointing is that, even though NT has all these solid design principles in place… bloat in the UI doesn’t let the design shine through. The sluggishness of the OS even on super-powerful machines is painful to witness and might even lead to the demise of this OS. ↫ Julio Merino You should definitely read the whole thing, and not just the conclusion, as it will give you some great insight into some of the differences between the two approaches, and how the UNIX and Windows NT worlds learned from each other and grew together. It’s well-written, easy to read, and contains a ton of information and details about especially Windows NT most people are probably not aware of. Reading through the article helped my crystallise a set of thoughts I’ve been having about the future of Windows, and in particular, the future of Windows NT as a short-hand for the kernel, lower-level frameworks, and everything else below the graphical layer. I think there’s a major change coming to Windows NT, something so big and unheard of it’s going to be the most defining moment in Windows NT history since its very first release. There’s a few facts that lie at the root of my conclusion. First, ever since the very beginning, Windows NT has been developed in roughly the same way: behind closed doors by a group of specialists inside Microsoft, and every now and then we got a massive dump of new code in the form of a major Windows release. It’s only recently that Microsoft has started taking a more rolling release approach to Windows development, with smaller updates peppered throughout the year, with different release branches users can subscribe to. Second, despite many of us almost equating Microsoft with Windows – or perhaps with Windows and Office – the reality of it is that Windows hasn’t been the primary driver for revenue for Microsoft for a while now. In Microsoft’s fiscal year of 2023, Windows made up just 10% of the company’s total revenue that year, which amounts to $22 billion out of a total revenue of $211 billion. Azure alone is almost four times as large at $80 billion, and even LinkedIn – yes, LinkedIn – is good for $15 billion in revenue, making Windows only about a third more profitable than the most soulless social network in human history. Third, despite Windows’ decreasing revenue share, the operating system is becoming ever larger in scope. Not only does it need to cover the literally infinite possible combinations of x86 hardware in both the desktop/laptop and server space, it now also needs to cover what is surely going to be a growing market for ARM hardware, starting with laptops, but surely expanding to desktops and servers, too. Microsoft needs to foot the bill for all of this development, and for how much longer can the company justify spending an inordinate amount of money on a massive army of Windows developers, when the revenue they bring in is such a small part of the company, and a part that’s decreasing every year, to boot? Fourth, the competition Windows faces is surprisingly strong. Not only are macOS, Chrome OS, and even the Linux desktop doing better than ever, mobile computing is also competing with Windows, and that’s a space Microsoft is simply not present in at all. This is especially pressing in the developing world, where often people’s first and only computing experience is mobile – through Android, mostly – and Microsoft and Windows simply don’t play any role. Given these facts, there’s only one reasonable course of action for Microsoft. I think the company is going to address all of these issues by releasing large parts of Windows NT as open source. I base this on a gut feeling bourne out of the above facts, and not on any form of insider information, and there is a 99.9% chance that I am wholly, completely, and utterly wrong. Still, deep down, I feel like releasing Windows as open source makes the most sense considering the challenges the operating system and its parent company are facing. You and I are going to witness Windows NT’s source code being published as open source on GitHub by Microsoft within 5-7 years, accompanied by an open governance model wherein contributions are welcomed and encouraged. Even if such a step will not be taken by Microsoft, I am convinced that, in the future, when today’s employees and executives write and publish their memoirs, it will contain a lot of discourse on the very serious consideration that took place within the company in the past to do so. You can quote me on this. And then laugh at me when it inevitable turns out I’m wrong.