Drupal Starshot blog: Drupal CMS base recipe update for initial release

What

Why

Installs a bunch of core modules and applies some core recipes

We are no longer using install profiles, so we have to add the foundational stuff somehow

Adds a redirect on access denied to the login form, and then to the original destination (via ECA)

So users can easily reach their intended destination even if their session has expired

Adds support for logging in with email in addition to username (via Login Email or Username)

So users don’t have to remember a separate username. There is also an issue for supporting this in core, and when that lands we will no longer require a contrib module.
#111317: Allow users to login using either their username OR their e-mail address

Adds Gin as the admin theme

Because Gin provides a more modern UI, and as a contrib theme, is able to innovate faster than Drupal core admin themes

Adds Navigation (with a left-side menu) instead of the traditional admin toolbar

So the admin UI feels more modern and aligned with other similar systems. Navigation is an experimental module in core and has a roadmap outlining the path to stable.
#3421969: [PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to Stable

Adds a quick search for the admin menu (via Coffee)

So users can easily search for the admin page they are looking for.

Adds Trash module 

So users can recover deleted content

Adds Linkit support to CKEditor

So users can easily link to site content via search. Note there is an issue for adding a basic version of this in core, and we would prefer to use that. If it lands before 11.1, we will replace Linkit in the initial release.
#3317769: Drastically improve the linking experience in CKEditor 5

Adds a site dashboard (via Dashboard)

So users see a dashboard with relevant content when they first install, and when they log in (replacing /user as the default login page)

Adds focal point cropping to the image media type (via Focal point)

So users can select a focal point for their images to help them display nicely across aspect ratios

Adds Project Browser, Automatic updates, and Upgrade status

So users can add modules and keep their sites up to date from the UI, with no developer tools required

Adds some media management helper tools (Media entity download and Media file delete)

So the default media management experience is more intuitive. This will be extended and updated as part of the Media management track work.

Adds a Basic page content type

So every site has at least one content type available by default. See the full content strategy for more information.

Adds content cloning (via Quick node clone)

So users can duplicate content to easily create similar pages. This feature is a must-have, but the implementation is still up for discussion in #3474608: Evaluate cloning modules and #3477303: Create recipe to clone entities with ECA

Adds foundational SEO functionality: Pathauto, Redirect

Most sites require this functionality and the initial setup can be done generically

What

Why

Better default site search 

Drupal core search is very limited and not what site owners would expect from a modern platform. Drupal CMS will provide a more robust search experience using Search API. This is being done in the Advanced search work track, with the recipe in progress in #3468271: Add recipe for search backend

Autosave on forms (via Autosave Form)

So users don’t lose their work. This feature is a must-have, but we wanted to ensure the approach did not conflict with Experience Builder’s approach to the same problem.

HTML email sending

So users can send nicely formatted emails without additional configuration. See #3480680: Handle sending email in Drupal CMS

What

Why

Better select lists

The default select list experience is suboptimal, however, there is not currently a viable non-jQuery solution for this. We would like to use the Accessible Autocomplete Element/Widget based on the Accessible Autocomplete library but there are technical limitations around managing front-end dependencies.

Sitewide alerts

This is a common feature request, but we don’t want to implement something that will conflict with Experience Builder when it comes out, leaving sites with a problem to solve. We also feel it is a nice-to-have for our target person rather than a must-have.