Planet Drupal
CKEditor: DrupalCon 2024 - A chat with Simon Morvan
The Drop Times: A Name of Purpose and Clarity
Consensus Enterprises: Starshot: Moving Drupal Towards a Product Platform
mandclu: What’s Cooking with the Events Recipe for Drupal CMS
When I first heard the vision for Starshot (now Drupal CMS), I knew exactly how I wanted to contribute. For years I have been working on trying to make it easier to quickly build Drupal sites following established best practices. I had been working on a set of modules I called Configuration Kits, but they were conceptually very similar to Recipes, albeit in a simpler (and less flexible) form.
mandclu Aug 19, 2024 - 8:48am Tags#! code: Drupal 10: An Introduction To Batch Processing With The Batch API
The Batch API is a powerful feature in Drupal that allows complex or time consuming tasks to be split into smaller parts.
For example, let's say you wanted to run a function that would go through every page on you Drupal site and perform an action. This might be removing specific authors from pages, or removing links in text, or deleting certain taxonomy terms. You might create a small loop that just loads all pages and performs the action on those pages.
This is normally fine on sites that have a small number of pages (i.e. less than 100). But what happens when the site has 10,000 pages, or a million? Your little loop will soon hit the limits of PHP execution times or memory limits and cause the script to be terminated. How do you know how far your loop progressed through the data? What happens if you tried to restart the loop?
The Batch API in Drupal solves these problems by splitting this task into parts so that rather than run a single process to change all the pages at the same time. When the batch runs a series of smaller tasks (eg. just 50 pages at a time) are progressed until the task is complete. This means that you don't hit the memory or timeout limits of PHP and the task finishes successfully and in a predictable way. Rather than run the operation in a single page request the Batch API allows the operation to be run through lots of little page request, each of which nibbles away at the task until it is complete.
This technique can be used any a variety of different situations. Many contributed modules in Drupal make use of this feature to prevent processes taking too long.
Mario Hernandez: SOLVED - Cannot crop based on original image after initial crop has been set
If you have read my posts about responsive images you will know I have done quite a bit of work with Drupal media and in particular, images. However, I recently ran into an issue I had not experienced before and it was quite challenging to comprehend. The issue was related to image cropping.
In our Drupal platform we allow content editors to manually crop images using a hand-full of crop types for various aspect ratios such as 1:1, 3:4, 4:3, 16:9, etc. To achieve the manual crop we use the Crop API and Image Widget Crop Drupal modules.
The issue we started noticing is that no matter the image we were using, all cropping settings were limited to a predefined aspect ratio of 1:1 or square, rather than the original image's aspect ratio. This was causing big problems for us because editors were not able to properly crop images and as a result images were rendered with odd cropping settings.
After some research, I found an issue that had been reported in the Image Widget Crop module, issue #3222406. This was exactly the issue we were having and was relieved it wasn't something unique to our platform.
Cause of the issueLooking back, I think this issue was partly of my own making, but seeing that others were experiencing the same it's also possible it was just an odd bug. Long story short, the issue was caused by using an image style with specific hard dimension, as the crop preview image, See Fig. 1 below.
Fig. 1: Screenshot of Crop preview configuration.
You may not know this but you can change image styles for almost any image within Drupal's admin. I recently completed a lot of work around image styles within our platform and perhaps I unknowingly changed the image style used by Drupal's crop preview. I can't say for sure.
SolutionThe issue was not so much the aspect ratio used in the image style used as the crop preview, but rather the hard dimensions of the image style. These dimensions were forcing all images, regardless of their aspect ratio, to use the square aspect ratio as the starting point for cropping, rather than the original image.
The solution is to use an image style that uses the Scale image effect, as the crop preview. The Scale image effect does not require image dimensions and thus allows your cropping area to always reset to the original image.
If you read comment #5 in the issue page you will see juamerico explanation of the issue in more detail and what he did to fix it.
Steps taken to address the issue- I created a new image style called Crop preview with the Scale image effect as well as using a wide aspect ratio or crop type such as 16:9.
- I configured the Manage form display for the Image media type (admin/structure/media/manage/image/form-display), so it uses the new image style I just created. See Fig. 2 below
Fig. 2: Screenshot of Manage form display settings for images.
NOTE: Your environment may be configured differently than mine and you may not have the same options as I do.With the changes to the Crop preview image style, every time you crop the image you are dealing with the original image rather than an already cropped image.
In closingThe main reason for writing about this topic is so I know what to do next time I run into this issue. I hope you find this helpful.
Mario Hernandez: Migrating from Patternlab to Storybook
Building a custom Drupal theme nowadays is a more complex process than it used to be. Most themes require some kind of build tool such as Gulp, Grunt, Webpack or others to automate many of the repeatitive tasks we perform when working on the front-end. Tasks like compiling and minifying code, compressing images, linting code, and many more. As Atomic Web Design became a thing, things got more complicated because now if you are building components you need a styleguide or Design System to showcase and maintain those components. One of those design systems for me has been Patternlab. I started using Patternlab in all my Drupal projects almost ten years ago with great success. In addition, Patternlab has been the design system of choice at my place of work but one of my immediate tasks was to work on migrating to a different design system. We have a small team but were very excited about the challenge of finding and using a more modern and robust design system for our large multi-site Drupal environment.
Enter StorybookAfter looking a various options for a design system, Storybook seemed to be the right choice for us for a couple of reasons: one, it has been around for about 10 years and during this time it has matured significantly, and two, it has become a very popular option in the Drupal ecosystem. In some ways, Storybook follows the same model as Drupal, it has a pretty active community and a very healthy ecosystem of plugins to extend its core functionality.
Storybook looks very promising as a design system for Drupal projects and with the recent release of Single Directory Components or SDC, and the new Storybook module, we think things can only get better for Drupal front-end development. Unfortunately for us, technical limitations in combination with our specific requirements, prevented us from using SDC or the Storybook module. Instead, we built our environment from scratch with a stand-alone integration of Storybook 8.
INFO: At the time of our implementation, TwigJS did not have the capability to resolve SDC's namespace. It appears this has been addressed and using SDC should now be possible with this custom setup. I haven't personally tried it and therefore I can't confirm. Our process and requirementsIn choosing Storybook, we went through a rigorous research and testing process to ensure it will not only solve our immediate problems with our current environment, but it will be around as a long term solution. As part of this process, we also tested several available options like Emulsify and Gesso which would be great options for anyone looking for a ready-to-go system out of the box. Some of our requirements included:
1. No components refactoringThe first and non-negotiable requirement was to be able to migrate components from Patternlab to a new design system with the least amount of refactoring as possible. We have a decent amount of components which have been built within the last year and the last thing we wanted was to have to rebuild them again because we are switching design system.
2. A new Front-end build workflowI personally have been faithful to Gulp as a front-end build tool for as long as I can remember because it did everything I needed done in a very efficient manner. The Drupal project we maintain also used Gulp, but as part of this migration, we wanted to see what other options were out there that could improve our workflow. The obvious choice seemed to be Webpack, but as we looked closer into this we learned about ViteJS, "The Next Genration Frontend Tooling". Vite delivers on its promise of being "blazing fast", and its ecosystem is great and growing, so we went with it.
3. No more Sass in favor of PostCSSCSS has drastically improved in recent years. It is now possible with plain CSS, to do many of the things you used to be able to only do with Sass or similar CSS Preprocessor. Eliminating Sass from our workflow meant we would also be able to get rid of many other node dependencies related to Sass. The goal for this project was to use plain CSS in combination with PostCSS and one bonus of using Vite is that Vite offers PostCSS processing out of the box without additional plugins or dependencies. Ofcourse if you want to do more advance PostCSS processing you will probably need some external dependencies.
Building a new Drupal theme with StorybookLet's go over the steps to building the base of your new Drupal theme with ViteJS and Storybook. This will be at a high-level to callout only the most important and Drupal-related parts. This process will create a brand new theme. If you already have a theme you would like to use, make the appropriate changes to the instructions.
1. Setup Storybook with ViteJS ViteJS- In your Drupal project, navigate to the theme's directory (i.e. /web/themes/custom/)
- Run the following command:
- When prompted, select the framework of your choice, for us the framework is React.
- When prompted, select the variant for your project, for us this is JavaScript
After the setup finishes you will have a basic Vite project running.
Storybook- Be sure your system is running NodeJS version 18 or higher
- Inside the newly created theme, run this command:
- After installation completes, you will have a new Storybook instance running
- If Storybook didn't start on its own, start it by running:
Twig templates are server-side templates which are normally rendered with TwigPHP to HTML by Drupal, but Storybook is a JS tool. TwigJS is the JS-equivalent of TwigPHP so that Storybook understands Twig. Let's install all dependencies needed for Storybook to work with Twig.
- If Storybook is still running, press Ctrl + C to stop it
- Then run the following command:
- vite-plugin-twig-drupal: If you are using Vite like we are, this is a Vite plugin that handles transforming twig files into a Javascript function that can be used with Storybook. This plugin includes the following:
- Twig or TwigJS: This is the JavaScript implementation of the Twig PHP templating language. This allows Storybook to understand Twig.
Note: TwigJS may not always be in sync with the version of Twig PHP in Drupal and you may run into issues when using certain Twig functions or filters, however, we are adding other extensions that may help with the incompatability issues. - drupal attribute: Adds the ability to work with Drupal attributes.
- Twig or TwigJS: This is the JavaScript implementation of the Twig PHP templating language. This allows Storybook to understand Twig.
- twig-drupal-filters: TwigJS implementation of Twig functions and filters.
- html-react-parser: This extension is key for Storybook to parse HTML code into react elements.
- @modifi/vite-plugin-yaml: Transforms a YAML file into a JS object. This is useful for passing the component's data to React as args.
Update your vite.config.js so it makes use of the new extensions we just installed as well as configuring the namesapces for our components.
import { defineConfig } from "vite" import yml from '@modyfi/vite-plugin-yaml'; import twig from 'vite-plugin-twig-drupal'; import { join } from "node:path" export default defineConfig({ plugins: [ twig({ namespaces: { components: join(__dirname, "./src/components"), // Other namespaces maybe be added. }, }), // Allows Storybook to read data from YAML files. yml(), ], }) Storybook configurationOut of the box, Storybook comes with main.js and preview.js inside the .storybook directory. These two files is where a lot of Storybook's configuration is done. We are going to define the location of our components, same location as we did in vite.config.js above (we'll create this directory shortly). We are also going to do a quick config inside preview.js for handling drupal filters.
- Inside .storybook/main.js file, update the stories array as follows:
- Inside .storybook/preview.js, update it as follows:
- If Storybook is still running, press Ctrl + C to stop it
- Inside the src directory, create the components directory. Alternatively, you could rename the existing stories directory to components.
With the current system in place we can start building components. We'll start with a very simple component to try things out first.
- Inside src/components, create a new directory called title
- Inside the title directory, create the following files: title.yml and title.twig
- Inside title.yml, add the following:
- Inside title.twig, add the following:
We have a simple title component that will print a title of anything you want. The level key allows us to change the heading level of the title (i.e. h1, h2, h3, etc.), and the modifier key allows us to pass a modifier class to the component, and the url will be helpful when our title needs to be a link to another page or component.
Currently the title component is not available in storybook. Storybook uses a special file to display each component as a story, the file name is component-name.stories.jsx.
- Inside title create a file called title.stories.jsx
- Inside the stories file, add the following:
- If Storybook is running you should see the title story. See example below:
- Otherwise start Storybook by running:
With Storybook running, the title component should look like the image below:
The controls highlighted at the bottom of the title allow you to change the values of each of the fields for the title.
I wanted to start with the simplest of components, the title, to show how Storybook, with help from the extensions we installed, understands Twig. The good news is that the same approach we took with the title component works on even more complex components. Even the React code we wrote does not change much on large components.
In the next blog post, we will build more components that nest smaller components, and we will also add Drupal related parts and configuration to our theme so we can begin using the theme in a Drupal site. Finally, we will integrate the components we built in Storybook with Drupal so our content can be rendered using the component we're building. Stay tuned. For now, if you want to grab a copy of all the code in this post, you can do so below.
Resources In closingGetting to this point was a team effort and I'd like to thank Chaz Chumley, a Senior Software Engineer, who did a lot of the configuration discussed in this post. In addition, I am thankful to the Emulsify and Gesso teams for letting us pick their brains during our research. Their help was critical in this process.
I hope this was helpful and if there is anything I can help you with in your journey of a Storybook-friendly Drupal theme, feel free to reach out.
mark.ie: My LocalGov Drupal contributions for week-ending August 16th, 2024
Here's what I've been working on for my LocalGov Drupal contributions this week. Thanks to Big Blue Door for sponsoring the time to work on these.
Dries Buytaert: Drupal CMS: the official name for Drupal Starshot
We're excited to announce that "Drupal CMS" will be the official name for the product developed by the Drupal Starshot Initiative.
The name "Drupal CMS" was chosen after user testing with both newcomers and experienced users. This name consistently scored highest across all tested groups, including marketers unfamiliar with Drupal.
Participants appreciated the clarity it brings:
Having the words CMS in the name will make it clear what the product is. People would know that Drupal was a content management system by the nature of its name, rather than having to ask what Drupal is. I'm a designer familiar with the industry, so the term CMS or content management system is the term or phrase that describes this product most accurately in my opinion. I think it is important to have CMS in the title.The name "Drupal Starshot" will remain an internal code name until the first release of Drupal CMS, after which it will most likely be retired.
Dries Buytaert: Evolving Drupal's Layout Builder to an Experience Builder
Imagine a world where installing Drupal instantly offers a creative experience that allows you to build and style pages right out of the box, without any need for additional modules or configuration.
The introduction of Drupal's Layout Builder in 2018 was an important milestone toward this vision, but it was just the first step. Layout Builder provides site builders with a powerful drag-and-drop interface for creating and arranging content within customizable layouts.
Despite its success, there is a clear and pressing need to improve the existing Layout Builder. The numerous community-developed modules enhancing Layout Builder highlight the need for a more comprehensive solution.
That is why at DrupalCon Lille last year, I was excited to announce the "Next Generation Page Builder" initiative, aimed at improving and expanding the Layout Builder to provide a truly intuitive, out-of-the-box page-building experience.
Since announcing the 'Next Generation Page Builder', led by Lauri Eskola (Acquia), a Drupal Core Committer, we've done extensive research and planning.
Inspired by user feedback, we decided to make two changes. First, we decided to broaden our focus: not only will we improve the page-building features of Layout Builder, we will also integrate basic theming capabilities, enabling users to style their pages effortlessly without having to edit Twig files. Second, reflecting on this wider scope, we renamed the initiative from 'Next Generation Page Builder' to 'Experience Builder'.
In recent months, we explored several options for how to create such an Experience Builder, including accelerating development of the Layout Builder, switching to Gutenberg, adopting Paragraphs, or using the newly open-sourced Plasmic.
After thorough analysis and discussions with key stakeholders, including Automattic's Gutenberg team, the Drupal Core Committers decided the best approach is to expand the Layout Builder while also incorporating the best elements of Paragraphs.
Looking to the future, I hope the Experience Builder becomes the preferred Drupal tool for layout design, page building, and basic theming. Our main goal is to create a tool that site builders love, with an amazing out-of-the-box experience. By integrating key features from Paragraphs, we also aim to create a unified solution that reduces fragmentation, accelerates innovation, and ensures Drupal remains at the forefront of site building.
Our future success hinges on expanding Drupal's usability to a wider audience. Our CMS capabilities are often better than our competitors', but aren't always as user friendly. In the Drupal 7 era, Drupal was the OG (Original Great) of low-code but today we are being outpaced by competitors in terms of ease of use. Without user experience improvements, we'll lose ground. The Experience Builder initiative is all about introducing more people to the power of Drupal.
I feel strongly that a unified Experience Builder is one of the most important initiatives we can undertake right now.
Developing an Experience Builder is a big task that will require substantial effort, extensive collaboration, and significant expertise in user experience and design. As Drupal Core Committers, we are driven by a sense of urgency to advance this initiative. We are committed to moving quickly and iterating rapidly, but to succeed, we also need your support. There will be many opportunities for the community to collaborate and contribute to this initiative.
For more information, please check Lauri's latest blog post on the topic. Additionally, I will discuss this further in my upcoming DrupalCon Portland keynote in a few weeks.
mark.ie: My Drupal Core Contributions for week-ending August 16th, 2024
Here's what I've been working on for my Drupal contributions this week. Thanks to Code Enigma for sponsoring the time to work on these.
The Drop is Always Moving: Let's meet at Drupal Starshot Initiative sessions at DrupalCon Barcelona! Check out this rundown of what you can look forward to at the event and buy your ticket before the regular prices end midnight on Monday August 19...
Let's meet at Drupal Starshot Initiative sessions at DrupalCon Barcelona! Check out this rundown of what you can look forward to at the event and buy your ticket before the regular prices end midnight on Monday August 19!
Drupal Starshot blog: Let's meet at Drupal Starshot Initiative sessions at DrupalCon Barcelona
The ambitious Drupal Starshot Initiative aims to build the new default download of Drupal, called Drupal CMS. Dries Buytaert announced it at DrupalCon Portland 2024. DrupalCon Barcelona provides a midway checkpoint in how far the teams got with the goals and the program will be packed with opportunities to get information and join the initiative.
Dries will provide an overall update in his Driesnote on Tuesday. This is a must see session! But the event will provide ample opportunities to get to know how each component is going. The following sessions are highly suggested.
A cornerstone of the experience is UI based installation of functionality. This is powered by the Recipes feature, which supports packages of functionality and configuration. Martin Anderson-Clutz and Mark Casias will present the Drupal Recipes Initiative Update. Recipes and other functionality are installed with Project Browser. Get insights into progress on that at Project Browser: making Starshot's in-browser feature composition a reality with Chris Wells and Leslie Glynn.
Automatic software installs and updates could be dangerous if the sources are not validated properly. Composer creator Nils Adermann teams up with Tim Lehnen and Christopher Gervais to explain solutions to this problem that will make Drupal project installation secure in Supply Chain Security in Drupal and Composer.
Drupal CMS will ship with Gin as the default administration team. Sascha Eggenberger will update us in Gin Admin Theme - Road to stable. But there is a lot more to figure out about the admin UI. Jen Witkowski and Stephanie Ganzer will provide insight into The Admin UI Redesign Process so we can see what more is to come.
In some cases, involving targeted AI solutions results in much faster user benefits compared to redesigning user interfaces. James Abrahams and Marcus Johansson will showcase AI innovation in Using Drupal’s AI module to power your Drupal websites and potential plans for Starshot.
Much anticipated and also much newer is the Experience Builder Initiative which aims to provide a modern experience building tool for Drupal and is planned to eventually ship with Drupal CMS as well. Lauri Eskola will update us on progress and future goals.
In Building the future of Drupal: 11, 12 and Starshot Gábor Hojtsy and Tim Plunkett will show how the different software packages are connected and build on top of each other, providing a closer look at the technologies used and processes followed.
It is not enough to make the software easier to build with, we also aim to make it easier to try. Drupal.org will have an in-browser trial experience to make Drupal easier to explore. Matt Glaman will provide a peek at the technology powering this in The Web APIs powering the Starshot trial experience.
Functionality to be built for Drupal CMS are divided in Starshot Initiative Tracks that are exploring options and building recipes to provide key features to users. The Drupal Initiative Leads keynote will explore how these tracks approached their areas, the research they did and the results they came up with.
These were only the sessions, there will be even more discussions (BoFs) and working groups (in the contribution room) that you can join. It is not too late to buy your DrupalCon Barcelona ticket, the regular ticket pricing ends at the end of August 19th. Buy your ticket now and see you there!
The Drop Times: Bold Changes to Propel Drupal Forward: Will Huggins
LN Webworks: How to set up WordPress with docker?
Docker is an open-source software that helps us to run the container or which provides us with a containerized platform. In simple, Docker is very famous and widely used.
WordPressWordPress is an open-source content management system (CMS) that makes it easy to create and manage a website. It is the most popular CMS in the world. Millions of business owners, bloggers, and publishers use WordPress daily to maintain their online presence.
joshics.in: Choosing Between Drupal Core and Drupal CMS: A Comprehensive Guide
With the recent rebranding of Drupal Starshot to 'Drupal CMS', there has been some confusion surrounding the distinctions between Drupal CMS and Drupal Core. Both play critical roles in the Drupal ecosystem, yet they cater to different needs and use cases. In this blog post, we will explore the nuances of each, providing you with detailed insights and specific use cases to help you determine the best fit for your project.
What is Drupal Core?Drupal Core is the foundation of the Drupal content management framework. It includes essential functionalities such as user management, content authoring, and taxonomy, without any additional modules or themes. Essentially, Drupal Core is ideal for developers who prefer a minimalist approach, allowing them to build a website from the ground up, adding only the functionalities that are necessary for their specific needs.
Key Features of Drupal Core:
- Minimalist Framework: Provides a lean starting point without extra bloat.
- High Customisability: Allows developers to build custom features without pre-configured settings.
- Essential Functionalities: User management, content authoring, and taxonomy.
- Security: Regular updates and robust security measures.
Use Cases for Drupal Core:
- Custom Web Applications: Ideal for projects requiring unique functionalities.
- High Traffic Websites: Optimal for performance tuning and scalability.
- Complex Integrations: Suitable for environments requiring extensive custom integrations.
Drupal CMS (formerly known as Drupal Starshot) is a more user-friendly, ready-to-use version of Drupal tailored for those who want a feature-rich website out of the box. It includes a carefully curated set of modules, themes, and configurations to streamline the development process. Essentially, Drupal CMS is designed to offer immediate functionality with minimal setup, making it an excellent choice for less technically inclined users or for those who need to rapidly deploy a website.
Key Features of Drupal CMS:- Pre-configured Modules: Comes with essential modules for various functionalities like SEO, security, and performance.
- User-friendly: Simplifies the development process with pre-set configurations.
- Theming Options: Wide range of professional themes to choose from.
- Community Support: Extensive documentation and community support.
- Small to Medium Businesses: Perfect for businesses needing a robust online presence without extensive custom development.
- Non-technical Users: Ideal for users who want to set up and manage their site with minimal technical know-how.
- Rapid Deployment: Excellent for projects requiring quick turnaround times, such as event websites or campaign microsites.
- Content-driven Websites: Great for blogs, news portals, and other content-heavy sites where pre-configured SEO and performance optimisations are beneficial.
Deciding between Drupal Core and Drupal CMS hinges on your project requirements and technical expertise. If you're looking for a fully customisable solution and have the development resources, Drupal Core offers unparalleled flexibility. On the other hand, if you need a comprehensive and user-friendly solution that allows you to hit the ground running, Drupal CMS is the way to go.
Both are exceptional in their own right and serve distinct purposes within the Drupal ecosystem. By understanding their individual strengths and applications, you can make an informed decision that aligns with your project goals.
Drupal Drupal CMS Drupal core Drupal PlanetPromet Source: Drupal GovCon: Transforming Federal Digital Experiences
Bounteous.com: The Future of Experimentation: Acquia Convert
Bounteous.com: Discover the Power of Drupal for Enhanced Operational Efficiency and Security for Healthcare Systems
Bounteous.com: A New Age of Drupal: Drupal CMS
Pages
Recent Publications
- Managing Hidden Dependencies in OO Software: a Study Based on Open Source Projects
- Open Source Communities as Liminal Ecosystems
- Investigating developers' email discussions during decision-making in Python language evolution
- Developers, Quality Control and Download Volume in Open Source Software (OSS) Projects
More...FLOSS Project Planets
FLOSS Research
- Give Your Input on the State of Open Source Survey
- Open Data and Open Source AI: Charting a course to get more of both
- The Open Source Initiative and the Eclipse Foundation to Collaborate on Shaping Open Source AI (OSAI) Public Policy
- ClearlyDefined v2.0 adds support for LicenseRefs
- ClearlyDefined at SOSS Fusion 2024: a collaborative solution to Open Source license compliance