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.
Earlier this month, at Mid Atlantic Dreamin’ in Philadelphia, I gave a talk titled Software Super Heroes: Building the tools you wish you had. My goal with the talk was to convince people that should, can, and in fact do, built tools for themselves. If you work with technology, and your job involves repetitive tasks the same applies to you too.
I like to use a very expansive definition of tool: “A tool is anything that makes a task easier which would be repetitive, hard, or impossible without it.” In that sense just about anything you make that simplifies you work can be considered a tool: a project estimation spread sheet, a good set of directions for a complex task, a flow for a Salesforce admin, a piece of code to normalize a large collection of files, and more.
My intention with that expansive view is to help encourage people to take on a tool builder’s mindset.
To be a digital tool builder does not require knowing how to write complex software, it just requires you to do what you already do now, but with intention. When we use a broad definition of tools, it’s easier to see ourselves as tool builders, even if we’re just talking about a spreadsheet or a Salesforce flow meant to handle an administrator’s daily tasks. When we see ourselves as tool builders we are more likely to make something worth using more than once.
When we approach problems with a tool building mind set, instead of insurmountable challenges caused by gaps in our tooling, we see opportunity to create something new to make the impossible possible. Instead of facing hours of boring repetitive tasks, we have chance to build a more interesting special purpose solution.
There are several excuses I commonly hear from people when I encourage them to build their own tools. They range from concerns about not having the right skills, to assuming someone else already built that tool or that the time required isn’t worth the effort.
My general response to these concerns is that while people should indeed look around for tools that already solve their problem, and that some problems are very hard to solve completely, if you start to chip away at a complex problem you often will find that you can create tools that are good enough to save you time and effort.
Don’t try to build the perfect tool that solves all possible edge cases on your first go. Create a tool that takes out some annoying and repetitive task. Then create a tool that solves for another task, or builds on your first time. Chip away.
I often tell developers who are early in their career that I should never see them doing rote repetitive tasks for hours on end. Instead once they understand how a repetitive task is done, they should start thinking about how to build a tool to take over. But that’s not just advice for developers: we invented computers to do repetitive asks (calculating artillery firing tables and cracking codes), let them do that.
When you set out to create a tool you have two main options: use something you already know, or use tool building as a chance to learn something new. I’ve used tool building as was to teach myself new features of Excel, Google Sheets, Salesforce Flows, Git, and several programming languages. This can be a great way to learn how to use the tool that’s just right for the job. But learning a new tool or technique takes time, and if you have a deadline you may need to move faster.
Personally I try to take both paths from time to time. I use things I know when: they are exactly the right tool, I am under time pressure, or I want to keep my skills sharp. I will take the time to learn something new when: it’s something I need to learn anyway, I am building on my own time, or it’s exactly the right tool for what I need to do.
Neither path is correct 100% of the time. By using them both I am able to create the tools I need, and broaden my skills over time.
The next time you’re faced with a task that is repetitive or hard with the tools you have: create yourself something new. Don’t get hung up on being perfect, just create something that’s better than what you have at the start.
Then save your tool to use again later. Share it with colleagues, friends, or as an open source project.
When in doubt, just start building.
The post Tool Building Mindset appeared first on Spinning Code.