Allow starterkit theme generator tool to clone Olivero

Yes please! I'd love to use Olivero as the starting point for the D10 version of wimleers.com 🤓 (Which I'll make happen hopefully some time later this year…)

Does this need work in Olivero itself, or in the theme generator infrastructure?

Let's find out.

Yes, this needs to happen within Olivero. Olivero will need to implement \Drupal\Core\Theme\StarterKitInterface similar to \Drupal\starterkit_theme\StarterKit which will handle post process steps required for Olivero.

We need to decide what to do about the Olivero color changing when the theme generator is used. We need to decide if we want to copy all of the logic to the generated theme or if we should try to abstract that feature to a module.

Olivero uses PostCSS for its CSS. I guess we should also generate tooling for the generated theme so that the owners of the new theme will be able to rebuild the CSS.

I am also testing the Olivero theme in my new Drupal 9 project (candidate to 10 ... ), and I was trying to understand how to fork/subtheme it,
and then being able to customise it to my specific needs,
when I figure out that it doesn't really support it, yet.

Looking around I found this: https://github.com/mherchel/olivero-subtheme
and I have been able to take advantage of its "manual" procedure (pretty obvious, I know, and also not an immediate process, due to the many "find & replace"s to carefully process ), and fixing all the mistakes and the missed ones.

Unfortunately its bash script doesn't work properly: a lot of files are not properly cloned.

Anyway its yarn commands (defined in the package.json file) work pretty well, especially in managing (altering / extending / customising) its *.pcss.css files.

I know that I am in not an ideal situation ... as I will probably miss / mismatch all the still ongoing devs in Olivero (before the first official release of Drupal 10 on the 14th of December). But that was the most reasonable approach I found so far to have the Olivero really adoptable ... and not only for a curious look at it.

Olivero looks really cool to me, with its Grid responsive system, and almost ready to go state.
Hence really looking forward for a forthcoming implementation of a starterkit for it ...

Here's my attempt at a sub-theme tool for Olivero, which should work: #3214072: Provide an Olivero sub-theme creation tool.

Adding testing instructions to the IS.

Honestly, I think there are several improvements to the starterkit script that we could make:

• There's no way currently to specify files that shouldn't be copied over to the new theme without a custom implementation like I did in the MR. This seems like the kind of thing that should be easier to implement in that StarterKit class with an array of filenames
• The starterkit script currently does a lot of re-naming, but does it only in very specific ways. I wonder if there's a reason not to expand it to a full find-and-replace like in the MR

An additional to-do: we probably want to remove the starterkit class from the generated theme as well.

Latest updates:

• Delete post_update.php, tests dir, StarterKit.php from generated theme
• Renames PHP classes with a TitleCased version of the theme's human-readable name.
• Renames PHP files with the capitalized "Olivero" with a TitleCased version of the theme's human-readable name

Latest changes find-and-replace class names first.

Got the build-step files in from core. Still needs tests, but ready for review!

Question: We need a readme file in there that details the PostCSS compilation steps as well as other pertinent information. What's the best way to provide this without easily exposing the readme directly within Olivero? Maybe we should create a newThemeReadme.md in the src directory, and then copy, rename, and modify it when doing the theme generation process?

Just chipping in, as someone who has subthemed and modified Olivero, having the steps there to compile PostCSS would be hugely valuable, as it wasn't entirely clear what the best way to do it was.

So I just ended up creating a custom stylesheet and not touching the PostCSS. Not a huge issue as I only had to make minor modifications, but having the steps to compile the PostCSS right there in the theme, would have made my life slightly easier.

Adding #788332: Provide a parser for THEME.colors.yml as a related issue. It would be nice to get that in place before this issue so site builders don't have to duplicate & maintain their own theme coloring functionality.

Just tested this out myself and it worked great. I did encounter one error when trying installing theme dependencies after generation:

$ yarn install
yarn install v1.22.19
error package.json: Name contains illegal characters
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

This turned out to be due to the fact that I passed a value to the `--name` option when generating the theme that contained spaces. This resulted in the package.json file having a name value that contained spaces. E.g.:

{
  "name": "My name with spaces"
  ...

...which `yarn install` apparently doesn't like.

The full command that I ran that ultimately resulted in the error was:

$ php web/core/scripts/drupal generate-theme machine_name --description="Custom theme for My Site based on Olivero" --name="My Theme Name" --starterkit=olivero

Great work @andy-blum! I just tried the command which works well, as @balsama also wrote. I see the same Yarn error, which happens because the theme name is used in package.json, where the machine name would work better:

The "name" field contains your package's name, and must be lowercase and one word, and may contain hyphens and underscores.

From Creating a package.json file.

Currently in package.json:

{
  "name": "My New Theme",
[...]

After the update (66d7562d - Use machine name ...):

{
  "name": "my_new_theme",
[...]

After switching to using the machine name, I can generate a new theme, update for example the font in css/base/variables.pcss.css, and generate new CSS files, which take effect in the new theme.

Tests still need work - letting the test runner do the first nightwatch test to see if it passes 🤞

We're running into some issues here that I'm not sure how to fix - to this point I've been unable to get the PHP setup function to run before the nightwatch tests.

This line of the MR should be creating a new theme, using Olivero as a starterkit, but either that's not working, or we need to dump the cache before we move on, because the ThemeInstaller can't find our new theme.

10:19:00   ✖ NightwatchAssertError
10:19:00    Command failed: php ./scripts/test-site.php install --setup-file "core/tests/Drupal/TestSite/TestSiteOliveroInstallTestScript.php" --install-profile "minimal"  --base-url http://php-apache-jenkins-drupal-patches-159421/subdirectory --db-url mysql://drupaltestbot:drupaltestbotpw@172.18.0.4/jenkins_drupal_patches_159421 --json
10:19:00 
10:19:00 In ThemeInstaller.php line 132:
10:19:00                                       
10:19:00   Unknown themes: test_custom_theme. 

From Drupal Slack:

@mherchel

Not sure this is much help, but @bnjmnm looks like he's building some theme switching tools within the MR in #3293469: Automated A11y tests in Nightwatch. Not sure if it'd solve the issue of generating the theme and then switching though...

@bnjmnm

I think it might be possible to use an approach similar to my theme switcher, I'm basically throwing the logic we need into a controller managed by a module in the Nightwatch install profile. Since it sounds like execution order is the problem, you may be able to benefit from the same approach: have your test begin by going to /the-setup-stuff-you-need which will perform whatever tasks are required, then move on to the actual testing

That was so easy, thanks so much! I've been trying to stick with just core stuff for a simple site and ended up needing to customize just a little of the css and templates, so this was a huge win for my site. Thanks!

Thanks a lot on this! This is already pretty useful ...
BUT I have faced some important issues trying to generate a custom theme of mine with this starterkit from Olivero, when using a machina name with underscores and a label/name with spaces inside it.

For instance the following command:

php core/scripts/drupal generate-theme my_custom_theme --name "My Custom Theme" --starterkit olivero

generated weird duplications and mismatches in the names of the generated files and also a pre-render class name with spaces ...
(nothing really usable)

The only working solution with this has been (so far) to create/use a theme with both machine name and name without underscore or spaces, such the following:

php core/scripts/drupal generate-theme mycustomtheme --name MyCustomTheme --starterkit olivero

I could make it work, but is indeed not ideal ...

@itamir can you point to any specific examples where you encountered problems? I copied your example command and got perfectly valid results. I was able to fully install and set the new theme as default and browse the site without issue.

Hi Andy … well ok … sorry!
Donno what was it, how I experienced those weird behaviours, but I re-tested this few times more, and all LGTM now.
I am on a new Macbook ARM M2 and recently made some updates in my composer etc etc ...
Indeed now this looks neat and good to me.
I was able to start / fork 3 themes from Olivero, very quickly and with no apparent issues.

+1 for RTBC by me
(and thanks for this great work)

Now that the theme switching function from #3293469: Automated A11y tests in Nightwatch has landed, I've added it into our new testPerTheme() function. 🤞

Themes are created and installed successfully, but if their name does not contain the word "olivero". For example, if the theme's name is "custom_olivero" then there are issues with namespaces. Maybe it make sense just notify users about this in some doc?

Seems there are failures in the MR

Moving this to postponed as the starterkit tool theme is currently undergoing a re-write in #3364885: Allow themes to use a starterkit.yml file so it is easier to use the theme generator. When that's done all Olivero should need to do is update .info.yml and add a .starterkit.yml file

How is this not Major?! 🤯

Also, this is blocked on #3364885: Allow themes to use a starterkit.yml file so it is easier to use the theme generator, which itself is blocked 😅

… it's blocked more than I thought 😅

Symfony's finder & filesystem components are now full runtime dependencies [CR]

Now that #3364885: Allow themes to use a starterkit.yml file so it is easier to use the theme generator is in, this is unblocked!

Is it somehow possible to use/clone Olivero as a starterkit theme? Maybe with a patch since it hasn't made it into Drupal 11 yet.

For Drupal CMS there is the drupal_cms_olivero theme which itself uses Olivero as a base theme and which is not recommended like the module itself states in drupal_cms_olivero.info.yml.

# This theme is marked as @internal. It is intended to evolve and change over minor releases.
# Although we are sub-theming Olivero within Drupal CMS, sub-theming Olivero is
# explicitly not supported by Drupal core. This is intended as a stop-gap
# measure to provide great looking content types and components before a more
# robust design system can be implemented.

What is the proposed solution for Drupal CMS and Olivero and the build setup (CSS/JS/img optim) once Olivero got actually cloned? I would like to reuse the the 'menu' with it's a11y features.

Thanks for guidance.

Same question here for D11.1 core.

php core/scripts/drupal generate-theme mycustomtheme --name MyCustomTheme --starterkit olivero
[ERROR] Theme source theme olivero is not a valid starter kit.

I'm eagerly awaiting this issue to be ready for testing. I managed to patch Olivero to create a subtheme back under D9, but the patch wouldn't work for me in D10.

As a stop-gap, I've been using Jean Valverde's Olivero Subtheme Project. It links to this issue, and warns that it will soon be obsolete, but it doesn't seem to be quite yet!

I fully expect to recreate my subtheme as a Starterkit theme when possible, but just now Jean's project seems to be the best option for Olivero derived themes.

Whats holding this back? It's quite frustrating to see no progress here since a long time. In general, if Drupal "finally" wants to (re)attract (more) Frontend people the frontend topics should also be addressed like any other issue. Since my D6 days, the frontend has always been the stepchild ... I don't want to rant, but I'm actually a bit frustrated since I came back to Drupal after a while being away (for reasons) and things seem to be the same as they were in Drupal Frontendlandia. SDC is nice (for components), but we need a theme too (to glue it all together) ... marketing says it all changed but it unfortunately hasn't. Don't get me wrong and this is probably the wrong place to address this but on the otherhand it's also a core thing/theme where alot of effort already went into so why not reusing this great work and making it available for everybody? Navigation/focus management is key for websites a11y ... probably the navigation/focus handling needs to be extracted/provided as a own navigation module which then can be integrated/combind in any theme.

You can install this theme:
https://www.drupal.org/project/drupal_cms_olivero
Once installed, you can override anything you need in a custom theme.

@deviantintegral joined me in a pairing session to step-debug the test failures.

@andy.blum and I took some time to debug this. I pushed up a commit that moves the generation to before the site installer, but it may not be needed.

We determined that the core issue has to do with the APCu class resolver cache. For example, if you run:

ddev exec 'killall -HUP php-fpm' && ddev nightwatch tests/Drupal/Nightwatch/Tests/Olivero/oliveroPrimaryTabsTest.js && ddev nightwatch tests/Drupal/Nightwatch/Tests/Olivero/oliveroPrimaryTabsTest.js

The first test case will pass, and the second will fail being unable to resolve \Drupal\test_custom_theme\TestCustomThemePreRender.

!!!

It figures, in writing this out I realized what's happening!

The test theme is being generated in the simpletest directory, which is good so we have a clean state. But, the autoloader is caching the resolution of that class lookup, and then we remove that directory in future tests which get a new test ID.

This strikes me as being a problem with any test that is doing per-site multisite style themes or modules. Yet, the default apcu prefix should use the hash_salt, which in tests is the database prefix. There's still something else missing here.

We discovered what appears to be an unrelated bug. If you enable a theme in the UI, component caches aren't cleared so the new components aren't usable. @andy.blum is going to push up a workaround that installs the theme first from the CLI during the site install. I've filed #3522505: New SDC components are not available when enabling themes through the UI.

This is such a nice idea. +1

Added some comments to the MR - we shouldn't be adding return typehints in this MR.

One thought is doing we really need to run all the nightwatch tests against Olivero and a starterkit theme - doing so is going to double our Nightwatch testing time as far as I can see. Maybe we only need to run the most generic of tests - or maybe we only need to run against a generated theme?

Do we have an ETA on this?

I have trouble building the CSS in the 11.x branch. It used to work with Drupal 10, I think, at one point but now I seem to be getting:
UndefinedParserError: No parser and no file path given, couldn't infer a parser.
which is an error message from prettier.

Anyone else come across this one?

This comes up at compile.js starting at line 75 in compile.js (the one with return).

    .then(async result => {
      const config = await prettier.resolveConfig(filePath);
      return await prettier.format(result.css, config);
    })

Compiling Olivero CSS in core works, so there must be something with the paths ore some dependencies, I guess.

Another thing with the copies scripts is a more simple one:
For watch:css we have a set of paths to watch in postcss-watch.js
const watcher = watch(['./themes', './modules', './profiles'], {
but for the starterkit theme those folders don't exist but we should use something like
const watcher = watch(['./css'], {