Try to fork Mercury on install of a site template

I feel like this is a must have for CMS, but also recipes in general. Drupal core has Starterkit themes → .

We can generate a clone of an existing theme using a Drupal core script:

php core/scripts/drupal generate-theme my_new_theme

I assume that would could run that from the custom module and it would be done.

But would there be a way that this could be done from within the recipe? It can't be in config actions which my mind immediately went to, because it's not really config relates except for setting the theme as the default.

How else could we do this?

Adding ✨ Add a theme configurator so recipes can generate themes Active as related. There is an idea there for recipes, but no work yet.

Created https://www.drupal.org/project/site_template_helper → for this, at @alexpott's suggestion. It's really only meant for site templates. We shouldn't use it yet because we haven't yet figured out what the best practice is.

Capturing some discussion with @pameeela in Slack - ideally a site template would not need to rely on a bespoke theme at all; it would be able to just spin up with an automatic fork of Mercury (so that Mercury is free to evolve as it needs), and then do all further customization in Canvas, with JS components being used if custom design elements that stand outside Mercury's design system are needed.

Canvas isn't quite there yet, though. Site templates still need custom themes, based on Mercury but not extending it (i.e., themes forked from Mercury as a starter kit, rather than using it as a base theme), that can implement their customized styling or tweaks.

Ideally, they can ship these themes in such a way that they immediately become a part of the site itself, rather than exist as specific projects published on drupal.org. That will lead directly to a wasteland of dead and unmaintained themes -- a problem we would like to avoid.

My proposal is that we use Site Template Helper to support the following workflow:

• A developer creating a site template uses core's generate-theme command to create a custom theme that is a renamed Mercury clone.
• They build their site template on that theme, customizing it as needed.
• When it comes time to distribute the site template, they make it depend on Site Template Helper, and they zip up the theme into a file called theme.zip, that sits in the site template.

When a site builder spins up a site using that template:

• The site template is downloaded and installed by Composer, just like any other recipe.
• Site Template Helper, being a Composer plugin, springs into action and extracts the theme.zip file to themes/custom.
• The template can then be applied like a normal recipe. The theme is completely disconnected from Composer, and it is added to the project's Git repository as a totally custom, bespoke theme that will not be affected by any upstream changes in Mercury.

Although this isn't necessarily the ideal long-term solution, it solves the problem of depending on Mercury (or any other upstream theme), and it solves the problem of spamming drupal.org with highly custom, one-off themes, meant for but disconnected from specific site templates. It unambiguously puts the site's presentation layer under the complete control of the site template user, and the theme is truly the only thing that is controlling the site's look and feel. It's also a fairly easy workflow for site template developers -- "generate a theme and stuff it in a zip file" is simple to grok.

What if a site template wants to include an admin theme, or multiple themes (domain access, multisite, etc)?

I'm not sure the development workflow would be fairly easy. Now I have to have a place to work on the theme, and then zip it up, or create a deployment mechanism to do package things up instead of a normal git composer workflow.

What if a site template wants to include an admin theme, or multiple themes (domain access, multisite, etc)?

It can bring those in as normal Composer dependencies.

Now I have to have a place to work on the theme, and then zip it up, or create a deployment mechanism to do package things up instead of a normal git composer workflow.

Maybe it's a theme directory instead of a zip file, then. Not sure yet. But the overall gist is that the theme (since we unfortunately need to have one) should be embedded in the site template somehow.

Yep, admin theme should be a composer dependency and not part of the site template. I think a theme directory for the site template theme makes sense conceptually. It could be either a self-contained theme or a theme depending on another theme via composer dependency depending on the site template and its needs.

OK, so here's where we landed, with agreement from Lauri (here and on Slack/Zoom) and Jason and Lanny. This is what I'm merging.

A site template can do either, or both (or none) of these:

• Ask Composer to generate a custom theme on its behalf, based on some starter kit it specifies in composer.json. This is what drupal_cms_starter does, generating a Mercury fork called starter_theme (we can rename this later if we want to). The idea is that, if you don't start with a site template, you start with a blank slate and a detached theme, based on but not yoked to Mercury, that you can customize freely.
• Include a custom theme, in a magically named theme subdirectory. If this exists, the machine name of the theme will be inferred from the info file, and the theme will be moved, not copied, into the themes/custom directory for further customization, if desired. This custom theme can be a completely custom theme and doesn't have to be based on Mercury or any other starter kit.

In either case, the site builder is the person who ultimately has complete control of the theme, which is considered (and treated) as a totally custom theme.

Merged into 2.x.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.