Support automatic subtheme generation in Drupal 10+ / Drush 12+

wow ericmulder1980 thank you for figuring this out. That's so nifty. Does it get any conflicts with Drush 8 when these are applied?

Can review and test one the updated patch gets posted.

oh, sorry I cross posted (tabbed out reading Moshe's guide). Will test it now.

With Drupal version: 8.4.1, Drush version: 8.1.15 you can still use drush fst and it runs from the unchanged drush.inc. It is unchanged so that is all good.

Once Drush version: 9.0.0-beta8 is installed i get problems. Running drush fst gives a symphony error "Command "fst" is not defined". Running drush list does not show the command. I also checked with console.

It is 100% possible it is a composer issue on my setup so would suggest that someone else reviews.

Nope!I will swing back round to this tonight.

Okay, tested again, this time after applying the patch in the IS.

There is a slight difference in the functionality:

The command for Drush 8 was:
drush fst SubThemeName

For Drush 9 a machine name is required:
drush fst SubThemeName SubThemeMachineName

Once the subtheme has been successfully generated an error is reported:
[error] Unknown themes: new.

This has been an existing issue with Drush 8 also so not a deal breaker.

Because this patch requires a Drush patch we shouldn't commit it. Drush version : 9.0.0-beta8 is a final beta so I am not sure that they will make the changes to allow themes to register commands.

@ericmulder1980 do you want to inform the drush team over at https://github.com/drush-ops/drush/pull/3089 ?
I would say that is the most important thing, the clean up & adding cache clear can come after.

Not sure, I would say that we should wait on the response from the Drush team. If they indicate the inclusion of the #3089 patch in upcoming releases then we could preemptively commit this.

I agree w serg2 that we need to wait until drush team commit to the overall shape of the PR because if they tweak the API a little bit then we would be unleashing a flawed drush 9 implementation.

The good news is that they did patch drush 8 branch to work with 8.4.x I inquired with some people this weekend and we are in the clear there.

If anyone has drush 8 issues please make sure you update to at least 8.1.15: https://github.com/drush-ops/drush/releases/tag/8.1.15

Hi I have a beginner question there , I wish to use your patched drush 9 config for another drupal theme ( emulsify ) which has similar issue.
I saw this patch concern fundation 8.x-6.0-alpha3 but I couldn't find the specific commit ID and therefore couldn't find the original files to patch. Could somebody point me to the right direction ?

Finally found the solution , git clone https://www.drupal.org/node/1332338/git-instructions/8.x-6.x/nonmaintainer apply patch it with git apply -v, also I didn t see both file where at the root of the project.

Let's postpone this issue until the underlying core issue got fixed.

The underlying issue is "won't fix", so drush 9 commands for the theme won't be available.

The recommended alternative is to make the theme depend on a module in #474684: Allow themes to declare dependencies on modules which seems likely to appear with Drupal 8.6.

Alternatively, I've seen mentions of some themes using Drupal console instead to work around the problem.

Which means we could actually start working on a zurb_companion module and then declare it as dependency as soon as the new underlying core issue got fixed.

Revisiting this. Should we make a zurb helper module and put the drush commands in there?

Hi,

I've just created a new zurb_foundation_companion module to work with drush 9 / 10.
It's not stable yet, there are a few missing functions but it works. Co-maintainers are welcome. :)

Not sure why we need yet another helper module we already have #3025313: Outsource foundation libraries into common module dependency? and the foundation_sites module. This should be pushed into a separate initiative where we discuss the common functionality and break that out.

I am thinking the functionality that is broken out is:

• drush 8+9 support
• drupal console support
• centralized library management

Thoughts?

We need Drush 10 support. Drupal Console is basically dead. The companion module should be merged into the foundation_sites module.

Here is the error message I am receiving after installation.

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - drush/drush is locked to version 10.4.0 and an update of this package was not requested.
    - drush/drush 10.4.0 requires symfony/finder ^3.4 || ^4.0 || ^5 -> found symfony/finder[v3.4.0-BETA1, ..., 3.4.x-dev, v4.0.0-BETA1, ..., 4.4.x-dev, v5.0.0-BETA1, ..., 5.x-dev] but it conflicts with another require.
  Problem 2
    - drupal/zurb_foundation_companion 6.x-dev is an alias of drupal/zurb_foundation_companion dev-6.x and thus requires it to be installed too.
    - drupal/zurb_foundation_companion[dev-6.x, 6.0.0-alpha1, ..., 6.0.0-beta1] require drupal/core ^8.7 -> satisfiable by drupal/core[8.7.0-alpha1, ..., 8.9.x-dev].
    - You can only install one version of a package, so only one of these can be installed: drupal/core[8.4.0-rc1, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.2.x-dev].
    - drupal/core-recommended 9.1.4 requires drupal/core 9.1.4 -> satisfiable by drupal/core[9.1.4].
    - pantheon-upstreams/upstream-configuration dev-master requires drupal/core-recommended ^8.8 || ^9 -> satisfiable by drupal/core-recommended[9.1.4].
    - pantheon-upstreams/upstream-configuration is locked to version dev-master and an update of this package was not requested.
    - Root composer.json requires drupal/zurb_foundation_companion ^6 -> satisfiable by drupal/zurb_foundation_companion[6.0.0-alpha1, ..., 6.x-dev (alias of dev-6.x)].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Came across this issue looking for a solution for UIKit's subtheme initialization. It seems like themes defining drush tasks is just not going to happen, so I made a composer script to do the task instead. Hope this helps!

Uh, wow! This is a good idea 👍

Here is a patch for the composer script approach.

But realizing i think this whole approach should be obsolete now? #3364885: Allow themes to use a starterkit.yml file so it is easier to use the theme generator

Starterkit themes now use starterkit.yml file

Blog post: https://mglaman.dev/blog/improving-drupal-theme-starterkit-and-theme-gen...