When building web applications, developers typically choose between a decoupled architecture with modern frontend frameworks or a traditional monolithic approach using template engines like Twig or Blade. Inertia.js revolutionized Laravel development by enabling developers to maintain their server-side workflow while adopting modern frontend frameworks like Vue and React - without having to completely change their development approach.
Inertia.js has proven tremendously successful in the Laravel ecosystem, showing that developers appreciate the flexibility to gradually adopt modern frontend practices while leveraging their existing server-side expertise. Today, we are excited to bring the same powerful approach to the Drupal ecosystem.
Like Inertia.js, Lupus Decoupled Drupal lets you build modern web applications without sacrificing the benefits of server-side rendering. You maintain full control over routing and data flow on the server while delivering dynamic, interactive experiences through JavaScript components. At its core, Lupus Decoupled Drupal follows the same simple but powerful model - pages + components. Drupal defines pages and provides data - either via code or configuration - while JavaScript components handle the presentation and interactivity. This gives you the best of both worlds: server-side control with rich client-side interactions.
We are happy that as of today, Lupus Decoupled is officially considered complete and ready for production use. In fact, the building blocks of Lupus Decoupled are stable for a long time. They are already powering this site, as you can see by inspecting the API output of this post.
With version 1.0, Lupus Decoupled Drupal provides:
Beyond these core features, Lupus Decoupled Drupal maintains deep integration with Drupal, ensuring that Drupal's powerful tools work seamlessly with your modern frontend:
Similar to Inertia.js, the backend (Drupal) renders into a tree of high-level components (custom elements), making it easy for any frontend framework to render the output. By default, we provide a Nuxt-powered frontend that makes it simple to get started, thanks to its web-standard focused approach. Nuxt is a versatile and beginner-friendly framework supporting various rendering modes. Additionally, we offer a proof-of-concept React implementation with Next.js for those who prefer React. Other frontend frameworks, like Astro, can be easily added as well. If you are interested to work on that, get in touch!
We are currently working on adding better support for the Drupal CMS and leveraging recipes as part of the installation process, making it easy to pick your desired features. Next, we plan to integrate with the upcoming experience builder, enabling server-rendered modern experiences. When Drupal CMS and the experience builder empower the Drupal site-builder, Lupus Decoupled Drupal will be ready to connect it with a modern frontend development toolbox.
Now is the perfect time to get started: Try one of the Gitpod-powered web-based development environments and take your first steps. Join us in Drupal slack at #lupus-decoupled to share your feedback or get help!
The video above explores two different methods for creating engaging quizzes in Drupal CMS. Whether you want to test user knowledge or boost engagement, Drupal provides flexible solutions for quiz creation.
The guide below explains the Quiz module and Webform Quiz Elements, their key differences, and step-by-step instructions for implementing each option.
What are Drupal Quiz Solutions?
Drupal provides two primary methods for creating quizzes:
Every year we try to clarify goals early, and here we go for 2025! We'd love to have your thoughts and opinions! Some of the things we planned in 2024 aren't quite done yet, but we're working and planning and responding to your needs.
At the DDEV Advisory Group's 2-hour annual review/planning meeting on March 4, 2025, we'll talk about plans and priorities for 2025. You are invited!
We'd love to have your input as daily users as we work through these this month.
(I expect to edit this blog post several times as people express their opinions.)
ddev launch in Golang instead of as script.In addition to prioritizing these initiatives, we have applied to the Google Summer of Code, hoping that we can mentor contributors in that program and see work on one or more of these be successful through GSoC. We'll also be looking for community mentors (is that you?), and maybe some of you would like to sign up for being mentees via Google this summer!
Do you see other important things in the issue queue or elsewhere that are important to you? Are there frictions that impact your work that DDEV could fix? Please let us know.
We would dearly love to have your input on these as the planning process goes forward. You can respond so very many ways in all of the support venues.
Want to keep up as the month goes along? Follow us on
Happy February!
DDEV v1.24.2 was released with MySQL 8.4 support and improved ddev composer create making it nearly compatible with composer create-project.
DDEV Notes and News
ddev composer create, making it nearly compatible with composer create-project. Additionally, the ddev composer create-project alias has been added for improved usability.Ongoing DDEV Work
Funding DDEV and especially to help both maintainers go full-time on DDEV: We need your help and your organization's help! Let me know if you need help getting this into your 2025 budget! Our key financial goal is to fully fund @stasadev so he can work exclusively on DDEV. We've slipped back in recent months. We need about $3700/month in increased pledges from organizations and individuals. See Full information about supporting DDEV. We’re happy to invoice you, happy to do a call discussing this, and would love it if you’d include DDEV in your 2025 budgeting process. (Our current status: We receive about $3000/month, have been spending about $3000-$4000/month. Bank balance is about $6,000, down from $8,600 last month.)
THANKS to all of you who are supporting DDEV’s path to sustainability and who have gotten your organizations to do so.
Want to keep up as the month goes along? Follow on
Happy February from Randy Fay, DDEV Project Lead. It's a delight to collaborate with you!
Join us 11 - 13 March 2025 in Davos at Drupal Mountain Camp if you are interested in learning about Drupal CMS and how AI technology will shape the future of the open web.
Open Source on Top of the World
As a co-organizer I am particularly excited about the keynotes speakers of this year:
The program brings you a good variety of expertise, exchange opportunities and fun in the swiss mountains:
Liip is proud to participate in the program in various ways:
We expect more than 100 participants, with a good mix of folks from Switzerland and abroad.
Thanks to sponsors like agiledrop, amazee.io, varnish, Hostpoint, MD Systems, Happy Coding, soul.media, iqual, tag1, the 3 days conference is brought to you at a comparably low price, with tickets available for CHF 100 per ticket.
Celebrating the best Drupal projects in Switzerland
Nominees are just being selected and communicated for the Splash Awards Switzerland. The winning projects will be announced at the award ceremony Tuesday afternoon.
We are excited to be nominated with the following entries:
Drupal Mountain Camp wouldn’t be possible without a team of dedicated volunteers.
See you at drupalmountaincamp.ch.
jenna
Thu, 02/06/2025 - 14:23
Drupal
Drupal 11 is here! In part one of this two-part blog series, I walked through its new features that will benefit developers and content editors alike. Now that we know what we have to look forward to, let’s talk about how and when to upgrade to Drupal 11.
While every Drupal site is unique and has its own requirements and complexities, I’m going to explain the general steps of a Drupal upgrade. And even though an upgrade from Drupal 10 to 11 is relatively less effort than going from Drupal 6 to 7, you still need to plan it out.
If you have a site that has a lot of contributed modules, modules that aren't well supported, or complicated custom modules, both planning the upgrade and actually doing the upgrade will take longer.
The Upgrade Status module will help with this process. With it you can assess if your modules have D11 versions, identify changes needed in custom code, and make recommendations on what to do with modules that lack D11 support. This is also a really great time to look at the modules you're using and identify any that can be removed or replaced with something newer.
Then you'll have to perform the upgrades. I wrote upgrades in plural here because I think it works best as a set of at least two upgrades, maybe more in some cases.
The first upgrade is to ensure that the new platform requirements are satisfied. This could mean some extra work if you're responsible for maintaining your web servers. So make sure you are aware of those.
It works well to first update your modules and test to make sure everything is working as expected. Module changes are where regressions or errors are going to come up. Upgrading those to versions that are compatible with both D10 and 11 will give you plenty of time to test and isolate variables.
And then do a separate deployment to update Drupal core itself. This will depend heavily on the complexity of your code and operations, but I think it's reasonable to expect that the development timeline will be measured in hours to days.
If you have an e-commerce site where the risk and impact of downtime is high, or you have a super complicated custom codebase, it could take days, or even weeks. But if you have a very simple site, it could be done in an afternoon.
So here we are in early 2025. Drupal 10.4 is out and is in “maintenance support,” which means that select changes from Drupal 11 will be backported down, but at this point Drupal 11 has development priority. Around the end of 2025, Drupal 10 will enter a period where it only receives security updates, and it will reach end of life in mid-2026 when Drupal 12 is released.
Drupal 10 Life Cycle
When any given Drupal version reaches end of life, your site will continue to function. It's not like a license that expires and suddenly your site stops working, but there are no more bug fixes to your installed Drupal core, and most critically there are no more security updates. Contributed module maintainers have focused on newer versions, so they're not really getting regular updates.
All of this means that upgrading later takes more effort because there's more and more that has to be addressed as time goes on.
11.0 was released in summer of 2024, and Drupal 11 will be receiving active development support until around 2027, when it goes into maintenance support like I described earlier.
Drupal 11 Life Cycle
Putting this together and adding in the Drupal 12 cycle, I think the second half of 2025 is going to be the right time for most people to upgrade to Drupal 11 with some caveats.
For instance, if you have a simpler site and all of your contributed and custom modules are ready to run on Drupal 11, there's no harm in doing it sooner. But I think for most larger sites, it's best to let contributed modules catch up with Drupal 11 development, let some of the kinks get worked out in the community, and then upgrade.
Now that Drupal is on a more steady and predictable release schedule, we can start looking forward to new features in Drupal 12 in 2027.
Seth HillBálint “balintbrews” Kléri and Jesse Baker fixed a funny bug: the component inputs form was unscrollable, which meant that using Experience Builder (XB) in small viewports (or with complex components that have many inputs), you just couldn’t reach them 😅🙈
Dave “longwave” Long and I simplified the way XB represents Component config entity IDs, a small next step towards supporting multiple component types. It will now feel more familiar for anybody used to dealing with Drupal’s configuration.
Ted “tedbow” Bowman and Dave introduced basic auto-saving (much future work left to be done):
Basic auto-saving in XB: navigating away and back does not lose changes the author made.The Drupal Association started defaulting to version 1.6.3 of the GitLab CI template on October 15, as they announced in GitLab CI templates will make Drupal 11 the default version to run back in August. Cool! Except … any contrib module with more complex testing needs will have customized the CI, and that was now automatically broken too, because the 1.6.x CI template changed CI job names 😬
Yay for versioning, because Dave fixed this by simply pinning XB’s CI template to extend the 1.5.x one instead.
Some minor bug fixes by Atul “soaratul” Dubey and Travis Carden also landed.
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!
This week’s big leap forward was led by yours truly 1 (and reviewed by Dave) to pave the path towards XB product requirement 19. Modify the page template (i.e. global sections), which Lauri “lauriiii” Timmanee captured as:
As a builder, I want to modify the page template (i.e.
page.html.twig). When I modify the page template, I can place components globally to global regions like navigation, header, footer, etc.
In other words: the ability to not use Drupal core’s existing “Block Layout” (/admin/structure/block) functionality, but to instead use XB to achieve the same.
That will mean not using Drupal’s default page variant (BlockPageVariant), but an XB-provided one.
Fun fact: I helped a decade ago to finalize exactly this infrastructure ahead of Drupal 8’s release, created the official Drupal 8 render pipeline diagram, and talked about it! The part XB will be using for this functionality is RenderEvents::SELECT_PAGE_DISPLAY_VARIANT 🤓
XB needs to know what component tree to show in each theme region, so those need to be stored somewhere. For that, I introduced the PageTemplate config entity, which:
null if it’s empty)MainContentBlockPluginInterface — to display the result of the matched route’s controllerTitleBlockPluginInterface — to display the title returned by that same controllerMessagesBlockPluginInterface one — to display messagesPageTemplateDisplayVariant to render the stored component trees.It leaps ahead of where the rest of the XB codebase is at, because it assumes there’ll be Block-sourced components, whereas currently XB only supports SDC-sourced components! And that’s where the path that we paved last week (and improved this week) already is being trodden! 🥳
That’s how I was able to write a test that proves in <100 LoC that XB’s page variant works as expected, despite a lot of other infrastructure not yet existing. Hence I was confident that the rest of the team could build all the necessary UI pieces and blocks-as-components infrastructure while I’d be out! 😊
Week 23 was October 14–October 20, 2024.
I was trying to get ahead of the rest of the team in anticipation of my upcoming paternity leave, little did I know it’d already be next week 😅
Full detail in the config schema if you’re interested!
Authored by Nadiia Nykolaichuk.
I was asked via a private message on LinkedIn: What word of advice would you give to help me build a successful agency ?