Make updating changes from starterkit themes to generated themes easier [#3206226]

Problem/Motivation

When using base theme, theme maintainers could rely on upstream bug fixes on templates, CSS and JavaScript not overridden by theme.
Changes will start happening more frequently with the new starterkit theme because it addresses the BC concerns by moving some of the maintenance responsibility from the base theme to the theme maintainer. This raises a question; are there theme maintainers that would like to apply at least some of the changes from the starterkit theme to their generated themes?

Proposed resolution

Make it easier to follow changes in the starterkit themes adding a generator key to the info.yml that stores the name and version of the starterkit theme. This will allow providing tooling to make updating changes easier in future if that's desired.

Remaining tasks

~~Validate if theme maintainers are interested in following core changes and applying them in generated themes~~

User interface changes

API changes

Data model changes

Release notes snippet

Issue fork drupal-3206226

Show commands

Start within a Git clone of the project using the version control instructions.

Add & fetch this issue fork’s repository

Or, if you do not have SSH keys set up on git.drupalcode.org:

Add & fetch this issue fork’s repository

1 hidden branch

3206226-make-updating-changes

changes, plain diff MR !2176

Check out this branch for the first time

Check out existing branch, if you already have it locally

About issue forks

Comments

Comment #1

29 March 2021 at 14:30

lauriii created an issue. See original summary.

Comment #2

lauriii

he/him

Finnish

Finland

commented 29 March 2021 at 14:30

Issue summary:

View changes

Comment #3

gábor hojtsy

he/him

Hungarian

Hungary

commented 8 April 2021 at 17:17

Issue tags:

+Drupal 10, +NorthAmerica2021

Tagging for DrupalCon North America 2021 contribution.

Comment #4

mherchel

he/him

English

Gainesville, FL, US

commented 12 April 2021 at 19:35

From my point of view, if I generate a brand new theme and its working, I won't be actively looking for upgrades.

If it ain't broke, don't fix it

That being said, it would be nice to have a changelog, so we could potentially bring in relevant issues.

Comment #5

12 April 2021 at 19:35

Version:

9.2.x-dev

» 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #6

12 April 2021 at 19:35

Version:

9.3.x-dev

» 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Comment #7

mglaman

English

WI, USA

commented 3 December 2021 at 07:51

Title:

Make updating changes from startekit themes to generated themes easier

» Make updating changes from starterkit themes to generated themes easier

Fix typo in title.

Comment #8

lauriii

he/him

Finnish

Finland

commented 8 December 2021 at 10:13

I tend to agree to #4. When I've maintained sites, I don't remember I would have ever looked for markup updates unless something was broken.

Since this seems like a bit of an edge I'm wondering if we could simply prepare for this by adding a new key to info.yml on the theme creation which stores the version of the starterkit theme used for generating the theme. The documented steps for checking changes that has happened since the theme was created could be:

Generate a new theme using the same version of the starterkit theme as the theme originally used
Commit the theme to a temporary branch in git
Update to the latest version of Drupal
Generate the same theme again and compare changes

I think the key part here is that we store the version of the original theme so that if we want to provide better tooling for this in future, we would already have that information available. Thoughts?

Comment #9

gábor hojtsy

he/him

Hungarian

Hungary

commented 8 December 2021 at 10:21

I think as long as there is a way to track which version was used to generate the theme, people could evolve tooling later on as well.

I would personally not say people will not look for markup updates, after all we are replacing a system where they ALWAYS got the markup updates in the base theme, so there was no reason to look for them, they got them. There was also no way to avoid them unless you avoided updating the base theme somehow (eg. contrib base themes).

Comment #10

mglaman

English

WI, USA

commented 27 April 2022 at 22:26

So should we provide a generated key which has something like SOURCE_THEME_NAME:VERSION. Which requires a version key to exist and converting the pseudo-constant VERSION to \Drupal::VERSION

Comment #11

lauriii

he/him

Finnish

Finland

commented 27 April 2022 at 22:33

+1, something like that is what I was thinking. We should also make sure a static value from contrib projects is supported.

Comment #12

27 April 2022 at 23:19

mglaman opened merge request !2176

Comment #13

mglaman

English

WI, USA

commented 29 April 2022 at 01:28

Status:

Active

» Needs review

Comment #14

6 May 2022 at 14:21

Wim Leers made their first commit to this issue’s fork.

Comment #15

wim leers

Ghent 🇧🇪🇪🇺

commented 10 May 2022 at 14:15

I think after addressing the reviews from @lauriii and @alexpott, this is now probably getting pretty close :)

Comment #16

lauriii

he/him

Finnish

Finland

commented 11 May 2022 at 11:37

Issue summary:	View changes
Status:	Needs review	» Reviewed & tested by the community

I think this is ready for committer review. Thanks for the epic work @Wim Leers and @mglaman!

Comment #17

mglaman

English

WI, USA

commented 12 May 2022 at 02:24

Wow, improvements look great. +1 to RTBC. It'll be interesting to get agency feedback on the strictness for a theme version. I think it's a good push, though, for best practices.

Comment #18

alexpott

he/they

English

🇪🇺🌍

commented 12 May 2022 at 08:07

Status:

Reviewed & tested by the community

» Fixed

Committed and pushed 8d3c6fd35f to 10.0.x and b4011fbfd6 to 9.5.x and 9243da8ab2 to 9.4.x. Thanks!

Credited myself for MR code review.

Comment #19

12 May 2022 at 08:07

alexpott committed 8d3c6fd on 10.0.x

Issue #3206226 by Wim Leers, mglaman, lauriii, alexpott: Make updating...

Comment #20

12 May 2022 at 08:07

alexpott committed b4011fb on 9.5.x

Issue #3206226 by Wim Leers, mglaman, lauriii, alexpott: Make updating...

Comment #21

12 May 2022 at 08:07

alexpott committed 9243da8 on 9.4.x

Issue #3206226 by Wim Leers, mglaman, lauriii, alexpott: Make updating...

Comment #22

wim leers

Ghent 🇧🇪🇪🇺

commented 12 May 2022 at 08:10

I think it's a good push, though, for best practices.

My thoughts exactly :)

Comment #23

wim leers

Ghent 🇧🇪🇪🇺

commented 23 May 2022 at 09:59

Issue tags:

+9.4.0 release notes

IMHO this belongs in the 9.4.0-beta1 release notes … but I see that #3206219: Allow configuring which theme is used as a starterkit theme was also not mentioned yet in https://www.drupal.org/project/drupal/releases/9.4.0-alpha1 — is that an oversight or intentional? 😅🤓 I think we might want to do both?

Comment #24

lauriii

he/him

Finnish

Finland

commented 23 May 2022 at 10:35

#3206219: Allow configuring which theme is used as a starterkit theme was not mentioned because the starterkit theme is still alpha, and shouldn't be included in tagged releases. I think what we need is one draft release note which introduces the starterkit theme on a high level and mentions these key extension points.