Problem/Motivation
We have opened multiple issues planning to deprecate themes:
- #2659890: [Policy] [Plan] Drupal 9 and 10 markup and CSS backwards compatibility Will likely introduce a new Stable for Drupal 9 meaning that the Drupal 8 Stable should be deprecated on Drupal 9.0.0.
- #3050378: [meta] Replace Classy with a starterkit theme Plans to replace Classy with a starterkit.
- #3084814: Deprecate Seven theme Plans to replace Seven with a new admin theme.
These are blocked or will be blocked by the fact that at the moment we don't have any documentation on what is the process for deprecating themes..
Proposed resolution
Document process for deprecating themes.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | 3084816-13.patch | 1.48 KB | sakthivel m |
Issue fork drupal-3084816
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
lauriiiComment #4
bnjmnmAssigning to myself to avoid possible duplication of work. I have a patch almost ready but likely won't be able to post until tomorrow.
Comment #5
bnjmnmHere's a possible approach.
Comment #6
lauriiiI'm not sure if it's enough for us to trigger the deprecation warning during the theme installation process. It would be great if this information would be available for already installed themes as well.
Comment #7
bnjmnmAgreed - I was having difficulty finding a good place for it that doesn't trigger tons of deprecation errors, but a good location (or at least a better one) finally occurred to me.
Comment #8
lauriiiWe could potentially follow the path that this issue is taking: #3062302: Properly deprecate the entity reference module. This would be better because it would trigger the error whenever the theme is being used, rather than just on the appearance page. Any thoughts?
Comment #9
bnjmnmThe suggestion in #8 led to a much simpler approach.
I also tried this out with every core theme and the deprecation warning successfully appears for each theme using only existing tests - something I assumed would be the case but it's nice to have confirmation of.
Comment #13
sakthivel m commented#13 Just re-roll the patch
Comment #15
sakthivel m commentedComment #16
andypostIt should wait for #3124762: Add 'lifecycle' key to .info.yml files
Comment #17
xjmThat's in!
Comment #19
bnjmnmMoved #9 to a merge request.
The reroll in #13 was unnecessary as #9 still applies to later version of core, and it also breaks the patch as two necessary files were excluded from.
I noticed another unnecessary reroll you made in #2939985: Remove non-existent dependency core/collapse in claro.libraries.yml. If you'd like to determine if a reroll is necessary, simply go to the most recent patch, click its "Add test/retest" link, then choose "custom parameters" with the most recent branch of Drupal. If you get an error that the patch doesn't apply, then it needs a reroll.
Comment #21
gábor hojtsyWith #3124762: Add 'lifecycle' key to .info.yml files in, #3215043: Indicate the non-stable statuses in admin/modules page RTBC and #3250585: Highlight deprecated modules and themes at admin/reports/status page, providing warning and link with explanation being actively worked on, what else is needed here. There is a way to mark a theme deprecated now, but its not surfaced for users. Should it be? It appears the thinking in the existing issues has been that we don't want to expose that to users since it is perfectly fine to use a deprecated theme.
Upgrade status already exposes obsolete and deprecated extensions for a while, see #3223453: Check for uses of deprecated and obsolete projects based on the lifecycle info file key.
Comment #22
xjmComment #23
catchI think we still might need #3215044: Promote the non-stable statuses in admin/appearance page, optionally even visually, but I don't think there's anything else here that's not covered by the lifecycle key, so marking duplicate.