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.
a second official version of Drupal
- Dries Buytaert, in his blog post announcing Drupal Starshot
If you're a Drupal developer of any caliber and pay any attention to the goings-on in the Drupal community, then you no doubt have heard about Starshot, recently announced by Dries Buytaert at DrupalCon Portland 2024.
In this post, I'll do my best to not repeat everything that was announced, but rather to summarize, ask a question or two and offer an opinion or two…
Starshot will be a new download available on drupal.org that includes contributed modules and configuration to provide a superior out-of-the-box solution that is more usable/approachable/friendlier than Drupal core.
In my opinion, Starshot can be thought of (generally speaking of course) as two-ish large tasks. First, full integration with Automatic Updates, Project Browser and Recipes (including full Recipe support in Project Browser.) Second; Experience Builder, which is planned to be (roughly speaking) some combination of Layout Builder (or a replacement,) Paragraphs, Single Directory Components, an in-browser styling tool and other modules/configuration to provide a best-of-breed page-building solution.
The -ish in two-ish from above is all the additional functionality that having full Recipes support will bring. IMHO, this is the star in Starshot.
Note: Experience Builder is not new - it is an evolution of Next generation page builder initiative that started in 2023.
In his keynote, Dries spoke about the need for Starshot over the course of a few minutes, enumerating various reasons why he and others in the community feel this is a necessary task, including the fact that Drupal's UI is difficult to use for new users.
I think Mike Herchel summed the Why up nicely in his blog post:
It’s an acknowledgement of the perception that Drupal is archaic and/or legacy software, and that this perception needs to change.
Starshot is the Drupal community's effort to win back small- and medium-sized sites that don't currently even consider using Drupal.
Furthermore, one of the main goals of Drupal Starshot is to allow for faster innovation cycles, allowing Starshot to add functionality at a faster pace than Drupal core.
There's a countdown clock to liftoff on drupal.org/starshot that is currently at a bit over 200 days. Based on this, Starshot will be ready by January 1, 2025. Dries mentioned in his keynote that the goal was to have an initial release by the end of 2024.
There's actually a very early prototype of a subset of the functionality available from phenaproxima (Adam G-H.)
I'm a bit dubious about all of the mentioned functionality of Starshot being ready by the end of the year. More of my opinion on this in a bit…
It's not a fork - that much is clear. It will include Drupal core, but have its own release schedule. I can only imagine that any time Drupal core has a security update, there will be a new Starshot release (as well as any time any of the contrib modules used in Starshot have a security release as well, I assume)
One of my biggest questions after Dries' keynote was based on a mockup of a drupal.org page that he presented.
What happens when someone clicks "Launch?" I've been a proponent of the Drupal Association engaging/partnering with low-cost hosting providers to provide a way to easily provide hosting for a Drupal site that supports relies on Automatic Updates and Project Browser. The community has invested a lot of time in both of these initiatives, and I feel that neither really has a hosting "home." What would be a better way to officially launch these projects than hosting partners that fully support both, as well as a meaningful site backup plan, all included in a low monthly hosting price. IMHO, this type of thing should definitely be one of the options behind the mysterious "Launch" button. Maybe the DA gets a small referral fee from the hosting providers as well?
Gábor Hojtsy writes in his blog post about Starshot, "Discussions around making simple hosting available for simpler sites was reignited and a WebAssembly-based browser-executed demo solution's feasibility is also explored again." He also mentioned the potential for a WebAssembly-based option in his DrupalCon Portland 2024 session about Drupal 11, as well as options for ephemeral (temporary) hosting solutions (think SimplyTest.me.)
Absolutely. Dries and other folks already involved in Starshot admit that there's a lot of things to still figure out, decisions to be made and a lot of work to do to make all this a reality. Nothing is set in stone.
As exciting as Experience Builder sounds, I'm worried that this is going to take a long time. In addition, as we've seen with the plethora of Layout Builder related contrib modules, there is often no one-size-fits-all solution for page creation.
From my perspective, I think that Drupal Starshot (or Drupal CMS, or whatever we end up calling it) phase 1 should be Automatic Updates, Project Browser, Recipes, and a set of curated recipes available geared towards page building. Experience Builder should be phase 2.
Being able to install recipes from Project Browser (leveraging Package Manager from Automatic Updates) will be a game-changer.
The way I look at it is with full Recipes support, we don't have to have just one Experience Builder, we can have many. We can have simpler ones (sooner) and more intricate ones (later.) We can have recipes that leverage Layout Builder and any number of the currently existing supporting contrib modules or recipes that focus on Paragraphs. The cream will rise to the top as the various Experience Builder modules are written, tested, and released.
Simon Hobbs agrees that Recipes is the "secret sauce" to Starshot in his optimistic blog post.
In the two-ish weeks since Dries announced Starshot, Drupal agencies from around the world have weighed in with their support, including PreviousNext from Australia (blog post by Kim Pepper,) 1xINTERNET from Europe (announcement,) Specbee (blog post by Malabya Tewari,) and (obviously) Acquia (United States.)
In my conversations with folks while at DrupalCon Portland 2024, reactions were mostly positive, but some folks had some concerns; with the leading issue being that (paraphrasing) the announcement feels like there were some internal (non-public) discussions about doing Starshot following by a "we are doing this" announcement by Dries. While I don't completely agree with this sentiment, I do understand it. The main pieces of Starshot have been open to discussion in the community, while the idea of putting them all together into a new "product" is something that (as far as I could tell) wasn't necessarily widely open for community input.
Jon Pugh
Wed, 05/22/2024 - 07:16
About 7 years ago, Washington State University, Vancouver set up their 11 websites on Aegir using a single Drupal 8 codebase. Thanks to Aegir, our client and friend Aaron Thorne was able to maintain all 11 websites by himself, despite not being a Drupal developer. Eventually, though, it was time for something new.
Last year, they contacted me to upgrade their sites and the hosting platform, but keep it inside their own private server infrastructure.
We took our time to figure out how we could design a new model for a multisite codebase, hosting, testing.
How can we implement reliable quality controls and automated delivery across all 11 sites? How can we make it as easy as possible for developers and system administrators to maintain? How can we leave WSU Vancouver with a system that they can use long term, so that they can update their codebase... forever?
The answer? A new self-contained system using DDEV, GitHub Actions, and clever usage of settings.php and Drush aliases.
I gotta be honest: as a developer, working this way has been a dream.
Yesterday, your CTO mandated that all new CMS builds would be on Drupal and that all existing CMS platforms would be consolidated to Drupal within the next three years. Great! Time to start prioritizing sites, hiring teams, and planning development and launch schedules.
Series Overview & ToC | Previous Article | Next Article (coming May 29th) In the previous article, we talked about avoiding entity ID conflicts which is one of the primary known issues when migrating to Drupal 10. In this section, we will discuss other issues that might arise and some limitations of the API. As time passes, issues are fixed and new ones might get discovered. While we strive to keep this series up to date, refer to the official documentation for the latest community aggregated resources. Contact us to learn how we can help you with your migration. Schedule a Free Consultation ## Migrating Views The migration of views is not supported by the core Migrate API. Among other reasons, changes to the site architecture and views plugins not being available in Drupal 10 are some of the reasons behind this decision. Outside of what is provided by Drupal core, multiple contributed modules were created to attempt an automated upgrade path. As of this writing, the only supported one is the Views Migration module. It takes a best-effort approach to performing an automated migration. A few things to consider: * There are many modules that integrate...
Read more mauricio Wed, 05/22/2024 - 06:00Whether it comes to e-commerce stores, blogs, or standard landing pages, using web forms for Drupal 10 is a traditional practice for many. Their purpose is to add more functionality to your system — you will need a separate form to let end users register on your platform, delete accounts, add data, and much more.
Your task is to create a sitemap and understand what business services you are going to offer. Then, you will find the target form in Drupal 10 and make things work innovatively, smoothly, and straightforwardly — no old-school static pages.
The Technical Working Group (TWG) is announcing one coding standards change for final discussion. Feedback will be reviewed at the meeting scheduled for Wednesday 5 June 2024 UTC.
The Coding Standards project page outlines the process for changing Drupal coding standards. Changes to the Drupal Coding Standards are announced via Coding Standard changes records.
Join #coding-standards in Drupal Slack to meet and work with others on improving the Drupal coding standards. We work on improving our standards as well as implementing them in the core software.