Today we are talking about Drupal Forge, how it works, and why it’s changing Drupal with guest Darren Oh. We’ll also cover ECA VBO as our module of the week.
For show notes visit: https://www.talkingDrupal.com/497
TopicsDarren Oh - drupalforge.org Darren Oh
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Kathy Beck - kbeck303
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
Seven years ago, I wrote a post about a tiny experiment: publishing my phone's battery status to my website. The updates have quietly kept coming ever since, showing up at https://dri.es/status.
Every 20 minutes or so, my phone sends its battery level and charging state to a REST endpoint on my Drupal site. Timing depends on iOS background scheduling, which has a mind of its own.
For years, this lived quietly at https://dri.es/status. I never linked to it outside the original blog post, so it felt like a forgotten corner of my site. Still working, but mostly invisible.
Even after seven years, people still mention it from time to time. So I decided to bring it out of hiding.
I added a battery icon to my site's header. It's a dynamically generated SVG that reflects my phone's battery level and charging state.
It's a little goofy. But that's the fun of having a personal website–you get to make it yours.
I've always been drawn to working with images, and when responsive images came onto the scene, I dove deep into learning everything I could about them.
I've written extensively about Responsive images if you need a refresher, but today, let's focus on modern image formats. In particular, WebP.
WebP is a modern image format developed by Google that provides superior compression and quality compared to traditional formats like JPEG and PNG. It supports both lossy and lossless compression, transparency, and animation, making it a versatile choice for web images. WebP helps improve website performance by reducing file sizes, which leads to faster loading times and better user experience.
Since 2020, all major browsers support WebP. (Check caniuse for details). My site, this site, uses WebP exclusively for most images and although it is not a big site, I still see performance improvements.
You would think that a big upgrade like this would be a complex task but you'll be surprised to learn that enabling WebP for new and existing images in Drupal is straightforward. Let's quickly go over the steps.
Edit each of your image styles and add the Convert effect.
Fig. 1: Selecting the Convert effect for an image style.
Select and add the WebP format to the image style.
Fig. 2: Adding the WebP format to an image style.
That's it!
Fun fact!: WebP support was introduced to Drupal core in Drupal 9.2.0, which was released on June 16, 2021. Before this core integration, WebP support in Drupal was only available through contributed modules or custom code. The inclusion in core made the format's benefits available to all Drupal 9.2+ sites without requiring additional modules.
I did a quick and simple test to show the difference in file size when adding a typical JPEG image to an article, then converting it to WebP using the steps above. The test was done in Drupal 10.x.
Using a JPEG image on an article node, shows a file size of 289kb.
Fig. 3: Example shows using a JPEG format.
After converting the imag eto Webp by updating the image style of that image, the file size was reduced to 76kb. That's about 60% file size reduction.
Fig. 3: Example shows using a WebP format.
NOTE: This was a pretty basic comparison test. File size reduction will vary depending on original file zize, format, and other preferences on your site.
The Avif image format is also a great option with many benefits. The browser support is really good at the time of this post (See caniuse), and it's worth looking into it as an alternative to WebP, or even combining the two depending on your media needs.
It's all about the small wins. This one is pretty simple but can provide significant performance benefits. Give it a try!
Craig asks,
Ask Freelock
Read More The European Accessibility Act (EAA) introduces new EU-wide rules to ensure digital products and services are accessible to everyone, including people with disabilities. By June 28, 2025, all businesses and organizations that offer digital…
Read moreTL;DR: DDEV was a huge force multiplier, enabling me to focus on writing a WordPress plugin to export WordPress content for use in Grav CMS. More information on the plugin can be found at the GitHub repository wp2grav_exporter.
Popular content managment systems like WordPress and Drupal store content in databases (MySQL/ PostgreSQL/ etc.). Grav CMS stores content and configuration in local files (Markdown and YAML respectively). Grav's simpler flat-file storage mechanism is one of the things that drew me to start dabbling with it.
While the recent shenanigans from Automattic's CEO accelerated my work, it wasn't the primary reason I developed this content exporter. I fell in love with Grav development back in 2018 when I first started writing a Drupal 7 exporter, and I wanted to port something similar over to WordPress. I value data portability, empowering the end user to control where their content is used! In the end, it's about giving options.
DDEV is a fantastic tool, and it is perfect for my PHP development workflow. It made spinning up two local developlment sites a breeze. I normally relish building and configuring my own automated environments, but DDEV makes it so simple to configure local environments. Additionally, DDEV comes with many "quickstart" configurations, meaning that popular CMS's like Drupal and WordPress work out of the box with nearly all settings ready to go.
I made two different directories, one for WordPress and the other for Grav. After running ddev config on each respective directory, ddev start on each starts serving the content.
I installed DemoPress in the WordPress environment to help generate random test content and users to export.
Step debugging is imperative while trying to inspect content in-flight. Xdebug needed to listen on two different ports to avoid collisions between the two sites, and the DDEV docs are informative on how to configure this. I personally use VSCode, but other IDE's should work just as well, too. Step debugging was crucial to finding appropriate data structures and information I needed my converter plugin to use in a Grav site.
The wp2grav_exporter plugin is the resultant labor of love. It automatically exports:
Additional screenshots of example content exports can be found at the plugin's GitHub page.
After running the export, content was drag-dropped between my two DDEV directories, and I could immediately test how content looked. The exported post configurations are encompassed in a Grav plugin, so the end user is free to use whatever theme they want!
DDEV has saved me countless hours with its easy setup and dependability. If you haven't yet taken it for a test spin, I can't recommend it enough!
Find an issue with my exporter? Submissions are welcome at the project's issue queue!
Drupal is more than just a content management system; it’s a gateway to innovation, creativity, and endless possibilities. Before stepping into the Drupal world, I saw CMS platforms as rigid structures with predefined functionalities. But Drupal? It completely changed my perception. It’s not just a tool, it’s a playground for developers, where ideas come to life, solutions evolve, and digital experiences are redefined.
As I began my journey with Drupal, I quickly realised that it’s more than just a platform, it's an ecosystem. From its modular architecture to a thriving open-source community, Drupal offers something for everyone, whether you’re a beginner like I was or an experienced developer looking to push boundaries. The more I explored, the more I realised that Drupal isn’t just about building websites, it's about creating dynamic, scalable, and future-proof digital experiences.